RFC 1426

SMTP Service Extension for 8bit-MIMEtransport 💌

Okay bestie, the title block tea first ☕ This is RFC 1426, dated February 1993, from the Network Working Group. Its category is an IAB standards track protocol (more on that in the Status part 👀). The crew behind it:

• J. Klensin, WG Chair, United Nations University 👑
• N. Freed, Editor, Innosoft International, Inc. ✍️
• M. Rose, Dover Beach Consulting, Inc. 🌸
• E. Stefferud, Network Management Associates, Inc. 🦋
• D. Crocker, The Branch Office 🎀

The title block doesn't list anything this RFC obsoletes or updates, so no drama there 🙅

---

Status of this Memo 💅

This RFC is an IAB standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 Check the current edition of the "IAB Official Protocol Standards" for the standardization state and status of this protocol. Distribution of this memo is unlimited 🌈

1. Abstract ✨

This memo defines an extension to the SMTP service so that an SMTP content body with octets outside of the US ASCII octet range (hex 00-7F) may be relayed using SMTP. Iconic, right? 💖

2. Introduction 🦋

Okay so SMTP is super widely and robustly deployed, and honestly it's a whole icon 💅 But people keep asking for extras. A big chunk of the Internet wants to send messages whose body is a MIME message [3] full of arbitrary octet-aligned material 📨 This memo uses the mechanism from [5] to add an extension to the SMTP service so that kind of content can be exchanged.

Now the important bit 🙈 Note that this extension does NOT eliminate the possibility of an SMTP server limiting line length. Servers are free to implement this extension, but they can still set a line length limit no lower than 1000 octets.

3. Framework for the 8bit MIME Transport Extension 🧚

The 8bit MIME transport extension is laid out like this:

1. the name of the SMTP service extension defined here is 8bit-MIMEtransport;
2. the EHLO keyword value associated with the extension is 8BITMIME;
3. no parameter is used with the 8BITMIME EHLO keyword;
4. one OPTIONAL parameter using the keyword BODY is added to the MAIL FROM command. The value of this parameter is a keyword saying whether a 7bit message (in strict compliance with [1]) or a MIME message (in strict compliance with [3]) with arbitrary octet content is being sent;
5. no additional SMTP verbs are defined by this extension; and,
6. the next section specifies how support for the extension affects the behavior of a server and client SMTP.

Here's the syntax for the value, written in the ABNF notation of [2]:

body-value ::= "7BIT" / "8BITMIME"

4. The 8bit-MIMEtransport service extension 💜

So when a client SMTP wants to submit (using the MAIL command) a content body that's a MIME message with arbitrary octet-aligned material, it first issues the EHLO command to the server SMTP. If the server SMTP responds with code 250 to the EHLO command, and the response includes the EHLO keyword value 8BITMIME, then the server SMTP is basically saying it supports the extended MAIL command and will accept MIME messages containing arbitrary octet-aligned material 🎀

The extended MAIL command is issued by a client SMTP when it wants to transmit a content body that's a MIME message containing arbitrary octet-aligned material. The syntax is identical to the MAIL command in [1], except that a BODY parameter MUST appear after the address.

The complete syntax of this extended command is defined in [5]. The esmtp-keyword is BODY, and the syntax for esmtp-value is given by the body-value syntax shown above.

The value of the BODY parameter tells you whether the content body passed using the DATA command is a MIME message containing some arbitrary octet-aligned material (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. This is the core promise, bestie 🧠

Naturally, the usual SMTP data-stuffing algorithm applies, so that content containing the five-character sequence:

<CR> <LF> <DOT> <CR> <LF>

or content that begins with the three-character sequence:

<DOT> <CR> <LF>

does not prematurely terminate the transfer of the content. Further, it should be noted that the CR-LF pair immediately preceding the final dot is considered part of the content. Finally, even though 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, it 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, but the conversion is still constrained in the following ways:

1. it MUST cause no loss of information; MIME transport encodings MUST be employed as needed to ensure this is the case, and
2. the resulting message MUST be valid 7bit MIME.

5. Usage Example 🎬

The following dialogue shows the 8bit-MIMEtransport service extension in action:

S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 dbc.mtview.ca.us SMTP service ready
C: EHLO ymir.claremont.edu
S: 250-dbc.mtview.ca.us says hello
S: 250 8BITMIME
C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME
S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok
C: RCPT TO:<mrose@dbc.mtview.ca.us>
S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok
C: DATA
S: 354 Send 8BITMIME message, ending in CRLF.CRLF.
 ...
C: .
S: 250 OK
C: QUIT
S: 250 Goodbye

6. Security Considerations 🔐

Plot twist 😱 This RFC does not discuss security issues. It is not believed to raise any security issues that aren't already endemic in electronic mail and already present in fully conforming implementations of [1]. So please keep that in mind as you read on, because the stakes are real and you do not want to get this part wrong. 💀

7. Acknowledgements 🫶

This document is a synthesis of the ideas of many people, plus the reactions to those ideas and to the proposals of others. Randall Atkinson, Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas and text sufficient to be considered co-authors 👏 Other important suggestions, text, or encouragement came from Harald Alvestrand, Jim Conklin, Mark Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per Hedeland, Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John Wagner, Rayan Zachariassen, and the contributions of the entire IETF SMTP Working Group. Of course, none of these individuals are necessarily responsible for the combination of ideas represented here. Indeed, in some cases, the response to a particular criticism was to accept the problem identification but to include an entirely different solution from the one originally proposed. 🙌

8. References 📚

[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982.

[2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, UDEL, August 1982.

[3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail Extensions", RFC 1341, Bellcore, Innosoft, June 1992.

[4] Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1342, University of Tennessee, June 1992.

[5] 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.

[6] Partridge, C., "Mail Routing and the Domain System", RFC 974, BBN, January 1986.

9. Chair, Editor, and Authors' Addresses 📬

Here are the contact details exactly as the original lists them, including the "Moutain View" spelling 🙈

John Klensin, WG Chair
United Nations University
PO Box 500, Charles Street Station
Boston, MA 02114-0500  USA

Phone: +1 617 227 8747
Fax: +1 617 491 6266
Email: klensin@infoods.unu.edu


Ned Freed, Editor
Innosoft International, Inc.
250 West First Street, Suite 240
Claremont, CA 91711  USA

Phone: +1 909 624 7907
Fax: +1 909 621 5319
Email: ned@innosoft.com

Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Moutain View, CA  94043-2186  USA

Phone: +1 415 968 1052
Fax: +1 415 968 2510
Email: mrose@dbc.mtview.ca.us


Einar A. Stefferud
Network Management Associates, Inc.
17301 Drey Lane
Huntington Beach, CA, 92647-5615  USA

Phone: +1 714 842 3711
Fax: +1 714 848 2091
Email: stef@nma.com


David H. Crocker
The Branch Office
USA

Email: dcrocker@mordor.stanford.edu