Re: Last Call: draft-klensin-rfc2821bis (Simple Mail Transfer Protocol) to Draft Standard (1)

[Pete Resnick <[e-mail]>]

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:

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.

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.

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

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: [phone], Fax: [phone]

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf