Date: Wed, 12 Feb 92 11:02:07 +0100
From: "Alain FONTAINE (Postmaster - UCL)"
<fontaine(_at_)sri(_dot_)ucl(_dot_)ac(_dot_)be>
Subject: Re: A bad journey (an apocryphal war story)
To: Keith Moore <moore(_at_)cs(_dot_)utk(_dot_)edu>
Cc: MIME <ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu>
On Tue, 11 Feb 92 09:50:09 EST you said:
I thought I had understood from the discussion in Santa Fe that an
(unescaped) end-of-line in quoted printable was always to be interpreted
as 0D hex, 0A hex, regardless of the local convention for representing
ends-of-lines in text files. I don't see this spelled out quite so
clearly in the current MIME draft.
Quoted-printable has strictly no technical raison d'etre. It has been
introduced to allow encoded text to be somewhat visible.
Well, some would argue that quoted-printable exists because it is a safe
way of transmitting "text files" through email, that is more efficient
than base64.
If only the
presence of x'0D0A' in the text can produce a (hard) line break in the
encoding, quoted-printable produced by machines using anything else
internally to delimit lines will not contain any hard line-breaks.
Makes the encoding rather difficult to read. But there is more :
the line structure of the text will be lost when decoded on a machine
using another local convention. Or am I goofing once again ?
Anytime you send a "text" body part through email there is an implicit
conversion from "local" format to "network" format, that occurs before
any content-transfer-encoding takes place. For text files on UNIX
systems, this means replacing every newline character with a CR LF pair.
When such a message is received, the CR LF pair is understood to be
an end-of-line marker, and is translated into the recipient's system's
convention for newline in text files.
This has nothing to do with quoted printable. It just happens that in
quoted-printable, the sequence 0D 0A is represented as "end-of-line".
However, it wouldn't hurt to restrict the types of conversion that can
be done by a relaying MTA. Such conversions should always be to a
"safer" format. So, ordering the content-transfer-encodings as follows:
BINARY
8BIT QUOTED-PRINTABLE BASE64
7BIT
you can only convert to something further to the right.
Does not help at all. Suppose, in my example, that host A sends
quoted-printable. The encoding would then be :
ABBP=0D
8=0Fj6z=e0*O<
If the gateway decodes and reincodes in base64, the final result will be :
41 42 42 50 0D 0D 0A 38 0F 6A 36 7A E0 2A 4F 3C
The gateway has done the right thing; it is the original encoding that is
wrong. The original message of
41 42 42 50 0D 0A 38 0F 6A 36 7A E0 2A 4F 3C
should instead have been encoded as
ABBP
8=0Fj6z=e0*O<
(or perhaps ABBP=0D=0A8=0Fj6z=e0*O<)
Keith