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