draft SMTP 8bit-cleanliness Sep 92 SMTP Service Extension for 8bit-cleanliness Thu Sep 10 08:32:12 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 which contains non-ASCII octets may be relayed using SMTP. Expires March 10, 1993 [Page 1] draft SMTP 8bit-cleanliness Sep 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. From SMTP's perspective, it relays a mail object containing an envelope and a content. (1) The SMTP envelope is straight-forward: 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 has two parts: the headers and the body. The former is a collection of field/value pairs structured according to RFC 822 [2], whilst the latter, if structured, is defined according to MIME [3]. The content is textual in nature, expressed 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, although structured according to the rules of RFC 822, contains arbitrary octet-aligned material. This memo uses the mechanism described in [4] 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; (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" (4) the next section specifies how support for the extension affects the behavior of a server and client SMTP. Expires March 10, 1993 [Page 2] draft SMTP 8bit-cleanliness Sep 92 4. The 8bit-cleanliness service extension When a client SMTP wishes to relay (using the MAIL command) a content 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 client SMTP may transmit the content using the normal SMTP procedures. 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 does not prematurely terminate the transfer of the content. Further, it should be noted that the CR-LF pair immediately preceeding the final dot are considered part of the content. Finally, although the content 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 such a server SMTP accepts a content containing, or presumed to contain, octets with the high-order 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 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", then the server SMTP must transform the content (as described in Section 4.1). Otherwise, if the parameter had the value "NOCONVERT", then this is treated as a permanent error: if an originator address is present in the envelope, then an error report is generated; regardless, the message is discarded. 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 Expires March 10, 1993 [Page 3] draft SMTP 8bit-cleanliness Sep 92 characters outside the US ASCII repertoire. A client SMTP has two options in this case: first, it may seek to find another server SMTP, eligible to act as a mail relay for the current recipients (according to the rules of [5]), and which supports the 8-bit cleanliness extension (this might result in the message being re-queued by the client SMTP); or, it may choose to operate as a mail domain gateway (as described in Section 4.1). If neither option is available, then this is treated as a permanent error: if an originator address is present in the envelope, then an error report is generated; regardless, the message is discarded. 4.1. Client SMTP acting as a Mail Domain Gateway If the client SMTP chooses to operate as a mail domain gateway, then it first examines the headers of the content 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 body parts contained therein. For example, if only one part of a multipart content is encoded using characters outside of the US ASCII repertoire, then only that part is transformed. Otherwise, if the content 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 body of the content. (The choice of transfer-encoding is at the discretion of the client SMTP.) The Content-Transfer-Encoding field in the headers of the content 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, are added, i.e., Content-Type: application/octet-stream Content-Description: untagged data converted to MIME Expires March 10, 1993 [Page 4] draft SMTP 8bit-cleanliness Sep 92 After transforming the body of the content, the client SMTP determines if any textual components of the headers contain non-ASCII characters. If so, these are transformed using the rules defined in [6]. However, since no information is available as to the repertoire in use, the charset value of "x-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 headers of the content. This takes the form of a single Received: field placed above any other such fields in the headers. This new field should indicate the nature of the transformation which was applied, using the "with" phrase, 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 5. Acknowledgements The authors acknowledge the comments of Harald T. Alvestrand, Ned Freed, John C. Kleinsen, Keith Moore, and, Neil W. Rickert. 6. 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). [4] M.T. Rose. SMTP Service Extensions. Internet-Draft, (September, 1992). [5] C. Partridge. Mail Routing and the Domain System. Request for Comments 974, (January, 1986). Expires March 10, 1993 [Page 5] draft SMTP 8bit-cleanliness Sep 92 [6] K. Moore. Representation of Non-ASCII Text in Internet Message Headers. Request for Comments 1342, (June, 1992). Expires March 10, 1993 [Page 6]