ietf
[Top] [All Lists]

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

2007-12-10 17:18:58
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>