Autor: Alan J. Flavell Data: A: Marc Sherman CC: Exim Users Mailing List Assumpte: Re: [exim] Outlook confuses EXIM + SA
On Mon, 4 Apr 2005, Marc Sherman wrote:
> Peter Velan wrote:
[this is a bit OT for an MTA discussion list, but I'm afraid I
consider it sufficiently important to do a bit of stirring...]
> > Ok, thanks for answers regarding the mail-header. But there's no
> > 'Content-Type', no 'charset' and no 'Content-Transfer-Encoding' in
> > the header. Then, could above body easily be decoded by popular
> > non-MS MUAs?
Indeed, uuencoding was a feature of pre-MIME formats. It's at least
arguable that if properly-formed MIME headers are present (with a
content-type typically of text/plain) then it authoritiatively
excludes the possibility that the body content contains any kind of
attachment. If the sender intends there to be any uuencoding, then
they *ought* to arrange to send the thing with the headers which would
have been appropriate in pre-MIME days, and only then should client
software be willing to react on the appropriate trigger. If they use
MIME headers, on the other hand, then MIME defines a proper format for
attachments, and they should d*mned-well use it.
> The "garbage" you include there is a uuencoded file; back in the old
> days, the mua wasn't responsible for decoding that at all, but
> rather the user would recognize it themselves and pipe the mail
> through uudecode to get the Gemm.pdf file.
Which of course they could still do today, if necessary to rescue
some uuencoded stuff from the body of a mail that has arrived with
MIME headers. All that I'm saying is that it's a foul move for any
client software to unilaterally start decoding what appears to be
uuencoding, when the MIME header says it's plain text. The MIME
headers, if present, are authoritative, and it's no business of client
software to go second-guessing them.
See the definition of the text/plain media type in RFC2046 section
4.1.3: this:
indicates plain text that does not contain any formatting commands or
directives. Plain text is intended to be displayed "as-is", that is,
no interpretation of embedded formatting commands, font attribute
specifications, processing instructions, interpretation directives,
or content markup should be necessary for proper display.
Seems utterly clear to me.
> Many MUAs now recognize a uuencoded file included directly in the
> body of the message, and interpret it as an attachment.
One "MUA" in particular has been a serial offender, and I can't
begin to tell you what I think of that.