In <01MKLM0UFGRY003GRV(_at_)mauve(_dot_)mrochek(_dot_)com>
ned+ietf-822(_at_)mrochek(_dot_)com writes:
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:
Sure, but I was not suggesting that as a change to be incorporated in that
form at this time, but as a principle that we should move towards as and
when opportunity arises.
(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.
Most of those affect only Trace headers (DKIM signatures are Trace
headers),
Excuse me? It's exactly the opposite: Out of all of these the only one that
doesn't commonly involve message body modification is (2), and in that case
only if you're talking specifically about DKIM.
or they are specifically allowed as part of related protocols.
Exactly the opposite is again the case: In spite of the fact that all of these
activities (and many more besides) have extremely compelling use cases, and in
one case (MIME downgrading) is for all intents and purposes required for useful
standards compliance, almost none of them are actually defined in some sort of
specification. And when such things have been defined (as is the case for
format conversions), the amount of pushback has been huge.
Downgrading is fine (e.g. when passing to Non-8BITMIME systems); upgrading
is undesirable except maybe at the agent that does final delivery (it
breaks some signature algorithms). Likewise filtering is for final
delivery agents, and not at other points during transit. Gateways (that
inlcudes list expanders and other forms of forwarding) have of course to
provide whatever the ongoing medium requires, and maybe that involves
adding extra (trace-like) headers, but not removal or alteration of
anything that can possibly be avoided.
Sigh. This is precisely the sort of thinking that has led to the present ugly
situation. Someone like you, apparently secure in the knowledge that you
understand everything there is to know about what people are trying to
accomplish and what the constraints they are operating under are, starts
throwing around a bunch of assessments of the form "this should be done this
way" or "this only makes sense in this situation" or "this has to be done at
this stage of processing". The problem is quite simply that you simply do not
have sufficient perspective to make such blanket statements.
And BTW, neither do I. My experiecne isn't necessarily more extensive and
certainly not better, it's just different.
I have neither the time nor the inclination to refute all of your assertions
here, so let me just pick the one that I actually regard has having the weakest
use-case of the lot: MIME upgrading. Email environments exist where essentially
all of the data being dealt with audio or video material. If the amount of data
is very large - and it often is - the 33% overhead of our most efficient
standard encoding is quite simply unacceptable in terms of the burden it places
on storage, transmission and encode/decode overhead. In such cases the approach
that may make the most sense is to upgrade to binary MIME as soon as possible
and keep things in that form as much as possible. (There are other, trickier
appproaches, but the ones with comparable effciency typically involve even more
extensive modifications to message content.)
in any case, I'm seeing no support from anyone else for your proposals here,
so I think it is time to draw this discussion to a close.
Ned