RFC 1652

RFC 1652: SMTP Service Extension for 8bit-MIMEtransport 🎀

okay bestie, this is RFC 1652 💖 and it's called SMTP Service Extension for 8bit-MIMEtransport ✨. It came out of the Network Working Group and it's a Standards Track doc dated July 1994 📅. It obsoletes RFC 1426 🙈.

The authors are J. Klensin (WG Chair, MCI), N. Freed (Editor, Innosoft), M. Rose (Dover Beach Consulting, Inc.), E. Stefferud (Network Management Associates, Inc.), and D. Crocker (Silicon Graphics, Inc.) 👑. The whole squad 🫶

---

Status of this Memo 📜

so this doc is an Internet standards track protocol for the whole Internet community 🧚. They literally want your discussion and suggestions for improvements 💅. For the standardization state and status of this protocol, check the current "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited ✨.

Abstract 🌸

this memo adds an extension to the SMTP service 💌. It lets an SMTP content body made of text with octets outside of the US-ASCII octet range (hex 00-7F) MAY be relayed using SMTP 🫶.

1. Introduction 💖

okay so SMTP is super widely deployed and honestly really robust 💅, but people keep asking for extensions 🙏. A big chunk of the Internet community wants to send messages where the content body is a MIME message [3] full of arbitrary octet-aligned material 📨. This memo uses the mechanism from [5] to define an SMTP service extension so those contents MAY be exchanged 🎀.

quick heads-up though: this extension does NOT get rid of the possibility of an SMTP server limiting line length 🙈. Servers are free to implement this extension but can still set a line length limit no lower than 1000 octets. Since that restriction still applies, this extension does NOT provide a means for transferring unencoded binary via SMTP 💀.

2. 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 for the extension is 8BITMIME;
• (3) no parameter is used with the 8BITMIME EHLO keyword;
• (4) one OPTIONAL parameter using the keyword BODY gets added to the MAIL FROM command. Its value 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. The syntax of the value is below, written in the ABNF notation of [2]:
• (5) no additional SMTP verbs are defined by this extension; and,
• (6) the next section spells out how support for the extension affects the behavior of a server and client SMTP 🧚.

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

3. The 8bit-MIMEtransport service extension 🦋

okay so when a client SMTP wants to submit (using the MAIL command) a content body that's a MIME message with arbitrary lines of 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 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 lines of octet-aligned material. The syntax is identical to the MAIL command in [1], except that a BODY parameter MUST appear after the address. Only one BODY parameter MAY be used in a single MAIL command 💅.

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 syntax for body-value shown above 🧩.

The value tied to the BODY parameter says whether the content body that gets passed using the DATA command is a MIME message with 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 🔥.

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

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

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

<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 lines of 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). This restriction means that this extension MAY provide the necessary facilities for transferring a MIME object with the 8BIT content-transfer-encoding, but it DOES NOT provide a means of transferring an object with the BINARY content-transfer-encoding 🙈.

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 still 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.

4. Usage Example 💬

The following dialogue shows how the 8bit-MIMEtransport service extension gets used:

   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

5. Security Considerations 🚨

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]. Please take that seriously, bestie 💀.

6. Acknowledgements 🫶

this document is a synthesis of lots of people's ideas and of reactions to the ideas and proposals of others 🌸. Randall Atkinson, Craig Everhart, Risto Kankkunen, and Greg Vaudreuil contributed ideas and text good enough to count as 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 🙈. In some cases, the response to a criticism was to accept the problem identification but include a totally different solution from the one originally proposed 💅.

7. 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 1521, Bellcore, Innosoft, September 1993.

[4] Moore, K., "Representation of Non-ASCII Text in Internet Message Headers", RFC 1522, University of Tennessee, September 1993.

[5] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", RFC 1651, MCI, Innosoft, Dover Beach Consulting, Inc., Network Management Associates, Inc., Silicon Graphics, Inc., July 1994.

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

8. Chair, Editor, and Authors' Addresses 💌

here are the people to reach 📮

John Klensin, WG Chair
MCI Data Services Division
2100 Reston Parkway, 6th floor
Reston, VA 22091
USA

Phone:: 1 703 715 7361
Fax: +1 703 715 7435
EMail: klensin@mci.net

Ned Freed, Editor
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA

Phone:: +1 818 919 3600
Fax: +1 818 919 3614
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

Dave Crocker
Silicon Graphics, Inc.
2011 N. Shoreline Blvd.
P.O. Box 7311
Mountain View, CA 94039
USA

Phone: +1 415 390 1804
Fax: +1 415 962 8404
EMail: dcrocker@sgi.com