On Fri, 16 Aug 1991 11:15:59 -0700, david(_at_)twg(_dot_)com wrote:
We can outlaw it, but we are building a spec which allows one to put
an arbitrary file into a part of a message. People will do this to
mail files. Gateways will be programmed to do it too.
Why do you want to outlaw this?!?
Nobody is talking about outlawing mailing arbitrary files.
We are talking about outlawing double-encoding of message contents. The only
justification given for double-encoding is that it is easier for 8->7 mail
gateways to encode an entire message in QUOTED-PRINTABLE or BASE64 rather than
understand which contents require encoding and which do not.
The burden that is imposed by this is that the physical structure of the
message -- its envelope and body structure -- is hidden by such an operation
because headers themselves get encoded. It is impossible to learn the
physical structure of a double-encoded message without a decoding operation on
the entire message, even if there is no particular interest in the actual
contents at that point.
This is, in my opinion, an unacceptable burden on the UA's. Furthermore, it
requires that *every* recipient of such a message do the double-decoding, all
to benefit one lazy gateway and its lazier implementor. Even more damning,
the whole reason for this exercise is to satisfy those people who religiously
push the concept 8-bit MTA's in spite of the fact that there is NO ADDED
FUNCTIONALITY in doing so.
This is nothing more than the long-discredited and rejected "wretched
compromise" of the St Louis IETF coming back to haunt us.
It's been a lot of fun bashing Prime for going off on their own with 8-bit
only MTA's and RFC-1154, but at least they have a consistant and clean
implementation that parses a message in less than a week. RFC-1154 has major
flaws (which I and others went into in nauseating detail), but it works and
works well within the assumptions it makes. As a former RFC-1154 implementor,
I was dissatisfied with it; I strongly supported the RFC-XXXX effort, and I
joined in condemnation of Prime's thumbing its nose at the standards process.
However, with the current direction IETF-822/SMTP is going, RFC-1154 is
starting to look better all the time.