rfcs/rfc6152.txt -rw-r--r-- 12.7 KiB
1
2
3
4
5
6
7Internet Engineering Task Force (IETF) J. Klensin
8Request for Comments: 6152
9STD: 71 N. Freed
10Obsoletes: 1652 Oracle
11Category: Standards Track M. Rose
12ISSN: 2070-1721 Dover Beach Consulting, Inc.
13 D. Crocker, Ed.
14 Brandenburg InternetWorking
15 March 2011
16
17
18 SMTP Service Extension for 8-bit MIME Transport
19
20Abstract
21
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.
25
26Status of This Memo
27
28 This is an Internet Standards Track document.
29
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.
35
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.
39
40Copyright Notice
41
42 Copyright (c) 2011 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
44
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.
54
55
56
57
58Klensin, et al. Standards Track [Page 1]
59
60RFC 6152 SMTP Extension for 8-bit MIME March 2011
61
62
631. Introduction
64
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.
78
792. Framework for the 8-bit MIME Transport Extension
80
81 The 8-bit MIME transport extension is laid out as follows:
82
83 1. the name of the SMTP service extension defined here is
84 8bit-MIMEtransport;
85
86 2. the EHLO keyword value associated with the extension is 8BITMIME;
87
88 3. no parameter is used with the 8BITMIME EHLO keyword;
89
90 4. one optional parameter using the keyword BODY is added to the
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]:
97
98 body-value = "7BIT" / "8BITMIME"
99
100 5. no additional SMTP verbs are defined by this extension; and
101
102 6. the next section specifies how support for the extension affects
103 the behavior of a server and client SMTP.
104
1053. The 8bit-MIMEtransport Service Extension
106
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
111
112
113
114Klensin, et al. Standards Track [Page 2]
115
116RFC 6152 SMTP Extension for 8-bit MIME March 2011
117
118
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-
122 aligned material.
123
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
128 BODY parameter must appear after the address. Only one BODY
129 parameter may be used in a single MAIL command.
130
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.
134
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
139 ("7BIT").
140
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
147 <DOT> <CR> <LF>
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.
159
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.
164
165
166
167
168
169
170Klensin, et al. Standards Track [Page 3]
171
172RFC 6152 SMTP Extension for 8-bit MIME March 2011
173
174
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).
181
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
188 following ways:
189
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
192
193 2. the resulting message must be valid 7-bit MIME.
194
1954. Usage Example
196
197 The following dialogue illustrates the use of the 8bit-MIMEtransport
198 service extension:
199
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
205 S: 250 8BITMIME
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
210 C: DATA
211 S: 354 Send 8BITMIME message, ending in CRLF.CRLF.
212 ...
213 C: .
214 S: 250 OK
215 C: QUIT
216 S: 250 Goodbye
217
218
219
220
221
222
223
224
225
226Klensin, et al. Standards Track [Page 4]
227
228RFC 6152 SMTP Extension for 8-bit MIME March 2011
229
230
2315. Security Considerations
232
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.
240
2416. IANA Considerations
242
2436.1. SMTP Service Extension Registration
244
245 This document defines an SMTP and Submit service extension. IANA has
246 updated the 8BITMIME entry in the SMTP Service Extensions registry,
247 as follows:
248
249 Keyword: 8BITMIME
250
251 Description: SMTP and Submit transport of 8-bit MIME content
252
253 Reference: [RFC6152]
254
255 Parameters: See Section 2 in this specification.
256
2577. Acknowledgements
258
259 E. Stefferud was an original author. This version of the
260 specification was produced by the YAM working group.
261
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
277 proposed.
278
279
280
281
282Klensin, et al. Standards Track [Page 5]
283
284RFC 6152 SMTP Extension for 8-bit MIME March 2011
285
286
2878. Normative References
288
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.
292
293 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
294 Extensions (MIME) Part Two: Media Types", RFC 2046,
295 November 1996.
296
297 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
298 Specifications: ABNF", STD 68, RFC 5234, January 2008.
299
300 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
301 October 2008.
302
303 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
304 October 2008.
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338Klensin, et al. Standards Track [Page 6]
339
340RFC 6152 SMTP Extension for 8-bit MIME March 2011
341
342
343Authors' Addresses
344
345 John C. Klensin
346 1770 Massachusetts Ave, Ste. 322
347 Cambridge, MA 02140
348 USA
349
350 Phone: +1 617 245 1457
351 EMail: john+ietf@jck.com
352
353
354 Ned Freed
355 Oracle
356 800 Royal Oaks
357 Monrovia, CA 91016-6347
358 USA
359
360 EMail: ned.freed@mrochek.com
361
362
363 M. Rose
364 Dover Beach Consulting, Inc.
365 POB 255268
366 Sacramento, CA 95865-5268
367 USA
368
369 Phone: +1 916 538 2535
370 EMail: mrose17@gmail.com
371
372
373 D. Crocker (editor)
374 Brandenburg InternetWorking
375 675 Spruce Dr.
376 Sunnyvale, CA
377 USA
378
379 Phone: +1 408 246 8253
380 EMail: dcrocker@bbiw.net
381 URI: http://bbiw.net
382
383
384
385
386
387
388
389
390
391
392
393
394Klensin, et al. Standards Track [Page 7]
395