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: r...@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 <[email protected]> To: [email protected]; [email protected] 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 <[email protected]> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan ------------------------------------------------------ Mailman-Users mailing list [email protected] http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-users/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
