Re: [Mailman-Users] [Mailman-Developers] Sender field
I'd like to work up an unofficial diff to Mailman 2.1 for people like Stephen who are willing to give it a try on a live site. I'm not sure this is even necessary. Ezmlm doesn't touch the Sender: header at all, Majordomo sets it to the owner of the list, and (AFAICT) Listserv sets it to the list itself. This would seem to me to indicate that incidences of mail being returned inappropriately to the sender are infrequent, at worst. The important question would seem to be what's appropriate? From RFC 2822, 3.6.2: The originator fields indicate the mailbox(es) of the source of the message. Given this, the definition of the Sender and From headers, and the example given in this section, it seems that Outlook's interpretation of the fields (SENDER on behalf of FROM) is reasonable. Mailman is not the originator of the message, so it should not be tampering with the From: or Sender: fields at all. It might be appropriate for Mailman to add Resent-* headers, depending on how one reads RFC 2822, 3.6.6. I personally don't think it's necessary or useful, since list servers add their own List-* headers, per RFC 2369. The Resent-* headers seem to exist for individuals resending messages, not automated systems. This is supported by the RFC: Resent fields are used to identify a message as having been reintroduced into the transport system by a user. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
Re: [Mailman-Users] [Mailman-Developers] Sender field
John W. Baxter wrote: Probably, indeed. But what happens if that header was already taken in the process that brought the message to mailman for distribution to the list? As I noted in my previous response, I believe that the correct field (if Mailman were to add a Sender: header) to add would be Resent-Sender. Please see RFC 2822, section 3.6.6. The Resent-Sender field may be multivalued, so this isn't a problem. However, Mailman should not be modifying the Sender: field at all. Original-Sender is a header used when gatewaying X.400 messages into RFC 822 messages for use in JNT mail networks. It would not be appropriate for use here. -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
[Mailman-Users] Sender field
To reopen an old discussion: I would like to request that a feature be added in the next version of Mailman to allow a list administrator to disable rewriting of the Sender: header, or (better) for this behavior to be eliminated from Mailman altogether. Rationale: - Outlook treats the Sender field as a person sending on behalf of another. This seems to me to be a reasonable interpretation of the Sender field, per RFC 2822 3.6.2. When a bounces address is included in the sender field, Outlook displays something along the lines of From [EMAIL PROTECTED] On behalf of [EMAIL PROTECTED]. (See Mailman FAQ entry 2.3). This is undesirable. - Thunderbird also displays the sender field, which presents similar confusion. - Useful information (the original content of the Sender: header) is lost by doing this. - Bounces go to the envelope sender or Return-Path: header, not the Sender: header, so this is not necessary for proper bounce handling. - Again from RFC 2822 3.6.2, the Sender: header should contain the address of the agent responsible for transmitting the message, meaning that a person who sends mail to the address in that header should expect to reach said agent, not suggest to Mailman that a message bounced. - Information regarding interacting with the list is provided by the List-* headers; including it in the Sender: field is unnecessary. Removing this (IMO) unwanted functionality is trivial: diff -ru mailman-2.1.5.orig/Mailman/Handlers/SMTPDirect.py mailman-2.1.5/Mailman /Handlers/SMTPDirect.py --- mailman-2.1.5.orig/Mailman/Handlers/SMTPDirect.py 2004-01-22 17:02:07. 0 -0600 +++ mailman-2.1.5/Mailman/Handlers/SMTPDirect.py2006-04-26 13:48:45. 0 -0500 @@ -348,9 +348,9 @@ # the Sender header at all. Brad Knowles points out that MTAs tend to # wipe existing Return-Path headers, and old MTAs may still honor # Errors-To while new ones will at worst ignore the header. -del msg['sender'] +# del msg['sender'] del msg['errors-to'] -msg['Sender'] = envsender +# msg['Sender'] = envsender msg['Errors-To'] = envsender # Get the plain, flattened text of the message, sans unixfrom msgtext = msg.as_string() -- Mailman-Users mailing list Mailman-Users@python.org http://mail.python.org/mailman/listinfo/mailman-users Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py 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://www.python.org/cgi-bin/faqw-mm.py?req=showamp;file=faq01.027.htp
