sender/envelope addresses esp with mailed commands
I tried experimenting with the mail command interface to MailMan with total lack of success until I discovered some oddities regarding the detection of sender addresses.
I am using Mailman 1.0rc3 (same result with 1.0rc2). I have the default zero setting for USE_ENVELOPE_SENDER. The MUA I am using on the test account is Netscape running on Linux connecting through an ISP by POP/SMTP. Netscape appears to add a "Sender: nigel" header - ie my unqualified user name, which is not qualified by any of the MTAs on the way (basically none of the MTAs will have sufficient information to qualify it so they shouldn't be playing with it).
Commands sent to the list-request address are responded to by mailman, which helpfully (!) sends replies to "nigel" on the list machine and complains during subscribe operations about an unqualified email address.
Fixing up the sender header is not really an option - it impacts to many other peoples systems.
I tried just stripping the sender header (assuming that would cause a drop back to From: headers as is implied in the FAQ etc), and managed to completely break list posting :-(
So I guess that Mailman, to be safe, should check the sender address more carefully - specifically if it is not qualified then it should discard it and use the From: or envelope (maybe Return-Path:) address in its place.
Nigel.-- [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]
"NM" == Nigel Metheringham <Nigel.Metheringham@vdata.co.uk> writes:
NM> I am using Mailman 1.0rc3 (same result with 1.0rc2). I have
NM> the default zero setting for USE_ENVELOPE_SENDER. The MUA I
NM> am using on the test account is Netscape running on Linux
NM> connecting through an ISP by POP/SMTP. Netscape appears to
NM> add a "Sender: nigel" header - ie my unqualified user name,
NM> which is not qualified by any of the MTAs on the way
NM> (basically none of the MTAs will have sufficient information
NM> to qualify it so they shouldn't be playing with it).
NM> Fixing up the sender header is not really an option - it
NM> impacts to many other peoples systems.
NM> I tried just stripping the sender header (assuming that would
NM> cause a drop back to From: headers as is implied in the FAQ
NM> etc), and managed to completely break list posting :-(I don't understand this part. Where did you strip the Sender: header? Look at IncomingMessages.GetSender() in Mailman/Message.py. It definitely falls back to using From: if Sender: doesn't exist.
NM> So I guess that Mailman, to be safe, should check the sender
NM> address more carefully - specifically if it is not qualified
NM> then it should discard it and use the From: or envelope (maybe
NM> Return-Path:) address in its place.Mailman /could/ have some cascading algorithm for authenticating an email address (i.e. authenticate Sender -> From -> Reply-to -> Envelope Sender). That's a big change to the current situation, so I'm not going to do this for the 1.0 release. Mailman currently only authenticates the first address it finds and if that fails then the message gets held.
However, if your ISP is inserting an unqualified Sender: address into outgoing mail it is broken. You say fixing this is not really an option, though I don't understand why that is (it what way does it impact many other people's systems?). If that's really the case I don't know what you can really do.
-Barry
Nigel is having the same problem I had - the Sender: header exists, but is unqualified. This is the way that Netscape Communicator (at least the Unix version) generates the header and as such is something we have to deal with. I worked around this by modifying GetSender to use Reply-to: if available or else From:
-t
"Barry A. Warsaw" wrote:
"NM" == Nigel Metheringham <Nigel.Metheringham@vdata.co.uk> writes:
NM> I am using Mailman 1.0rc3 (same result with 1.0rc2). I have NM> the default zero setting for USE_ENVELOPE_SENDER. The MUA I NM> am using on the test account is Netscape running on Linux NM> connecting through an ISP by POP/SMTP. Netscape appears to NM> add a "Sender: nigel" header - ie my unqualified user name, NM> which is not qualified by any of the MTAs on the way NM> (basically none of the MTAs will have sufficient information NM> to qualify it so they shouldn't be playing with it). NM> Fixing up the sender header is not really an option - it NM> impacts to many other peoples systems. NM> I tried just stripping the sender header (assuming that would NM> cause a drop back to From: headers as is implied in the FAQ NM> etc), and managed to completely break list posting :-(I don't understand this part. Where did you strip the Sender: header? Look at IncomingMessages.GetSender() in Mailman/Message.py. It definitely falls back to using From: if Sender: doesn't exist.
NM> So I guess that Mailman, to be safe, should check the sender NM> address more carefully - specifically if it is not qualified NM> then it should discard it and use the From: or envelope (maybe NM> Return-Path:) address in its place.Mailman /could/ have some cascading algorithm for authenticating an email address (i.e. authenticate Sender -> From -> Reply-to -> Envelope Sender). That's a big change to the current situation, so I'm not going to do this for the 1.0 release. Mailman currently only authenticates the first address it finds and if that fails then the message gets held.
However, if your ISP is inserting an unqualified Sender: address into outgoing mail it is broken. You say fixing this is not really an option, though I don't understand why that is (it what way does it impact many other people's systems?). If that's really the case I don't know what you can really do.
-Barry
Mailman-Users maillist - Mailman-Users@python.org http://www.python.org/mailman/listinfo/mailman-users
--
Tony Abbott tabbott@intekom.co.za
Systems Administrator, Intekom Tel: +27-11-266-7800
http://www.intekom.co.za Fax: +27-11-315-0707The information in this email and in any attachments is confidential and intended solely for the attention and use of the named addressee(s). This information may be subject to attorney and client or other privilege. It must not be disclosed to any person without Intekom's permission.
"TA" == Tony Abbott <tabbott@intekom.com> writes:
TA> Nigel is having the same problem I had - the Sender: header
TA> exists, but is unqualified. This is the way that Netscape
TA> Communicator (at least the Unix version) generates the header
TA> and as such is something we have to deal with. I worked around
TA> this by modifying GetSender to use Reply-to: if available or
TA> else From:M.A. Lemburg was having the same problem, and actually found a workaround for the Netscape bug. This, or something very similar, will be included in a README.NETSCAPE file for the next release.
-Barry
-------------------- snip snip -------------------- Mailman - The GNU Mailing List Management System Copyright (C) 1998, 1999 by the Free Software Foundation, Inc. 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
Some of your users may experience problems sending mail to a members-only list, if they are using Netscape Communicator as their MUA. Communicator 4.6 on Linux has been observed to insert bogus unqualified Sender: headers -- i.e. Sender: headers with only the username part of the email address. Other version of Netscape may also have the same bug.
Members-only lists use Sender: as the first field to authenticate against, so if Sender: exists in the email message, but it is unqualified, it will never match a mailing list member's address, and their post will always be held for approval.
In the future, Mailman will improve its algorithm for finding a matching address, but in the meantime, M. A. Lemburg <mal@lemburg.com> provides the following advice. You can send this snippet to any user whose posts are being held for seemingly no reason.
Edit the two .js files in your .netscape directory (liprefs.js and
preferences.js) to include the function call:
user_pref("mail.suppress_sender_header", true);
BTW, the binary includes a comment which says that this is only
necessary on Unix.
Since Communicator regenerates this file upon exit, the change
must be done when Communicator is not currently running. With the
next start, it will stop adding the Sender: header and things
start to work like a charm again.The reason things start to work again, is that Mailman falls back to authenticating the From: header if the Sender: header is missing.
Mailman /could/ have some cascading algorithm for authenticating an email address (i.e. authenticate Sender -> From -> Reply-to -> Envelope Sender). That's a big change to the current situation, so I'm not going to do this for the 1.0 release. Mailman currently only authenticates the first address it finds and if that fails then the message gets held.
Should you do this, you might want to look at the source for formail in the procmail distribution. They've been using this scheme for auto-responders for years... /* * sender determination fields in order of importance/reliability * reply-address determination fields (wrepl specifies the weight * for regular replies, wtrepl specifies the weight for trusted users) * * I bet this is the first time you see a bar graph in C-source-code :-) */ static const struct {const char*head;int len,wrepl,wtrepl;}sest[]= { sslbar(replyto ,"******" ,"********" ), sslbar(Fromm ,"*" ,"*******" ), sslbar(retreceiptto ,"********" ,"*****" ), sslbar(sender ,"*****" ,"******" ), sslbar(res_replyto ,"***********" ,"***********" ), sslbar(res_from ,"***foo***" ,"***bar****" ), sslbar(res_sender ,"**********" ,"*********" ), sslbar(errorsto ,"*******" ,"****" ), sslbar(path ,"**" ,"*" ), sslbar(returnpath ,"***" ,"***" ), sslbar(From_ ,"****" ,"**" ) }; First bar graph is used if you trust machine-generated addresses, second graph is used if procmail is told to trust the sender's configuration. The header field definitions are found in header.h: X(returnpath, "Return-Path:") /* RFC 822 */ X(res_replyto, "Resent-Reply-To:") X(res_from, "Resent-From:") X(res_sender, "Resent-Sender:") X(Fromm, "From:") X(replyto, "Reply-To:") X(retreceiptto, "Return-Receipt-To:") /* ditto ... */ X(sender, "Sender:") X(errorsto, "Errors-To:") /* sendmail extension */ X(path, "Path:") /* ditto ... */ And of course, 'From_' is really the envelope 'header' value. Comments are a little worthless since I only cut out the relevant lines. This is just a FYI in case anyone wants to work this into an algorithm of sorts... Chris
participants (4)
-
Barry A. Warsaw -
Christopher Lindsey -
Nigel Metheringham -
Tony Abbott