[Mailman-Developers] Sender field

[Brad Knowles]

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 at 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/>.