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. > 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. > 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. > 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. 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 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. That's of course very far from 2821bis, but it's a mess, and it would be good if at least the core spec.s (incl. the future email-arch) are 100% clear. A MUST that is only a MUST in "simple" cases is a new concept for me. > more support for the position of 2821bis: > Mucking around with a header section leads to bad > consequences I agree, but apparently nobody else agrees, and common practice is to add a Sender (unlike the List-* header fields I don't like this Sender. Unless it's done as specified for RFC 4406, which still violates a MUST about Resent-* in 2822upd as confirmed in an appeal.) > until some more work is done in this area to figure > out the "correct" thing to do, one MUST NOT go > changing header sections. Sorry, I don't get it. Keeping a MUST when other RFCs ignore it for the *good* purpose List-* is beyond me. We're talking about 2821bis, one of the most important IETF RFCs, that's no stuff for a few geeks, it will be analyzed and discussed for years by thousands of users. We talked *months* about a single *dot* (in the former one-dot-only rule excluding TLDs) on three lists (SMTP, SPF, USEFOR). Frank _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf