RFC 1428

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

• Network Working Group 🌸
• Request for Comments: 1428
• Author: G. Vaudreuil (Greg Vaudreuil) of CNRI 💜
• Date: February 1993 📅
• Status: an informational doc. It provides info for the Internet community and is not an Internet standard 📖
• Obsoletes / Updates: the title block doesn't list anything this RFC obsoletes or updates 🤷‍♀️

---

Status of This Memo 🌈

Okay so this one is purely informational, bestie 💅 It's not a standard. It's just here to give the community the tea. And distribution of this memo is unlimited, so share it with everyone 🦋

Abstract 🦋

Okay, so the protocols for extending SMTP to pass 8bit characters have already been defined [3] [4] ✨ These protocols require that messages transported by the extended SMTP are to be encoded in MIME [1] [2]. Before any of that work started, several SMTP implementations went rogue and adopted ad-hoc mechanisms for sending 8bit data 🙈 It's super desirable that the extended SMTP environment and these ad hoc mechanisms interoperate, and this doc walks through the problems in that environment. It also lays out an approach to minimizing the cost of moving from current non-MIME 8bit messages to MIME 🫶

1. Terminology 📖

RFC 821 defines a 7bit transport. A transport agent that doesn't clear the high order bit when it receives octets with that 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 that doesn't 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 😭

Okay, so SMTP as defined in RFC 821 limits Internet Mail to US-ASCII [5] characters 💀 As the Internet grew to include non-English correspondents, people needed to talk in character sets other than US-ASCII. So lots of vendors and users extended SMTP or RFC 822 to use non-ASCII character sets 🌍 The common approaches are sending 7 bit national variant ISO 646 character sets over current RFC822/SMTP, extending SMTP and RFC822 to use 8bit ISO 8859 character sets, and using proprietary PC character sets 🎀

A third approach is used for Japanese mail, and it's giving main character energy 👑 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 they have a loose private agreement about using a specific character set without tagging, basic mail service can be provided 🦋

In the transition to the negotiated 8bit ESMTP/MIME environment, it matters that mail sent by a currently non-conforming user can still be read by another non-conforming user 😭 Right now that works, and it gets wrecked by converting 8bit text into unreadable Base-64, or into "garbled" quoted printable text 💔

There are several interesting non-interoperable cases that already exist in non US-ASCII mail, and several new ones that will probably pop up during the move to 8bit/MIME 🙈 Here's the 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 keep working unchanged with nationally variant ISO 646 or ISO 2022 character set shifting, as long as 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 gets bit-stripped mail, which means the data gets misinterpreted and the wrong characters show up when it's displayed or printed. Mail written in languages where most characters are in the US-ASCII subset of ISO 8859 might be somewhat readable, though 🥲

(3) 8bit transparent sender to 8bit transparent receiver 🫶

This will work if an external "out of band" agreement exists between the sender and the receiver to use a particular character set without tagging 🌈

(4) 8bit transparent sender to MIME/ESMTP conformant receiver 🔥

This will work if a reasonable upgrade path is provided via gateways, the character set tag the gateway inserts is correct, and the receiver supports the character set the sender chose. This case is the focus of this memo, bestie 🎀

(5) MIME/ESMTP sender to non-MIME 7bit receiver 💀

The ESMTP/MIME sender can't know whether the receiver understands 8bits, so the sender encodes the text into base-64 or quoted-printable, which the receiver may see as "garbled" 😭 To provide a useful downgrade path, the gateway must have some knowledge about the receiver's capabilities. When the character set can be clearly identified, techniques like the mnemonic MNEM encoding described in RFC 1345 may be helpful in this case 🧚

(6) MIME/ESMTP sender to MIME/ESMTP receiver ✨

Interoperability will be attained as long as the receiver supports the character set the sender chose 👑

3. Upgrade Path from 8bit Transparent to ESMTP/MIME 🚀

