Internet Engineering Task Force (IETF) J. Klensin Request for Comments: 6152 STD: 71 N. Freed Obsoletes: 1652 Oracle Category: Standards Track M. Rose ISSN: 2070-1721 Dover Beach Consulting, Inc. D. Crocker, Ed. Brandenburg InternetWorking March 2011 SMTP Service Extension for 8-bit MIME Transport
AbstractThis 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. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6152. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
RFC2045][RFC2046][RFC5322] containing arbitrary octet- aligned material. This memo uses the mechanism described in the SMTP specification [RFC5321] 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. RFC5321]) or a MIME message (in strict compliance with [RFC2046] and [RFC2045]) with arbitrary octet content is being sent. The syntax of the value is as follows, using the ABNF notation of [RFC5234]: body-value = "7BIT" / "8BITMIME" 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.
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 containing arbitrary octet- aligned material. 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 RFC 5321, 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 RFC 5321. 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 that will be passed using the DATA command consists of a MIME message containing some arbitrary octet-aligned material ("8BITMIME") or is encoded entirely in accordance with RFC 5321 ("7BIT"). A server that 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 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, 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 can allow as few as 1000 octets, inclusive of the CR-LF pair, on a single line). This restriction means that this extension provides 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 that contains characters outside of 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 7-bit MIME, or second, it may treat the barrier to 8-bit as a permanent error and handle it in the usual manner for delivery failures. The specifics of the transformation from 8-bit MIME to 7-bit 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 7-bit MIME.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.