Bug 65141 - Qfiles Directory Change Causes Bounced 'Subscribe' Emails
Qfiles Directory Change Causes Bounced 'Subscribe' Emails
Product: Red Hat Linux
Classification: Retired
Component: mailman (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: John Dennis
Depends On:
  Show dependency treegraph
Reported: 2002-05-18 01:19 EDT by Bob Cochran
Modified: 2007-04-18 12:42 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-06-06 05:54:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bob Cochran 2002-05-18 01:19:48 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513

Description of problem:
In mailman-2.0.9-1 the qfiles directory was changed from /var/mailman/qfiles to
/var/spool/mailman/qfiles however the Defaults.py script was not updated with
the new path for constant QUEUE_DIR. When a user then attempts to subscribe to a
mailing list newly created by this version of mailman, using an email with the
word 'subscribe' in the subject line, the email will bounce back as "Returned
mail: see transcript for details" and a python traceback dump is printed in the
body of the returned mail. 

In addition, if a user subscribes to a newly created mailing list using the
web-based subscription page for the new list, a confirmation request email will
be correctly sent to the subscriber. However when subscriber replies to the
email as directed, the reply bounces with a python traceback dump as indicated

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Create a new mailing list using /var/mailman/bin/newlist
2.Update aliases files needed by sendmail: /etc/aliases and
/etc/mail/genericstable, /etc/mail/virtusertable as needed to support the new list.
3.Send email with the word 'subscribe' in the subject line to the list 'request'
email address.

Actual Results:  The email will bounce on the sender with this message:

 ----- Transcript of session follows -----
Traceback (innermost last):
  File "/var/mailman/scripts/mailcmd", line 69, in ?
  File "/var/mailman/scripts/mailcmd", line 64, in main
    msg.Enqueue(mlist, torequest=1)
  File "/var/mailman/Mailman/Message.py", line 176, in Enqueue
    dbfp = Utils.open_ex(dbfile, 'w')
  File "/var/mailman/Mailman/Utils.py", line 599, in open_ex
    fd = os.open(filename, flags, perms)
IOError: [Errno 2] No such file or directory:
554 5.3.0 unknown mailer error 1

Sender is unable to subscribe to the new mailing list.

Expected Results:  Sender of a subscribe message should recieve an email
requesting confirmation of the list subscription. If sender is attempting to
confirm a web-based subscription request by replying to the confirmation
request, a "Welcome to ______ list..." message should have been recieved. 

Additional info:

A workaround that fixes this error is to edit /var/mailman/Mailman/mm_cfg.py as

add the line

QUEUE_DIR = '/var/spool/mailman/qfiles'
Comment 1 Nalin Dahyabhai 2002-05-22 12:11:16 EDT
The mm_cfg.py included with mailman-2.0.9-1 already contains this line, so I'm
not sure how you're getting this error.
Comment 2 Bob Cochran 2002-05-22 21:02:26 EDT
Hello, here is what I believe happened. 

1. I was already using mailman at the time I upgraded from Red Hat 7.2 to 7.3.
2. I created a new list right after the upgrade to 7.3 for as an unrelated project.
3. I noticed that mailman was suddenly saying the list administration URL was
http://localhost.localdomain/mailman/admin/(name of my list goes here). This
meant that the mailman upgrade probably overwrote my mm_cfg.py file.
4. I checked and confirmed this.
5. I then made a mistake, I didn't manually update the new mm_cfg.py file which
I now see contains several new lines. Instead, I overwrote the file with the
contents of the mm_cfg.py.rpmsave file.
6. Guess I should have manually updated mm_cfg.py with my site specific details. 

Bob Cochran

Note You need to log in before you can comment on or make changes to this bug.