Okay, so a gateway that's been upgraded to support Extended SMTP may upgrade an 8bit message it receives to MIME 💅 This lines up with the requirement that all 8bit mail sent by ESMTP be encoded in MIME. The upgrade should be done using the best available information 🌸

A site can "upgrade" to MIME en-masse by implementing MIME conversion for all messages leaving the site. For text messages, the body can be converted by adding a MIME-version header and a Content-Type: Text/Plain with the character set in use at the site, as long as the site uses a single character set 🦋

An appropriate Content-Transfer-Encoding header line must be added to indicate any encoding that may be necessary 🫶

Example:

   MIME-Version: 1.0
   Content-Type: Text/Plain; Charset = ISO-8859-1
   Content-Transfer-Encoding: 8bit

If no information about the character set in use is available, the gateway should upgrade the content using the character set unknown-8bit. The unknown-8bit value of the charset parameter only indicates that no reliable information about the character set(s) used in the message was available 🙈

If a message body has been upgraded to MIME, then RFC 822 headers containing non US-ASCII characters must be upgraded to conform with the header encoding rules of RFC1342 🎀 A gateway should recode all unstructured header fields, plus RFC 822 "comment"s and "phrase"s, according to the rules of RFC 1342 💖 RFC 1342 has no equivalent to the "8bit" Content-Transfer-Encoding value for message bodies, so all 8bit header text must be transformed using either the "B" or the "Q" encoding method 😭 For ISO 8859 character sets, the "Q" encoding will generally result in somewhat readable headers ✨

Trace information should be added to the document with a convert clause: rfc822-to-8bit, rfc822-to-base-64, or rfc822-to-quoted-printable, e.g.,

   Received: from dbc.mtview.ca.us by dbc.mtview.ca.us
             convert rfc822-to-8bit; Tue, 01 Sep 1992 01:18:00 -0700

Appendix - The "unknown-8bit" Character Set 📚

This section defines a "charset" parameter for use in a MIME Content-Type field 🌈

A special purpose character set called unknown-8bit is defined to be an unknown 8bit character set, encoded into a sequence of octets 🧚 It can be used as a label for any character set from any language, using any encoding. It must not be further defined 🔒

Using this token in a charset= field of a message indicates that nothing is known about the character set used. This marker is meant for non-MIME to MIME gateways, specifically the ones that translate from SMTP to 8bit ESMTP/MIME 💅

This character set isn't intended for mail composers. It's assumed that the mail composer knows the character set in use and will mark it with a character set value as specified in [1], as amended by current Assigned Numbers documents [6] 🌸

The unknown-8bit label is only meant for mail gateway agents that can't determine the intended character set through out-of-band information 🦋

How unknown-8bit gets interpreted is up to the mail reader. It's assumed that in many cases the human user will be able to make sense of the information and choose an appropriate character set or pre-processor 🫶

Acknowledgements 💜

This document started as a hallway conversation between Ned Freed, Neil Katin, and the author ☕ Substantive input came from Jonathan Laventhol, Craig Everhart, Olle Jarnefors, and Olafur Gudmundsson 🙌 The document was refined with the input of many participants in the IETF SMTP Extensions Working Group 🌟

References 📎

• [1] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1341, Bellcore, Innosoft, June 1992.
• [2] Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1342, University of Tennessee, June 1992.
• [3] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC 1425, United Nations University, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993.
• [4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions for 8bit MIMEtransport", RFC 1426, United Nations University, Innosoft International, Inc., Dover Beach Consulting, Inc., Network Management Associates, Inc., The Branch Office, February 1993.
• [5] Coded Character Set--7-Bit American Standard Code for Information Interchange, ANSI X3.4-1986.
• [6] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340, USC/Information Sciences Institute, July 1992.

Security Considerations 🔒

Security issues are not discussed in this memo. Read that twice, bestie 😭

Author's Address 🌈

Greg Vaudreuil
Corporation for National Research Initiatives
1895 Preston White Drive, Suite 100
Reston, VA 22091 USA

Phone: (703) 620-8990
EMail: GVaudre@CNRI.Reston.VA.US