Have you ever seen Mailman issue duplicate subscription requests?

When a user sends a request to subscribe, he is receiving two confirmations for each request. Nothing obvious is apparent in the logs and the confirmations are properly formatted. Email is flowing well (using Postfix as the MTA). Has anyone seen this problem before? Do you have any suggestions as to how to approach this problem?

Here is some environmental information:

OS - CentOS 5.2 (2.6.18-92.1.10.el5)
Mailman - 2.1.9
Postfix - 2.3.3
Python - 2.4.3

Any guidance would be greatly appreciated.


Search Discussions

  • Mark Sapiro at Dec 11, 2008 at 6:23 pm

    James Weingarten wrote:
    Have you ever seen Mailman issue duplicate subscription requests?

    When a user sends a request to subscribe, he is receiving two confirmations for each request.

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

    Mark Sapiro <mark at msapiro.net> The highway is for gamblers,
    San Francisco Bay Area, California better use your sense - B. Dylan
  • James Weingarten at Dec 12, 2008 at 10:25 pm
    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): 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: 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
    File "/usr/lib/mailman/Mailman/Archiver/Archiver.py", line 200, in ArchiveMail
    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?


    ----- 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

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

    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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupmailman-users @
postedDec 9, '08 at 7:17p
activeDec 12, '08 at 10:25p

2 users in discussion

James Weingarten: 2 posts Mark Sapiro: 1 post



site design / logo © 2023 Grokbase