[Mailman-Users] Duplicate Subscription Confirmations

Probably because he is sending two subscribe commands to the -request
address, one in the subject and one in the body.

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(0200000069b64b4149732800000030666530653230363239653337353438316264303639656238333931376436376433323766386362
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:

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.