Philip Guenther wrote:
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.
Okay, let's say there were some ad hoc "MUST NOT" in 2821 addressing
weird implementations at the time when it was written. That doesn't
force us to keep them when they did the trick. Another example in
this direction is the "Apparently-To" section: This is now a "IANA
registered bad idea" with a reference to 2821 (+3552). IMO we can
remove it from 2821bis, it's an obsolete bug. Nobody is going to
reinvent Apparently-To if 2821bis drops its Apparently-To chapter.
This was an area of 822/821 that was more murky than most, so it
was called out.
It's even murkier today with those multiple Resent-blocks, and some
odd RFC 4406 applications happily ignoring a MUST in RFC 2822 while
assuming that the "may add sender" in RFC 4409 is actually a "must
add sender" plus "get it right in the presence of Resent-blocks" :-(
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.
I see your point, but there are various "MUST NOT reject this" and
"MUST NOT reject that" resulting in an overall impression that any
"reject" decision is dubious. But that's not true anymore for a
world with 80% spam. With "reject a.s.a.p." legit senders have a
chance "to make another plan" or to fix whatever the problem is.
With the obsolete "always try to accept" strategy legit mails are
lost when they end up in some "suspicious" folder. So IMO any old
"MUST NOT reject" sends the wrong message to 2821(bis) readers, it
is propaganda for the broken "accept and bounce" design.
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.
Yes, and the sender will learn that they're idiots, and can "make
another plan", e.g. reject list subscriptions from their users.
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.
The general SHOULD NOT covers this, violating a SHOULD NOT needs a
good excuse, being an idiot isn't good enough:
| Server SMTP systems SHOULD NOT reject messages based on perceived
| defects in the RFC 822 or MIME (RFC2045 [21]) message header
| section or message body.
Frank
P.S. for John: My editor counts 35 "822" and 15 "2822", i.e. about
20 bare "822" where s/822/2822/ might be okay (?)