[imp] Content transfer encoding

[Jaap Winius]

Quoting Bjørn Mork <bmork at dod.no>:

> I fully agree with you that you encoding is the only way to ensure that
> a message can be delivered without any relay or gateway MTA altering the
> body, and that such altering really should be a no-no.  But the fact is
> that RFC 2822 does allow you to send 8bit bodies, by its references to
> RFC2045 etc, as long as the local mail server supports the 8BITMIME
> extension.
>
> I'm not sure that such a feature would be useful, though.  Maybe Jaap
> could explain the problems cased by encoded bodies?

Problems? There shouldn't be any. If one MTA has a message with 8bit  
content to send and finds out that the receiving MTA doesn't support  
that (no 250-8BITMIME ESMTP response), it translates the contents  
first (e.g. to Q-P) before sending the message. Therefore, nothing  
ever gets munged. The encoding may be modified, but to the user on the  
receiving end the message will look the same.

One of the main advantages of 8bit encoding is efficiency. For example:

    8bit;
    à á â ã ä å

    Base64;
    w6Agw6Egw6Igw6Mgw6Qgw6U=

    Q-P;
    =C3=A0 =C3=A1 =C3=A2 =C3=A3 =C3=A4 =C3=A5

Note: Base64 is more efficient than Q-P, but it's also a format  
favored by spammers, since those message sections are ignored by older  
anti-spam software.

Besides efficiency, it was recently argued in the Pine newsgroup that  
8bit encoding may also be seen as a solution for people who are  
worried about their Base64 or Q-P content getting munged, since there  
is no safe way to transport these encodings except within a multipart.  
The latter provides bounds for the encoded content that should have  
been, but was not part of Base64 and/or Q-P content. The poster felt  
that that this should have been mandatory for use with MIME. 8Bit  
ESMTP, he said, is the legitimate way to avoid the multipart.

Cheers,

Jaap