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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf