In <01MKEZIWES14005BGY(_at_)mauve(_dot_)mrochek(_dot_)com>
ned+ietf-822(_at_)mrochek(_dot_)com writes:
Again, this line of challenge to the current spec seems to be attempting a
review of previously-resolved issues, rather than claiming that there are
known problems with the resolution and documenting the need for change.
This is exactly such an example. Implementors seems to have taken that
SHOULD as an excuse to "improve" messages during transit (not allowed if
you read the spec correctly) or to avoid enabling display of these things
robustly when they do arrive (also not allowed by the spec).
And I'll once again point out that these implementors have quite simply read
something into the specification that just isn't there. You cannot
cure such misreadings by removing compliance language - if you do that
they will simply say "there's nothing in the specification that says I cannot
or should not do this".
If this really is worth addressing (and I'm 99.99% convinced it is not), the
way to do it is to tighten down the rules, not loosen them. For example, you
could say something like "the 78 character limit SHOULD be observed when
initially constructing messages but exceeding 78 characters SHOULD NOT be
taken
as justification for modifying messages in transit".
Yes, that would address my problem. In fact, it was one of the
possibilities I suggested, but Pete was unconvinced :-(.
Generally speaking, there should be a SHOULD NOT for changing _anything_
during transit, except for Trace headers, changes of CTE (if you are
unfortunate enough to encounter a non-8BITMIME system), or other such
things explicitly allowed. Far better to let the end points deal with
odd things that intermediate hops find odd.
Well, let's see. A _very_ incomplete list of legitimate things people do to
messages in transit would have to include:
(1) MIME conversions - upgrading as well as downgrading
(2) Format conversions and transcoding (we have formally defined
specifications for this)
(3) Signature addition, removal, and verification. (DKIM would fit in here.)
(4) Encryption, decryption, and reencryption
(5) Gateways to and from other message formats, arguably including netnews
(6) Various sorts of processing related to mailing lists. (IMO some of what's
done is legiti, some isn't, but attempts to pin down the rules for this
have beenn _spectacularly_ unsuccessful.)
(7) Spam and virus filtering, including but not limited to labelling,
part removal, and viral payload excision.
Given all these activities (most but not all of which are described in a bunch
of other specifications) trying to come up with language specific enough to
provide compliance guidelines seems rather futile, especially since the list of
what's acceptable and what's not changes constantly. And saying something
generic like "message content SHOULD NOT be changed unless you have to" seems
rather pointless, since everyone who does this invariably thinks whatever they
are doing is OK. And as I've pointed out previously, such language has no place
in the message format specification in any case - it belongs in the transport
documents since other transports may impose very different rules on messages
than SMTP does.
No, I'm afraid this entire area is pretty gray and where attempting to nail
down compliance is effectively an attempt to codify good judgement. It would be
nice if that were possible, but it just isn't.
Ned
P.S. The painful reality is that the rule some like to promulgate that our
transport mechanisms should never mess with message content, is "more honored
in the breach". And we need to stop pretending this isn't the case.