> 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 mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf
