[imp] Content transfer encoding

[Bjørn Mork]

Michael M Slusarz <slusarz at horde.org> writes:

> RFC 1652 deals with SMTP servers.  This is irrelevant for IMP.  You  
> need to look at RFC 2822 which defines the format for a valid e-mail  
> message and, more specifically, Section 2.1 which states:
>
> 2.1. General Description
>
>     At the most basic level, a message is a series of characters.  A
>     message that is conformant with this standard is comprised of
>     characters with values in the range 1 through 127 and interpreted as
>     US-ASCII characters [ASCII].

And continues further down:

   Note: This standard specifies that messages are made up of characters
   in the US-ASCII range of 1 through 127.  There are other documents,
   specifically the MIME document series [RFC2045, RFC2046, RFC2047,
   RFC2048, RFC2049], that extend this standard to allow for values
   outside of that range.  Discussion of those mechanisms is not within
   the scope of this standard.


And those documents allow "Content-Transfer-Encoding: 8bit" if the
underlying transport supports it, which a MTA may according to RFC2821
and RFC1652

>> When viewing the message headers with IMP4, it's the very first one  
>> displayed. Right now, the messages I send all have  
>> "Content-Transfer-Encoding: quoted-printable".
>
> You must encode (either base64 or Q-P) to create a RFC 2822 complaint  
> message.  This is what we do.

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?


Bjørn
-- 
I couldn't care less about your venture capitalist