Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME
RFC 1428

Document Type RFC - Informational (February 1993; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 1428 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                       G. Vaudreuil
Request for Comments: 1428                                          CNRI
                                                           February 1993

                   Transition of Internet Mail from
                              Just-Send-8
                           to 8bit-SMTP/MIME

Status of this Memo

   This RFC provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this memo is
   unlimited.

Abstract

   Protocols for extending SMTP to pass 8bit characters have been
   defined [3] [4]. These protocols require that messages transported by
   the extended SMTP are to be encoded in MIME [1] [2].  Before work
   began on these protocols, several SMTP implementations adopted ad-hoc
   mechanisms for sending 8bit data. It is desirable for the extended
   SMTP environment and these ad hoc mechanisms interoperate.  This
   document outlines the problems in this environment and an approach to
   minimizing the cost of transition from current usage of non-MIME 8bit
   messages to MIME.

1. Terminology

   RFC 821 defines a 7bit transport.  A transport agent which does not
   clear the high order bit upon receipt of octets with this bit set in
   SMTP messages is called 8 bit transparent in this document. An
   implementation of the general SMTP Extensions document [3] and the
   8bit extensions protocol [4] which passes MIME messages using all 8
   bits of an octet is called 8bit ESMTP.  An implementation of extended
   SMTP which does not accept 8bit characters is called 7bit ESMTP.  A
   gateway is defined to be a transport agent with User Agent authority
   to alter or convert the content of a message.

2. The Problem

   SMTP as defined in RFC 821 limits the sending of Internet Mail to
   US-ASCII [5] characters.  As the Internet has grown to include non-
   English correspondents, the need to communicate with character sets
   other than US-ASCII has prompted many vendors and users to extend
   SMTP or RFC 822 to use non-ASCII character sets.  Common approaches
   are to send 7 bit national variant ISO 646 character sets over
   current RFC822/SMTP, to extend SMTP and RFC822 to use 8bit ISO 8859

Vaudreuil                                                       [Page 1]
RFC 1428              Transition to 8bit-SMTP/MIME         February 1993

   character sets, and to use proprietary PC character sets.

   A third approach is used for Japanese mail.  Japanese characters are
   represented by pairs of octets with the high order bit cleared.
   Switching between 14 bit character sets and 7 bit character sets is
   indicated within the message by ISO 2022 escape sequences.

   So long as these implementations can communicate without intermediate
   transformations and have a loose private agreement on the use of a
   specific character set without tagging, basic mail service can be
   provided.

   In the transition to the negotiated 8bit ESMTP/MIME environment, it
   is important that mail sent by a currently non-conforming user can be
   read by another non-conforming user.  This existing functionality is
   reduced by conversion from 8bit text to text encoded in unreadable
   Base-64 or "garbled" text encoded in quoted printable.

   There are several interesting non-interoperable cases that currently
   exist in non US-ASCII mail and several new ones likely to emerge in a
   transition to 8bit/MIME.  Below is a listing of the transition-to-
   mime cases.  Only solutions to (4) in the context of a translating
   gateway are discussed in this memo.

                \ Receiver
                  \    7bit     8bit          MIME/
             Sender \| only   | transparent | ESMTP
           ----------------------------------------
           7bit only |  (1)   |    (1)      | (1)
           ----------------------------------------
    8bit transparent |  (2)   |    (3)      | (4)
           ----------------------------------------
          MIME/ESMTP |  (5)   |    (5)      | (6)

   (1) 7Bit non-MIME sender to 7bit, MIME, or 8bit transparent receiver

      This will continue to work unchanged with nationally varient ISO
      646 or ISO 2022 character set shifting if an external "out of
      band" agreement exists between the sender and the receiver.  A
      7bit to 8bit/ESMTP gateway need not alter the content of this
      message.

   (2) 8bit sender to 7bit non-MIME receiver

      The receiver will receive bit-stripped mail which results in the
      mis-interpretation of the data and the wrong character being
      displayed or printed.  Mail sent using languages where most

Vaudreuil                                                       [Page 2]
RFC 1428              Transition to 8bit-SMTP/MIME         February 1993

      characters are in the US-ASCII subset of ISO 8859 may be somewhat
      readable.

   (3) 8bit transparent sender to 8bit transparent receiver
Show full document text