Bad info in monthly reminder headers

Bug #265471 reported by Deejster
2
Affects Status Importance Assigned to Milestone
GNU Mailman
Fix Released
Medium
Unassigned

Bug Description

It appears that "Return-Path", "Sender", "Errors-
To", "X-BeenThere" are all being set to the incorrect
list when sending out the monthly info. [on the 4
list servers that I run, it turned out to be the
alphabetically first list in all 4 cases]

See the example below where <email address hidden> is a
member of "junk" and "testa" yet "Return-
Path", "Sender", "Errors-To" and
"X-BeenThere" are all
attributed to the "alist", and if subscriber.com
bounced the message for some reason, "alist-admin"
would be wondering why s/he couldn't find him amongst
the list members. [BTW - this is information exactly
as I received it for my subscriptions on one server.
Domains and IPs are the only things changed (for
privacy).]

In a perfect world this wouldn't be an issue, however,
the poor admin of alist (example headers below)
receives all the returns from all list reminders that
get sent out every month (and is starting to get tired
of it). Wouldn't it be better if these were
attributed to (one of) the list(s) that the subscriber
is a member of? Or if not that, shouldn't they at
least be attributed to mailman-owner (as in the "From"
header field)?

Return-Path: <email address hidden>
Received: from listhost.net (listhost.net [10.0.0.1])
 by mail.subscriber.com (8.9.2/8.9.2) with SMTP
id FAA01735
 for <email address hidden>; Tue, 1 May 2001
05:06:37 -0600 (MDT)
Received: from listhost.net (localhost [127.0.0.1])
 by listhost.net (8.9.3/8.9.3) with ESMTP id
FAA18897
 for <email address hidden>; Tue, 1 May 2001
05:06:18 -0600 (MDT)
Date: Tue, 1 May 2001 05:06:18 -0600 (MDT)
Message-Id: <email address hidden>
Subject: listhost.net mailing list memberships reminder
From: <email address hidden>
To: <email address hidden>
X-No-Archive: yes
X-Ack: no
Sender: <email address hidden>
Errors-To: <email address hidden>
X-BeenThere: <email address hidden>
X-Mailman-Version: 2.0.1
Precedence: bulk
X-UIDL: c3f7736e3c6bdbe9eb75e264e35e8768

<standard message body snipped>

Passwords for <email address hidden>:

List Password //
URL
---- --------
<email address hidden> <pw>
http://listhost.net/mailman/options/junk/dj%
40subscriber.com

<email address hidden> <pw>
http://listhost.net/mailman/options/testa/dj%
40subscriber.com

[http://sourceforge.net/tracker/index.php?func=detail&aid=420482&group_id=103&atid=100103]

Revision history for this message
Jafo-users (jafo-users) wrote :

Hmm, I just verified this on one the messages sent out on
one of our boxes running Mailman 2.0.4. FYI.

Revision history for this message
Morri027 (morri027) wrote :

We are experiencing the same problem - the return mail for all lists is
going to the administrators of
another list. However, the list that is getting the return mail is NOT
the first list alphabetically.

Revision history for this message
Whitaker-users (whitaker-users) wrote :

Is this issue fixed in subsequent (post 2.0.1) versions
of Mailman? For that matter, is this issue going to be
assigned a fixer?

Thanks,
Russell Whitaker

Revision history for this message
Whitaker-users (whitaker-users) wrote :

I should have added this information: the problem was seen
in our (my company's) Mailman 2.0.6 and 2.0.8 installations.

In the meantime, we have disabled the monthly 'mailpasswds'
cron entry for security reasons.

Russell Whitaker

Revision history for this message
Barry Warsaw (barry) wrote :

Note that in MM2.0, all reminders appear to come from the
first public list at your site. This is a design flaw
that's fixed in MM2.1.

Revision history for this message
Robellis (robellis) wrote :

A fix/workaround for anyone who might still be running 2.0.x --
create a list for sending password reminders, e.g.
'mm-reminders',
and make this change to cron/mailpasswds:

< a_public_list = None
---
> # a_public_list = None
> some_admin_list = 'mm-reminders'
> a_public_list = MailList.MailList(some_admin_list, lock=0)

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.