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

[Ned Freed <[e-mail]>]

> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf