RFC 1426 (rfc1426) - Page 3 of 6

SMTP Service Extension for 8bit-MIMEtransport

RFC 1426                SMTP 8bit-MIMEtransport            February 1993


   ("8BITMIME") or is encoded entirely in accordance with [1] ("7BIT").

   A server which supports the 8-bit MIME transport service extension
   shall preserve all bits in each octet passed using the DATA command.

   Naturally, the usual SMTP data-stuffing algorithm applies so that a
   content which contains the five-character sequence of

               

   or a content that begins with the three-character sequence of

               

   does not prematurely terminate the transfer of the content.  Further,
   it should be noted that the CR-LF pair immediately preceeding the
   final dot is considered part of the content.  Finally, although the
   content body contains arbitrary octet-aligned material, the length of
   each line (number of octets between two CR-LF pairs), is still
   subject to SMTP server line length restrictions (which may allow as
   few as 1000 octets on a single line).

   Once a server SMTP supporting the 8bit-MIMEtransport service
   extension accepts a content body containing octets with the high-
   order (8th) bit set, the server SMTP must deliver or relay the
   content in such a way as to preserve all bits in each octet.

   If a server SMTP does not support the 8-bit MIME transport extension
   (either by not responding with code 250 to the EHLO command, or by
   not including the EHLO keyword value 8BITMIME in its response), then
   the client SMTP must not, under any circumstances, attempt to
   transfer a content which contains characters outside the US ASCII
   octet range (hex 00-7F).

   A client SMTP has two options in this case: first,  it may implement
   a gateway transformation to convert the message into valid 7bit MIME,
   or second, or may treat this as a permanent error and handle it in
   the usual manner for delivery failures.  The specifics of the
   transformation from 8bit MIME to 7bit MIME are not described by this
   RFC; the conversion is nevertheless constrained in the following
   ways:

          (1)  it must cause no loss of information; MIME transport
               encodings must be employed as needed to insure this is
               the case, and

          (2)  the resulting message must be valid 7bit MIME.




Klensin, Freed, Rose, Stefferud & Crocker