Re: [Mailman-Users] Sender field
On 2006-04-27 at 22:46-05 Brad Knowles [EMAIL PROTECTED] wrote: At 10:40 AM -0500 2006-04-27, Neal Groothuis wrote: 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. Right. Mailman is the agent responsible for transmitting the message, and this needs to be reflected. This is not correct. Quoting RFC2822 section 3.6.2: 3.6.2. Originator fields The originator fields indicate the mailbox(es) of the source of the message. The From: field specifies the author(s) of the message, that is, the mailbox(es) of the person(s) or system(s) responsible for the writing of the message. The Sender: field specifies the mailbox of the agent responsible for the actual transmission of the message. For example, if a secretary were to send a message for another person, the mailbox of the secretary would appear in the Sender: field and the mailbox of the actual author would appear in the From: field. The Sender header should be employed by the orignator of the message, and only the originator. Mailman is not the originator of a message sent to a list; it is merely a relay agent. I will grant that the phrasing of the RFC is suboptimal here--it uses transmission when a better word choice would have been submission. But the immediately proceeding example (of a secretary sending mail on behalf of another person) clarifies the intent beyond any claim of ambiguity. [Outlook's behavior] is an MUA problem. See FAQ 2.3. No, it's not. As much as it pains me to say it, Outlook's behavior matches perfectly the intent of the RFC. It is Mailman's behavior of rewriting the Sender header that is the problem. However, we want to make sure to capture any potential messages that may be routed to the Sender: field and have them automatically processed through the part of the system that is designed to do that sort of thing. Mailman's processing behavior is to treat a reply to the Sender as a bounce. This is incorrect behavior, because many mail clients will include address of the Sender header in a reply-to-all function, causing Mailman to treat the reply as a bounce. So, in summary, the disadvantages of Mailman's behavior of rewriting the Sender header is that doing so is not in the intended spirit of RFC2822, causes subscription grief, and breaks Outlook. The advantage is that it helps Mailman detect bounces from a slim minority of brain-dead MTAs that send bounces to the Sender header. The problem is that you said you wanted to implement an option to allow people to turn it off, not to rip this feature completely out of the system. I would argue that the best course of action is to excise Sender header rewriting entirely and provide no option to turn it on. (Mailman has way too many options already.) If, however, an option is created to control the behavior, it should definitely default to OFF (no Sender header rewriting), not on. -- James Ralston, Information Technology Software Engineering Institute Carnegie Mellon University, Pittsburgh, PA, USA -- 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] Sender field
Neal Groothuis wrote: 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. The best place to make this kind of request is in FeatureRequests in the sourceforge.net tracker, and it is already there at http://sourceforge.net/tracker/index.php?func=detailaid=1460796group_id=103atid=350103. Please look at that item and add your own comments as you wish. Note however that there is motivation for keeping the Sender behavior as is because there are still broken MTAs that will return bounces to the Sender:, so anything that actually is implemented would likely be an option with current behavior as the default. Also, RFC 2822 arguably requires a Sender: header in the case of a list sending mail on behalf of a poster. -- Mark Sapiro [EMAIL PROTECTED] The highway is for gamblers, San Francisco Bay Area, Californiabetter use your sense - B. Dylan -- 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] Sender field
At 10:40 AM -0500 2006-04-27, Neal Groothuis wrote: 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. Have you filed an RFE at the appropriate SourceForge page for Mailman? - 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. This is an MUA problem. See FAQ 2.3. - Useful information (the original content of the Sender: header) is lost by doing this. If the previous value of the Sender: field is being lost, then that should be corrected. At the very least, the value should be saved in an Old-Sender: or Previous-Sender: or some other suitable renamed sender field. - Bounces go to the envelope sender or Return-Path: header, not the Sender: header, so this is not necessary for proper bounce handling. Mailman does not modify this header for the purpose of routing bounces to the appropriate place. Mailman modifies this header because the original From: header is left unchanged and the RFC specifies that we should indicate when the message has been forwarded or sent by someone/something else on behalf of the entity in the From: field. - 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. Right. Mailman is the agent responsible for transmitting the message, and this needs to be reflected. However, we want to make sure to capture any potential messages that may be routed to the Sender: field and have them automatically processed through the part of the system that is designed to do that sort of thing. - Information regarding interacting with the list is provided by the List-* headers; including it in the Sender: field is unnecessary. No, it is necessary. It's required by the RFCs. Removing this (IMO) unwanted functionality is trivial: The problem is that you said you wanted to implement an option to allow people to turn it off, not to rip this feature completely out of the system. Implementing the option and putting in the necessary UI features so that site and list administrators can choose whether or not to modify the headers in this way is a considerably more complex task than just ripping out a feature you don't like. Give us some suitable code to make this feature optional and controllable by the site admin (and something that can be delegated to the list admin), and you'll have a much better chance of getting someone to pay attention to your request. Otherwise, keep applying the patch to each new version of Mailman as you install it. -- Brad Knowles, [EMAIL PROTECTED] Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 LOPSA member since December 2005. See http://www.lopsa.org/. -- 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
