7Internet Engineering Task Force (IETF) J. Klensin
8Request for Comments: 6152
11Category: Standards Track M. Rose
12ISSN: 2070-1721 Dover Beach Consulting, Inc.
14 Brandenburg InternetWorking
18 SMTP Service Extension for 8-bit MIME Transport
22 This memo defines an extension to the SMTP service whereby an SMTP
23 content body consisting of text containing octets outside of the
24 US-ASCII octet range (hex 00-7F) may be relayed using SMTP.
28 This is an Internet Standards Track document.
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Further information on
34 Internet Standards is available in Section 2 of RFC 5741.
36 Information about the current status of this document, any errata,
37 and how to provide feedback on it may be obtained at
38 http://www.rfc-editor.org/info/rfc6152.
42 Copyright (c) 2011 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (http://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
58Klensin, et al. Standards Track [Page 1]
60RFC 6152 SMTP Extension for 8-bit MIME March 2011
65 Although SMTP is widely and robustly deployed, various extensions
66 have been requested by parts of the Internet community. In
67 particular, a significant portion of the Internet community wishes to
68 exchange messages in which the content body consists of a MIME
69 message [RFC2045][RFC2046][RFC5322] containing arbitrary octet-
70 aligned material. This memo uses the mechanism described in the SMTP
71 specification [RFC5321] to define an extension to the SMTP service
72 whereby such contents may be exchanged. Note that this extension
73 does NOT eliminate the possibility of an SMTP server limiting line
74 length; servers are free to implement this extension but nevertheless
75 set a line length limit no lower than 1000 octets. Given that this
76 restriction still applies, this extension does NOT provide a means
77 for transferring unencoded binary via SMTP.
792. Framework for the 8-bit MIME Transport Extension
81 The 8-bit MIME transport extension is laid out as follows:
83 1. the name of the SMTP service extension defined here is
88 3. no parameter is used with the 8BITMIME EHLO keyword;
91 MAIL command. The value associated with this parameter is a
92 keyword indicating whether a 7-bit message (in strict compliance
93 with [RFC5321]) or a MIME message (in strict compliance with
94 [RFC2046] and [RFC2045]) with arbitrary octet content is being
95 sent. The syntax of the value is as follows, using the ABNF
96 notation of [RFC5234]:
98 body-value = "7BIT" / "8BITMIME"
100 5. no additional SMTP verbs are defined by this extension; and
102 6. the next section specifies how support for the extension affects
103 the behavior of a server and client SMTP.
1053. The 8bit-MIMEtransport Service Extension
107 When a client SMTP wishes to submit (using the MAIL command) a
108 content body consisting of a MIME message containing arbitrary lines
109 of octet-aligned material, it first issues the EHLO command to the
110 server SMTP. If the server SMTP responds with code 250 to the EHLO
114Klensin, et al. Standards Track [Page 2]
116RFC 6152 SMTP Extension for 8-bit MIME March 2011
119 command, and the response includes the EHLO keyword value 8BITMIME,
120 then the server SMTP is indicating that it supports the extended MAIL
121 command and will accept MIME messages containing arbitrary octet-
124 The extended MAIL command is issued by a client SMTP when it wishes
125 to transmit a content body consisting of a MIME message containing
126 arbitrary lines of octet-aligned material. The syntax for this
127 command is identical to the MAIL command in RFC 5321, except that a
129 parameter may be used in a single MAIL command.
131 The complete syntax of this extended command is defined in RFC 5321.
132 The esmtp-keyword is BODY, and the syntax for esmtp-value is given by
133 the syntax for body-value shown above.
135 The value associated with the BODY parameter indicates whether the
136 content body that will be passed using the DATA command consists of a
137 MIME message containing some arbitrary octet-aligned material
138 ("8BITMIME") or is encoded entirely in accordance with RFC 5321
141 A server that supports the 8-bit MIME transport service extension
142 shall preserve all bits in each octet passed using the DATA command.
143 Naturally, the usual SMTP data-stuffing algorithm applies, so that a
144 content that contains the five-character sequence of
145 <CR> <LF> <DOT> <CR> <LF>
146 or a content that begins with the three-character sequence of
148 does not prematurely terminate the transfer of the content. Further,
149 it should be noted that the CR-LF pair immediately preceding the
150 final dot is considered part of the content. Finally, although the
151 content body contains arbitrary lines of octet-aligned material, the
152 length of each line (number of octets between two CR-LF pairs) is
153 still subject to SMTP server line length restrictions (which can
154 allow as few as 1000 octets, inclusive of the CR-LF pair, on a single
155 line). This restriction means that this extension provides the
156 necessary facilities for transferring a MIME object with the 8BIT
157 content-transfer-encoding, it DOES NOT provide a means of
158 transferring an object with the BINARY content-transfer-encoding.
160 Once a server SMTP supporting the 8bit-MIMEtransport service
161 extension accepts a content body containing octets with the high-
162 order (8th) bit set, the server SMTP must deliver or relay the
163 content in such a way as to preserve all bits in each octet.
170Klensin, et al. Standards Track [Page 3]
172RFC 6152 SMTP Extension for 8-bit MIME March 2011
175 If a server SMTP does not support the 8-bit MIME transport extension
176 (either by not responding with code 250 to the EHLO command, or by
177 not including the EHLO keyword value 8BITMIME in its response), then
178 the client SMTP must not, under any circumstances, attempt to
179 transfer a content that contains characters outside of the US-ASCII
180 octet range (hex 00-7F).
182 A client SMTP has two options in this case: first, it may implement a
183 gateway transformation to convert the message into valid 7-bit MIME,
184 or second, it may treat the barrier to 8-bit as a permanent error and
185 handle it in the usual manner for delivery failures. The specifics
186 of the transformation from 8-bit MIME to 7-bit MIME are not described
187 by this RFC; the conversion is nevertheless constrained in the
190 1. it must cause no loss of information; MIME transport encodings
191 must be employed as needed to insure this is the case, and
193 2. the resulting message must be valid 7-bit MIME.
197 The following dialogue illustrates the use of the 8bit-MIMEtransport
200 S: <wait for connection on TCP port 25>
201 C: <open connection to server>
202 S: 220 dbc.mtview.ca.us SMTP service ready
203 C: EHLO ymir.claremont.edu
204 S: 250-dbc.mtview.ca.us says hello
206 C: MAIL FROM:<ned@ymir.claremont.edu> BODY=8BITMIME
207 S: 250 <ned@ymir.claremont.edu>... Sender and 8BITMIME ok
208 C: RCPT TO:<mrose@dbc.mtview.ca.us>
209 S: 250 <mrose@dbc.mtview.ca.us>... Recipient ok
211 S: 354 Send 8BITMIME message, ending in CRLF.CRLF.
226Klensin, et al. Standards Track [Page 4]
228RFC 6152 SMTP Extension for 8-bit MIME March 2011
2315. Security Considerations
233 This RFC does not discuss security issues and is not believed to
234 raise any security issues not already endemic in electronic mail and
235 present in fully conforming implementations of RFC 5321, including
236 attacks facilitated by the presence of an option negotiation
237 mechanism. Since MIME semantics are transport-neutral, the 8BITMIME
238 option provides no more added capability to disseminate malware than
239 is provided by unextended 7-bit SMTP.
2416. IANA Considerations
2436.1. SMTP Service Extension Registration
245 This document defines an SMTP and Submit service extension. IANA has
246 updated the 8BITMIME entry in the SMTP Service Extensions registry,
251 Description: SMTP and Submit transport of 8-bit MIME content
255 Parameters: See Section 2 in this specification.
259 E. Stefferud was an original author. This version of the
260 specification was produced by the YAM working group.
262 Original acknowledgements: This document represents a synthesis of
263 the ideas of many people and reactions to the ideas and proposals
264 of others. Randall Atkinson, Craig Everhart, Risto Kankkunen, and
265 Greg Vaudreuil contributed ideas and text sufficient to be
266 considered co-authors. Other important suggestions, text, or
267 encouragement came from Harald Alvestrand, Jim Conklin,
268 Mark Crispin, Frank da Cruz, Olafur Gudmundsson, Per Hedeland,
269 Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller,
270 Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert,
271 John Wagner, Rayan Zachariassen, and the contributions of the
272 entire IETF SMTP Working Group. Of course, none of the
273 individuals are necessarily responsible for the combination of
274 ideas represented here. Indeed, in some cases, the response to a
275 particular criticism was to accept the problem identification but
276 to include an entirely different solution from the one originally
282Klensin, et al. Standards Track [Page 5]
284RFC 6152 SMTP Extension for 8-bit MIME March 2011
2878. Normative References
289 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
290 Extensions (MIME) Part One: Format of Internet Message
291 Bodies", RFC 2045, November 1996.
293 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
294 Extensions (MIME) Part Two: Media Types", RFC 2046,
297 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
298 Specifications: ABNF", STD 68, RFC 5234, January 2008.
300 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
303 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
338Klensin, et al. Standards Track [Page 6]
340RFC 6152 SMTP Extension for 8-bit MIME March 2011
346 1770 Massachusetts Ave, Ste. 322
350 Phone: +1 617 245 1457
351 EMail: john+ietf@jck.com
357 Monrovia, CA 91016-6347
360 EMail: ned.freed@mrochek.com
364 Dover Beach Consulting, Inc.
366 Sacramento, CA 95865-5268
369 Phone: +1 916 538 2535
370 EMail: mrose17@gmail.com
374 Brandenburg InternetWorking
379 Phone: +1 408 246 8253
380 EMail: dcrocker@bbiw.net
394Klensin, et al. Standards Track [Page 7]