[Mailman-Users] Duplicate Subscription Confirmations

James Weingarten santaclarajim at yahoo.com
Fri Dec 12 23:25:40 CET 2008 

Thank you, Mark. I think you're right. I don't see the problem often enough to merit implementing a fix.

I do have one additional pair of questions, if you please.

I had a problem with permissions that prevented the Mailman GUI from
successfully creating list. The GUI returned the following error:

Bug in Mailman version 2.1.9
We're sorry, we hit a bug!
Please inform the webmaster for this site of this
problem.  Printing of traceback and other system information has been
explicitly inhibited, but the webmaster can find this information in the
Mailman error logs.


and the error log shows:

Dec 12 11:35:27 2008 (3669) command failed: /usr/sbin/postalias /etc/mailman/aliases (status: 1, Operation not permitted)
Dec 12 11:35:27 2008 admin(3669): @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
admin(3669): [----- Mailman Version: 2.1.9 -----]
admin(3669): [----- Traceback ------]
admin(3669): Traceback (most recent call last):
admin(3669):  File "/usr/lib/mailman/scripts/driver", line 101, in run_main
admin(3669):    main()
admin(3669):  File "/usr/lib/mailman/Mailman/Cgi/create.py", line 56, in main
admin(3669):    process_request(doc, cgidata)
admin(3669):  File "/usr/lib/mailman/Mailman/Cgi/create.py", line 238, in process_request
admin(3669):    sys.modules[modname].create(mlist, cgi=1)
admin(3669):  File "/usr/lib/mailman/Mailman/MTA/Postfix.py", line 232, in create
admin(3669):    _update_maps()
admin(3669):  File "/usr/lib/mailman/Mailman/MTA/Postfix.py", line 53, in _update_maps
admin(3669):    raise RuntimeError, msg % (acmd, status, errstr)
admin(3669): RuntimeError: command failed: /usr/sbin/postalias /etc/mailman/aliases (status: 1, Operation not permitted)
admin(3669): [----- Python Information -----]
admin(3669): sys.version    =  2.4.3 (#1, May 24 2008, 13:47:28)
[GCC 4.1.2 20070626 (Red Hat 4.1.2-14)]
admin(3669): sys.executable  =  /usr/bin/python
admin(3669): sys.prefix      =  /usr
admin(3669): sys.exec_prefix =  /usr
admin(3669): sys.path        =  /usr
admin(3669): sys.platform    =  linux2
admin(3669): [----- Environment Variables -----]
admin(3669):    HTTP_COOKIE: campaignions+admin=280200000069b64b4149732800000030666530653230363239653337353438316264303639656238333931376436376433323766386362
admin(3669):    SERVER_SOFTWARE: Apache/2.2.3 (CentOS)
admin(3669):    SCRIPT_NAME: /mailman/create
admin(3669):    SERVER_SIGNATURE: <address>Apache/2.2.3 (CentOS) Server at hostname.com Port 80</address>
admin(3669):
admin(3669):    REQUEST_METHOD: POST
admin(3669):    HTTP_KEEP_ALIVE: 300
admin(3669):    SERVER_PROTOCOL: HTTP/1.1
admin(3669):    QUERY_STRING:
admin(3669):    CONTENT_LENGTH: 153
admin(3669):    HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.7
admin(3669):    HTTP_USER_AGENT: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
admin(3669):    HTTP_CONNECTION: keep-alive
admin(3669):    HTTP_REFERER: http://hostname.com/mailman/create
admin(3669):    SERVER_NAME: hostname.com
admin(3669):    REMOTE_ADDR: X.X.X.X
admin(3669):    SERVER_PORT: 80
admin(3669):    SERVER_ADDR: X.X.X.X
admin(3669):    DOCUMENT_ROOT: /var/www/html
admin(3669):    PYTHONPATH: /usr/lib/mailman
admin(3669):    SCRIPT_FILENAME: /usr/lib/mailman/cgi-bin/create
admin(3669):    SERVER_ADMIN: root at localhost
admin(3669):    HTTP_HOST: hostname.com
admin(3669):    REQUEST_URI: /mailman/create
admin(3669):    HTTP_ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
admin(3669):    GATEWAY_INTERFACE: CGI/1.1
admin(3669):    REMOTE_PORT: 3314
admin(3669):    HTTP_ACCEPT_LANGUAGE: en-us,en;q=0.5
admin(3669):    CONTENT_TYPE: application/x-www-form-urlencoded
admin(3669):    HTTP_ACCEPT_ENCODING: gzip,deflate

The problem was alleged to be caused by thefact that the web server process owner "apache" was calling this process. Apparently, this user did not have permissions to execute the command. After fiddling with ownerships and permissions, I was never able to resolve the problem and had to resort to command line "newlist" to create all lists. Do you have any idea what is causing this problem?

Also, (and this may be related), I am seeing the following error in the Mailman error log:

Dec 11 15:51:24 2008 (2107) SHUNTING: 1229039483.4080291+18102d31f7e1d52f9d4ca593ddb48d23f9e7d00e
Dec 11 15:51:24 2008 (2104) Archive file access failure:
        /var/lib/mailman/archives/private/listname.mbox/listname.mbox [Errno 13] Permission denied: '/var/lib/mailman/archives/private/listname.mbox/listname.mbox'
Dec 11 15:51:24 2008 (2104) Uncaught runner exception: [Errno 13] Permission denied: '/var/lib/mailman/archives/private/listname.mbox/listname.mbox'
Dec 11 15:51:24 2008 (2104) Traceback (most recent call last):
  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 112, in _oneloop
    self._onefile(msg, msgdata)
  File "/usr/lib/mailman/Mailman/Queue/Runner.py", line 170, in _onefile
    keepqueued = self._dispose(mlist, msg, msgdata)
  File "/usr/lib/mailman/Mailman/Queue/ArchRunner.py", line 73, in _dispose
    mlist.ArchiveMail(msg)
  File "/usr/lib/mailman/Mailman/Archiver/Archiver.py", line 200, in ArchiveMail
    self.__archive_to_mbox(msg)
  File "/usr/lib/mailman/Mailman/Archiver/Archiver.py", line 169, in __archive_to_mbox
    mbox = self.__archive_file(afn)
  File "/usr/lib/mailman/Mailman/Archiver/Archiver.py", line 157, in __archive_file
    return Mailbox.Mailbox(open(afn, 'a+'))
IOError: [Errno 13] Permission denied: '/var/lib/mailman/archives/private/listname.mbox/listname.mbox'

The "check_perms" command reports no problems. What should the owner be for the archive directories and files? What should the permissions be?

Do you think these issues are related?

Thanks,
Jim




----- Original Message ----
From: Mark Sapiro <mark at msapiro.net>
To: santaclarajim at yahoo.com; mailman-users at python.org
Sent: Thursday, December 11, 2008 12:52:41 PM
Subject: Re: [Mailman-Users] Duplicate Subscription Confirmations

Jim wrote:
>
>I have confirmed that one user who received the duplicate confirmation did, indeed, have a "subscribe" in the subject and the body.
>
>Is there a way to protect against that behavior by the -request process? I would expect that process to detect that the requests were within the same email message and send only one response. Is there a reason it doesn't behave in that manner today?


It could be done, but it is tricky.

As it is, CommandRunner just processes the subject and up to
DEFAULT_MAIL_COMMANDS_MAX_LINES (default 25) body lines one at a time
until it gets a non-command or error except non-commands or errors in
the subject are OK. If it gets a subscribe command for a member, it's
an error, but if subscribe requires confirmation or approval, the
subscribed address won't be a member when the second request is
processed.

Note that it is perfectly valid to have multiple subscribe commands in
one message as each command can request subscription of a different
address.

So, in order to avoid accepting a second subscribe request for the same
address, we could look at all the pending subscriptions and see if we
have one for this address, but even then we can't just ignore this
request as it might be intentional (say the confirmation email from
the prior request was lost) so we'd have to make a decision based on
how recent the prior request was. It seems like a lot of effort for
something that occurs infrequently and does no real harm.

-- 
Mark Sapiro <mark at msapiro.net>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

More information about the Mailman-Users mailing list