On Fri, 27 Apr 2007, Frank Ellermann wrote:
John C Klensin wrote:
[Frank wrote, citing the draft]
...
| In particular, they MUST NOT reject messages in which the
| numbers of Resent-fields do not match or Resent-to appears
| without Resent-from and/or Resent- date.
Delete this, please. Receivers can reject whatever they don't
like. The complete Resent-* concept is unnecessary in a world
using MIME. If some servers try to count Resent-* blocks they
are mad. But that's IMO a harmless madness, not a MUST NOT.
Changes an explicit DRUMS decision... needs a stronger argument
than your sense of taste, IMO.
IMO it needs a justification why that's relevant if you keep it,
for a specific MUST NOT after a general SHOULD NOT it has to be
important. You can't enumerate and forbid all cases of dubious
reject decisions. Something might be special with the Resent-*
case, and I've just no idea what this could be.
My recall from DRUMS of this and some of the other "MUST NOT reject
for <some reason>" was that they involved situations that were
always intended to be valid but that had been often misunderstood
by implementors, such that DRUMS decided to make a strong statement
that those cases were indeed valid and that systems that reject
messages because the implementor thought they weren't are broken
system.
So, what was special with the Resent-* case was that there *were*
known examples of implementors screwing up and rejecting because
they thought that a message with a Reject-To but no Reject-Date,
or something similar, was invalid. This was an area of 822/821
that was more murky than most, so it was called out. Perhaps 2821
has done its job of clarification and implementors are no longer
falling into that trap, but if so, it may be the very strength of
the MUST NOT that has been getting the point across.
<leaving direct topic....>
Just because a system may reject messages for whatever policy reasons
it chooses doesn't mean we don't want to exert strong pressure to
keep the avenues of SMTP operation and extension open. Is a site
that rejects all messages containing "unknown" header fields within
its rights to do so? Of course. They may be idiots, but they're
only hurting themselves. Is an implementation that always behaves
that way conforming? No, it's broken, and we really don't want
such an implementation to get into widespread use.
(This exact sort of thing is a major problem at other layers; think
DNS record types vs nameserver support, or TCP reserved bits vs
firewalls.)
Philip Guenther