![](https://secure.gravatar.com/avatar/e6ea3e5ffc3558c74e9f8cbf3f38357a.jpg?s=120&d=mm&r=g)
At 5:32 PM -0400 2006-04-28, James Ralston wrote:
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.
I read through all of section 3.4 pretty carefully.
Unfortunately, I haven't been able to find any references to automated agents acting on behalf of other parties. It is not exactly clear to me if a "relay agent" should be considered as a "user" (for which examples are given), or if it should be treated in some other manner.
There are cases of "forwarding" mentioned where it is not
appropriate to make any modifications to any headers, but there are other cases where modifications are acceptable or even recommended.
Additional clarification would be very useful.
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.
On the whole, I'm coming around to the view that Mailman should
be using "Resent-" headers for the things it would like to add to the message (e.g., Resent-From:, Resent-Date:, Resent-Message-ID:, etc...), as well as the standard "List-" headers.
However, it is not clear to me what the impact on the user
community would be.
Yes, some users would stop seeing things that are confusing them,
because we would stop rewriting/replacing the "Sender:" field. Well-known MTAs would not have any problems with these changes, but I do have to wonder what the negative impact would be from less common MTAs, not to mention all the different MUAs that are out there.
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.
Right now, I'm probably somewhere around 75% convinced that we
should not be rewriting/replacing the "Sender:" header, and should be using appropriate "Resent-" headers instead. At least, in the ideal world.
However, In the real world, I am much less convinced that we
should be making a radical change like this, at least not without a lot more experience in how things are actually impacted.
I would support adding code to the system to make this change
optional and to initially default to the old behaviour (allowing people who want to play with this option to do so), then in a future version to default to the proposed new behaviour (but still giving people the option to go back to the old method), and then finally to removing the option to revert to the old behaviour at some distant point in the future.
But I definitely would not support just ripping out the offending code.
-- Brad Knowles, <brad@stop.mail-abuse.org>
"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/>.