| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | Internet Engineering Task Force (IETF) J. Klensin |
| 8 | Request for Comments: 6152 |
| 9 | STD: 71 N. Freed |
| 10 | Obsoletes: 1652 Oracle |
| 11 | Category: Standards Track M. Rose |
| 12 | ISSN: 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 | |
| 20 | Abstract |
| 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 | |
| 26 | Status 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 | |
| 40 | Copyright 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 | |
| 58 | Klensin, et al. Standards Track [Page 1] |
| 59 | |
| 60 | RFC 6152 SMTP Extension for 8-bit MIME March 2011 |
| 61 | |
| 62 | |
| 63 | 1. 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 | |
| 79 | 2. 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 | |
| 105 | 3. 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 | |
| 114 | Klensin, et al. Standards Track [Page 2] |
| 115 | |
| 116 | RFC 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 | |
| 170 | Klensin, et al. Standards Track [Page 3] |
| 171 | |
| 172 | RFC 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 | |
| 195 | 4. 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 | |
| 226 | Klensin, et al. Standards Track [Page 4] |
| 227 | |
| 228 | RFC 6152 SMTP Extension for 8-bit MIME March 2011 |
| 229 | |
| 230 | |
| 231 | 5. 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 | |
| 241 | 6. IANA Considerations |
| 242 | |
| 243 | 6.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 | |
| 257 | 7. 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 | |
| 282 | Klensin, et al. Standards Track [Page 5] |
| 283 | |
| 284 | RFC 6152 SMTP Extension for 8-bit MIME March 2011 |
| 285 | |
| 286 | |
| 287 | 8. 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 | |
| 338 | Klensin, et al. Standards Track [Page 6] |
| 339 | |
| 340 | RFC 6152 SMTP Extension for 8-bit MIME March 2011 |
| 341 | |
| 342 | |
| 343 | Authors' 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 | |
| 394 | Klensin, et al. Standards Track [Page 7] |
| 395 | |