![](https://secure.gravatar.com/avatar/5733d9d0130cec137b9c60ad4e28baf6.jpg?s=120&d=mm&r=g)
On 2006-04-27 at 22:46-05 Brad Knowles <brad@stop.mail-abuse.org> 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