Transition of Internet Mail from Just-Send-8 to 8bit-SMTP/MIME (RFC1428)
Original Publication Date: 1993-Feb-01
Included in the Prior Art Database: 2019-Feb-10
Internet Society Requests For Comment (RFCs)
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. This RFC provides information for the Internet community. It does not specify an Internet standard.
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.
Protocols for extending SMTP to pass 8bit characters have been defined  . These protocols require that messages transported by the extended SMTP are to be encoded in MIME  . 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.
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  and the 8bit extensions protocol  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  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...