> Pete Resnick wrote: > > I believe this is a bogus complaint > And I hope you're right. > > RFC 2369 and RFC 2919 (the ones that define the List-* > > fields) both extend [2]821 > Yes, they didn't bother to say "updates [2]821, but yes, > they obviously overrule the MUST in 3.9 (was 3.10). > > in the same way that the MIME documents extend [2]822. > I'm not aware of any apparent or real incompatibilities > between MIME and [2]822, they are very near to perfect. Its about the biggest incompatibility imaginable: MIME allows charsets besides US-ASCII and both 8bit and binary content, RFC 2822 restricts things to 7bit US-ASCII. > > e.g., MIME says that it's OK to use other than US-ASCII > > characters even though neither 822 nor 2822 allow them > Not over normal 7bit SMTP, it needs an extension or a CTE. And that's the point. We're talking about extensions here. Regardless of whether or not these are negotiated in some way, they are extensions nevertheless. > > Base specifications can be extended by other documents, > > and we may update base specifications without taking > > into account those extensions. > SMTP extensions are typically offered by the server, and > accepted / used by the client as specified. Typically but not always. I can use MIME to transfer ISO-2022-JP text or binary data encoded with base64, both of which are specifically disallowed by 2821/2822 and neither of which require that the server offer anything other than base SMTP. > > 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. > Nothing's wrong with simple, especially not in *S*MTP ;-) > The spec. could note that there are mutilating^Wcomplex > lists violating the MUST. It could also say SHOULD, an > RFC on standards track might be a good excuse to violate > this SHOULD (a SHOULD is also the shortest possible fix). > > For simple aliasing and redistribution lists, I think > > the "MUST be left unchanged" is appropriate. > IBTD, you mention DKIM below. It's confusing if folks > make up their own definition of "originator", and it's > surreal if they add references to [2]822 or email-arch > with a very different definition. Which is DKIM's (or whoever else is doing this) problem to solve. > Admittedly RFC 2369 and 2919 don't reference [2]821, > but as DS 2821bis trumps PS, and a MUST is critical by > definition. If there are good excuses lets say SHOULD. I would not object to changing this to a SHOULD, but I don't think there is consensus to do so, especially since it would require a recycle at proposed. > I like List-* header fields, they are far better than > manipulations of the body (breaking DKIM, needing work > to remove them in replies, often spam, often breaking > MIME, not what the author wrote, etc.) > > 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. > Yes, and 2821bis apparently and you certainly said "NO". > 2822 doesn't directly mention the possibility, it offers > a MUST NOT wrt Resent-* header field. Later resulting > in a confirmed appeal against 4406, and 2822upd will NOT > deprecate them. Meanwhile the DKIM WG happily ignores > these facts wrt 5016 and SSP. Again, that's DKIM's problem to solve. Ned _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf