Network Working Group John Klensin, WG Chair Internet Draft Ned Freed, Editor <draft-ietf-smtpext-8bitmime-00.txt> Marshall Rose Einar Stefferud David Crocker SMTP Service Extension for 8bit-MIMEtransport April 11, 1995 Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). This draft is intended to supercede RFC 1652. The only significant change has been to bring the definition of 8bitMIME into alignment with the definition in the MIME specification. 1. Abstract This memo defines an extension to the SMTP service whereby an SMTP content body consisting of text containing octets outside of the US ASCII octet range (hex 00-7F) may be relayed using SMTP. Internet Draft SMTP 8bit-MIMEtransport April 1995 2. Introduction Although SMTP is widely and robustly deployed, various extensions have been requested by parts of the Internet community. In particular, a significant portion of the Internet community wishes to exchange messages in which the content body consists of a MIME message [3] containing arbitrary octet-aligned material. This memo uses the mechanism described in [5] to define an extension to the SMTP service whereby such contents may be exchanged. Note that this extension does NOT eliminate the possibility of an SMTP server limiting line length; servers are free to implement this extension but nevertheless set a line length limit no lower than 1000 octets. Given that this restriction still applies, this extension does NOT provide a means for transferring unencoded binary via SMTP. 3. Framework for the 8bit MIME Transport Extension The 8bit MIME transport extension is laid out as follows: (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 associated with this parameter is a keyword indicating 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 as follows, using the ABNF notation of [2]: body-value ::= "7BIT" / "8BITMIME" (5) no additional SMTP verbs are defined by this extension; and, Expires October 1995 [Page 2]
Internet Draft SMTP 8bit-MIMEtransport April 1995 (6) the next section specifies how support for the extension affects the behavior of a server and client SMTP. 4. The 8bit-MIMEtransport service extension When a client SMTP wishes to submit (using the MAIL command) a content body consisting of a MIME message containing 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 indicating that it supports the extended MAIL command and will accept MIME messages that use the capabilities of the 8bit MIME content-transfer-encoding. The extended MAIL command is issued by a client SMTP when it wishes to transmit a content body consisting of a MIME message containing arbitrary lines of octet-aligned material. The syntax for this command 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 associated with the BODY parameter indicates whether the content body which will be passed using the DATA command consists of a MIME message containing some 8-bit material ("8BITMIME") in accordance with [3] 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 that a content which contains the five-character sequence of <CR> <LF> <DOT> <CR> <LF> or a content that begins with the three-character sequence of Expires October 1995 [Page 3]
Internet Draft SMTP 8bit-MIMEtransport April 1995 <DOT> <CR> <LF> does not prematurely terminate the transfer of the content. Further, it should be noted that the CR-LF pair immediately preceeding the final dot is considered part of the content. Finally, although 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, 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 with values greater than hex 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 nevertheless 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. Expires October 1995 [Page 4]
Internet Draft SMTP 8bit-MIMEtransport April 1995 5. Usage Example The following dialogue illustrates the use of the 8bit- MIMEtransport service extension: 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 This RFC does not discuss security issues and is not believed to raise any security issues not already endemic in electronic mail and present in fully conforming implementations of [1]. 7. Acknowledgements This document represents a synthesis of the ideas of many people and reactions to the ideas and 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 the individuals are necessarily responsible for the combination of Expires October 1995 [Page 5]
Internet Draft SMTP 8bit-MIMEtransport April 1995 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] J.B. Postel. Simple Mail Transfer Protocol. Request for Comments 821, (August, 1982). [2] D.H. Crocker. Standard for the Format of ARPA Internet Text Messages. Request for Comments 822, (August, 1982). [3] N.S. Borenstein, N. Freed. Multipurpose Internet Mail Extensions. Request for Comments 1521, (September, 1993). [4] K. Moore. Representation of Non-ASCII Text in Internet Message Headers. Request for Comments 1522, (September, 1993). [5] M.T. Rose, E.A. Stefferud, D.H. Crocker, J.C. Klensin, N. Freed. SMTP Service Extensions. Internet-Draft, (April, 1995). [6] C. Partridge. Mail Routing and the Domain System. Request for Comments 974, (January, 1986). Expires October 1995 [Page 6]
Internet Draft SMTP 8bit-MIMEtransport April 1995 9. Chair, Editor, and Author Addresses John Klensin, WG Chair MCI 2100 Reston Parkway Reston, VA 22091 tel: +1 703 715-7361 fax: +1 703 715-7436 email: klensin@mci.net Ned Freed, Editor Innosoft International, Inc. 1050 East Garvey Avenue South West Covina, CA 91790 USA tel: +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 tel: +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 tel: +1 714 842 3711 fax: +1 714 848 2091 email: stef@nma.com Dave Crocker Brandenburg Consulting 675 Spruce Dr. Sunnyvale, CA 94086 USA USA tel: +1 408 246 8253 fax: +1 408 249 6205 email: dcrocker@mordor.stanford.edu Expires October 1995 [Page 7]
