On 12/9/07 at 6:07 AM +0100, Frank Ellermann wrote:
>I-D.klensin-2821bis 3.9 as before RFC 2821 3.10 state in essence, >that relays, forwarders, and mailing lists have no business to mess >with the header of a mail:
>>the message header section (RFC2822 [9]) MUST be left unchanged
>This appears to be at odds with the mailing list RFCs, adding >various List-* header fields.
I believe this is a bogus complaint on two counts:
I concur.
1. RFC 2369 and RFC 2919 (the ones that define the List-* fields) both extend [2]821 in the same way that the MIME documents extend [2]822. In each case, the former does things that the latter says one MUST NOT do (e.g., MIME says that it's OK to use other than US-ASCII characters even though neither 822 nor 2822 allow them). That's appropriate. Base specifications can be extended by other documents, and we may update base specifications without taking into account those extensions.
I also note that as a practical matter it is necessary for any base specification update to be stable before extensions that depend on that base to themselves be updated. The alternative of attempting to do everything at once is simply unworkable, and of course it makes no sense at all to attempt to update the extensions to reflect some change in the base at a point where it is still possible for the base to change in nontrivial ways.
2. The mailing lists described in 2821 are very simple redistribution lists, as opposed to the "fairly sophisticated forums for group communication" [2919] described in these documents. For simple aliasing and redistribution lists, I think the "MUST be left unchanged" is appropriate.
The key point is that this is redistribution prior to final delivery. Sophisticated list processors in effect submit a new message to the transport infrastructure and do not fall under this prohibition. Now, having said this, the minor one issue I do see with section 3.10 is that the "lists MUST change the envelope from" requirement is actually a tautology: Lists as distinct from aliases as defined as redistributors that change the envelope from address. The requirement that lists do the one thing that defines them appears to have originated in the department of redundancy department.
> It's disturbing if five IETF mail experts offer three strictly > incompatible opinions what mailing lists are supposed to do with an > existing "Sender" header field, or if adding a "Sender" (as it's > common practice) is actually permitted.
Assuming people here on the general IETF list have no idea what you're talking about here, suffice it to say that the discussion that occurred on the DKIM list to which you refer is about whether the aforementioned more complex mailing list should be adding or modifying the "Sender" field. I think there is not consensus on what such mailing lists should do, let alone what DKIM should do about that, which IMO lends more support for the position of 2821bis: Mucking around with a header section leads to bad consequences, and until some more work is done in this area to figure out the "correct" thing to do, one MUST NOT go changing header sections.
It is also worth pointing out that the extensions defined in RFC 2369 and RFC 2919 are far from the only ones that relax this requirement in some way. MIME downgrading, submit-time fixups, and content conversions are all processes defined in various other RFCs that can modify message headers and there are no doubt a bunch of others that I've forgotten to mention. Ned _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf