draft SMTP 8bit-cleanliness Oct 92 SMTP Service Extension for 8bit-cleanliness Fri Oct 16 23:17:52 1992 Einar A. Stefferud Network Management Associates, Inc. stef@nma.com David H. Crocker The Branch Office dcrocker@mordor.stanford.edu Marshall T. Rose Dover Beach Consulting, Inc. mrose@dbc.mtview.ca.us 1. 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 valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. (The file 1id-abstracts.txt on nic.ddn.mil describes the current status of each Internet Draft.) It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "work in progress". 2. Abstract This memo defines an extension to the SMTP service whereby an SMTP content body containing octets outside of the US ASCII repertoire may be relayed using SMTP. Expires April 16, 1993 [Page 1]
draft SMTP 8bit-cleanliness Oct 92 3. Introduction The Simple Mail Transfer Protocol (SMTP) [1] has provided a stable, effective basis for the relay function of message transfer agents. Although a decade old, SMTP has proven remarkably resilient. 4. Framework for SMTP Extensions For the purpose of service extensions to the SMTP, SMTP relays a mail object containing an envelope and a content. (1) The SMTP envelope is straight-forward, and is sent as a series of SMTP protocol units: it consists of an originator address (to which error reports should be directed); a delivery mode (e.g., deliver to recipient mailboxes); and, one or more recipient addresses. (2) The SMTP content is sent in the SMTP DATA protocol unit and has two parts: the headers and the body. The headers form a collection of field/value pairs structured according to RFC 822 [2], whilst the body, if structured, is defined according to MIME [3]. The content is textual in nature, expressed using the US ASCII repertoire (ISO registered character set number 6). Although extensions (such as MIME) may relax this restriction for the content body, the content headers are always encoded using the US ASCII repertoire. The algorithm defined in [4] is used to represent header values outside the US ASCII repertoire, whilst still encoding them using the US ASCII repertoire. Although SMTP is widely and robustly deployed, some parts of the Internet community might wish to extend the SMTP service. In particular, a significant portion of the Internet community wishes to exchange messages in which the content body contains 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: (1) the name of the SMTP service extension is 8bit- cleanliness; Expires April 16, 1993 [Page 2]
draft SMTP 8bit-cleanliness Oct 92 (2) the EHLO keyword value associated with the extension is 8BIT; (3) the syntax of the parameter (using the ABNF notation of [2]) associated with this EHLO keyword value is: 8bit-param ::= "CONVERT" / "NOCONVERT" / "MIME" (4) the next section specifies how support for the extension affects the behavior of a server and client SMTP. 5. The 8bit-cleanliness service extension When a client SMTP wishes to relay (using the MAIL command) a content body which contains 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 8BIT, then the server SMTP is indicating that it supports the extended MAIL command and will accept some types of octet-aligned material. If the parameter associated with the EHLO keyword value 8BIT is "MIME", then the client SMTP may transmit a content body containing octet-aligned material only if it is structured according to the rules given in [3] (i.e., any body part containing arbitrary octet-aligned material is tagged with a Content-Transfer-Encoding header field). Otherwise, if the parameter associated with the EHLO keyword value 8BIT is "CONVERT" or "NOCONVERT", then the client SMTP is permitted to transmit a content body containing arbitrary octet-aligned material to the server SMTP. The extended MAIL command is issued by a client SMTP when it wishes to transmit a content body containing arbitrary octet- aligned material. The syntax for this command is identical to the MAIL command in [1], except that a BODY parameter may appear after the address. The syntax of the extended MAIL command (using the ABNF notation of [2]) is: email-cmd ::= "MAIL FROM:<" reverse-path ">" body-param body-param ::= SPACE "BODY=" ( "USASCII" / "OCTET" ) Expires April 16, 1993 [Page 3]
draft SMTP 8bit-cleanliness Oct 92 The value associated with the BODY parameter indicates whether the content body which will be passed using the DATA command contains some arbitrary octet-aligned material ("OCTET") or is encoded entirely in US ASCII ("ASCII"). A server which supports the 8-bit cleanliness 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 <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 octet- aligned material, the length of each line (number of octets between two CR-LF pairs), must not exceed 1000 characters, as specified in [1]. Once a server SMTP supporting the 8bit-cleanliness 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 the path to the next hop (or a recipient's user agent) is not known to preserve all bits in each octet, then the behavior of the server SMTP depends on the parameter associated with the EHLO keyword value 8BIT. If the parameter had the value "CONVERT" or "MIME", then the server SMTP must transform the content body (as described in Section 5.1). Otherwise, if the parameter had the value "NOCONVERT", then this is treated as a permanent error, and is handled in the usual manner for delivery failures for that server SMTP. Expires April 16, 1993 [Page 4]
draft SMTP 8bit-cleanliness Oct 92 If a server SMTP does not support the 8-bit cleanliness extension (either by not responding with code 250 to the EHLO command, or by not including the EHLO keyword value 8BIT in its response), then the client SMTP must not, under any circumstances, attempt to transfer a content which contains characters outside the US ASCII repertoire. A client SMTP has two options in this case: first, it may seek another server SMTP to act as a mail relay for the current recipients (according to the rules of [6]), and which supports the 8-bit cleanliness extension (this might result in the message being re-queued by the client SMTP); or, it may implement the gateway transformations described in Section 5.1. If neither option is available, then this is treated as a permanent error, and is handled in the usual manner for delivery failures for that server SMTP. 5.1. Client SMTP performing gateway transformations If the client SMTP chooses to operate as a mail domain gateway, then it first examines the content headers looking for two header fields: MIME-Version and Content-Type. If both are present, and if the content-type associated with the latter is either Multipart or Message, then the client SMTP recursively examines, and if necessary, transforms, the transfer encodings of the body parts contained therein. For example, if only one part of a multipart content-type is encoded using characters outside of the US ASCII repertoire, then only that part is transformed. Otherwise, if the content-type is neither Multipart nor Message (or lacks the MIME-Version and/or Content-Type fields), then the client SMTP applies either the quoted- printable or base64 transfer-encoding to the content body. (The choice of transfer-encoding is at the discretion of the client SMTP.) The Content-Transfer-Encoding field in the content headers is changed to reflect the transfer-encoding in use, as specified in [3]. (If this field is not present, then it is added.) If a MIME-Version field is not present, then it is added, i.e., MIME-Version: 1.0 If a Content-Type field is not present, then it, along with a Content-Description field, shall be added, specifically: i.e., Expires April 16, 1993 [Page 5]
draft SMTP 8bit-cleanliness Oct 92 Content-Type: application/octet-stream Content-Description: untagged data converted to MIME After transforming the content body, the client SMTP determines if any textual components of the content headers contain characters outside of the US ASCII repertoire. If so, these are transformed using the rules defined in [4]. However, since no information is available as to the repertoire in use, the charset value of "unknown" is used. For each word encoded, the choice of applying either the "Q" or "B" transfer-encoding lies with the client SMTP. Finally, the client SMTP adds trace information to the content headers. This takes the form of a single Received: field placed above any other such fields in the content headers. This new field should indicate the nature of the transformation which was applied, using a "with" phrase, with a value of "binary-to-base64" or "binary-to-quoted", e.g., Received: from baiji.dbc.mtview.ca.us by dbc.mtview.ca.us with binary-to-base64 ; Tue, 01 Sep 1992 01:18:00 -0700 6. Acknowledgements The authors acknowledge the comments of Harald T. Alvestrand, Ned Freed, John C. Kleinsen, Keith Moore, Neil W. Rickert, and, John Wagner. 7. 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 1341, (June, 1992). Expires April 16, 1993 [Page 6]
draft SMTP 8bit-cleanliness Oct 92 [4] K. Moore. Representation of Non-ASCII Text in Internet Message Headers. Request for Comments 1342, (June, 1992). [5] M.T. Rose, E.A. Stefferud, D.H. Crocker. SMTP Service Extensions. Internet-Draft, (September, 1992). [6] C. Partridge. Mail Routing and the Domain System. Request for Comments 974, (January, 1986). Expires April 16, 1993 [Page 7]