idnits 2.17.1 draft-ietf-yam-rfc1652bis-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The draft header indicates that this document obsoletes RFC1652, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 19, 2010) is 5177 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 YAM J. Klensin 3 Internet-Draft 4 Obsoletes: 1652 (if approved) N. Freed 5 Intended status: Standards Track Sun Microsystems 6 Expires: August 23, 2010 M. Rose 7 Dover Beach Consulting, Inc. 8 D. Crocker, Ed. 9 Brandenburg InternetWorking 10 February 19, 2010 12 SMTP Service Extension for 8-bit MIME Transport 13 draft-ietf-yam-rfc1652bis-03 15 Abstract 17 This memo defines an extension to the SMTP service whereby an SMTP 18 content body consisting of text containing octets outside of the US- 19 ASCII octet range (hex 00-7F) may be relayed using SMTP. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 23, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 1. Introduction 61 Although SMTP is widely and robustly deployed, various extensions 62 have been requested by parts of the Internet community. In 63 particular, a significant portion of the Internet community wishes to 64 exchange messages in which the content body consists of a MIME 65 message [RFC2045][RFC2046][RFC5322] containing arbitrary octet- 66 aligned material. This memo uses the mechanism described in 67 [RFC5321] to define an extension to the SMTP service whereby such 68 contents may be exchanged. Note that this extension does NOT 69 eliminate the possibility of an SMTP server limiting line length; 70 servers are free to implement this extension but nevertheless set a 71 line length limit no lower than 1000 octets. Given that this 72 restriction still applies, this extension does NOT provide a means 73 for transferring unencoded binary via SMTP. 75 2. Framework for the 8bit MIME Transport Extension 77 The 8bit MIME transport extension is laid out as follows: 79 1. the name of the SMTP service extension defined here is 8bit- 80 MIMEtransport; 82 2. the EHLO keyword value associated with the extension is 8BITMIME; 84 3. no parameter is used with the 8BITMIME EHLO keyword; 86 4. one optional parameter using the keyword BODY is added to the 87 MAIL FROM command. The value associated with this parameter is a 88 keyword indicating whether a 7bit message (in strict compliance 89 with [RFC5321]) or a MIME message (in strict compliance with 90 [RFC2046][RFC2045]) with arbitrary octet content is being sent. 91 The syntax of the value is as follows, using the ABNF notation of 92 [RFC5234]: 93 body-value = "7BIT" / "8BITMIME" 94 5. no additional SMTP verbs are defined by this extension; and, 96 6. the next section specifies how support for the extension affects 97 the behavior of a server and client SMTP. 99 3. The 8bit-MIMEtransport service extension 101 When a client SMTP wishes to submit (using the MAIL command) a 102 content body consisting of a MIME message containing arbitrary lines 103 of octet-aligned material, it first issues the EHLO command to the 104 server SMTP. If the server SMTP responds with code 250 to the EHLO 105 command, and the response includes the EHLO keyword value 8BITMIME, 106 then the server SMTP is indicating that it supports the extended MAIL 107 command and will accept MIME messages containing arbitrary octet- 108 aligned material. 110 The extended MAIL command is issued by a client SMTP when it wishes 111 to transmit a content body consisting of a MIME message containing 112 arbitrary lines of octet-aligned material. The syntax for this 113 command is identical to the MAIL command in [RFC5321], except that a 114 BODY parameter must appear after the address. Only one BODY 115 parameter may be used in a single MAIL command. 117 The complete syntax of this extended command is defined in [RFC5321]. 118 The esmtp-keyword is BODY and the syntax for esmtp-value is given by 119 the syntax for body-value shown above. 121 The value associated with the BODY parameter indicates whether the 122 content body which will be passed using the DATA command consists of 123 a MIME message containing some arbitrary octet-aligned material 124 ("8BITMIME") or is encoded entirely in accordance with [RFC5321] 125 ("7BIT"). 127 A server which supports the 8-bit MIME transport service extension 128 shall preserve all bits in each octet passed using the DATA command. 129 Naturally, the usual SMTP data-stuffing algorithm applies so that a 130 content which contains the five-character sequence of 131 132 or a content that begins with the three-character sequence of 133 134 does not prematurely terminate the transfer of the content. Further, 135 it should be noted that the CR-LF pair immediately preceding the 136 final dot is considered part of the content. Finally, although the 137 content body contains arbitrary lines of octet-aligned material, the 138 length of each line (number of octets between two CR-LF pairs), is 139 still subject to SMTP server line length restrictions (which can 140 allow as few as 1000 octets, inclusive of the CR-LF pair, on a single 141 line). This restriction means that this extension provides the 142 necessary facilities for transferring a MIME object with the 8BIT 143 content-transfer-encoding, it DOES NOT provide a means of 144 transferring an object with the BINARY content-transfer-encoding. 146 Once a server SMTP supporting the 8bit-MIMEtransport service 147 extension accepts a content body containing octets with the high- 148 order (8th) bit set, the server SMTP must deliver or relay the 149 content in such a way as to preserve all bits in each octet. 151 If a server SMTP does not support the 8-bit MIME transport extension 152 (either by not responding with code 250 to the EHLO command, or by 153 not including the EHLO keyword value 8BITMIME in its response), then 154 the client SMTP must not, under any circumstances, attempt to 155 transfer a content which contains characters outside the US-ASCII 156 octet range (hex 00-7F). 158 A client SMTP has two options in this case: first, it may implement a 159 gateway transformation to convert the message into valid 7bit MIME, 160 or second, or may treat this as a permanent error and handle it in 161 the usual manner for delivery failures. The specifics of the 162 transformation from 8bit MIME to 7bit MIME are not described by this 163 RFC; the conversion is nevertheless constrained in the following 164 ways: 166 1. it must cause no loss of information; MIME transport encodings 167 must be employed as needed to insure this is the case, and 169 2. the resulting message must be valid 7bit MIME. 171 4. Usage Example 173 The following dialogue illustrates the use of the 8bit-MIMEtransport 174 service extension: 176 S: 177 C: 178 S: 220 dbc.mtview.ca.us SMTP service ready 179 C: EHLO ymir.claremont.edu 180 S: 250-dbc.mtview.ca.us says hello 181 S: 250 8BITMIME 182 C: MAIL FROM: BODY=8BITMIME 183 S: 250 ... Sender and 8BITMIME ok 184 C: RCPT TO: 185 S: 250 ... Recipient ok 186 C: DATA 187 S: 354 Send 8BITMIME message, ending in CRLF.CRLF. 188 ... 189 C: . 190 S: 250 OK 191 C: QUIT 192 S: 250 Goodbye 194 5. Security Considerations 196 This RFC does not discuss security issues and is not believed to 197 raise any security issues not already endemic in electronic mail and 198 present in fully conforming implementations of [RFC5321]. 200 6. IANA Considerations 202 6.1. SMTP service extension registration 204 This document defines an SMTP and Submit service extension, and IANA 205 is asked to update the 8BITMIME entry in the SMTP Service Extensions 206 registry, as follows: 208 Keyword: 8BITMIME 210 Description: SMTP and Submit transport of 8bit MIME content 212 Reference: [[IANA: Insert this RFC number.]] 214 Parameters: See Section 2 in this specification. 216 6.2. Acknowledgements 218 E. Stefferud was an original author. This version of the 219 specification was produced by the YAM working group. 221 Original acknowledgements: This document represents a synthesis of 222 the ideas of many people and reactions to the ideas and proposals 223 of others. Randall Atkinson, Craig Everhart, Risto Kankkunen, and 224 Greg Vaudreuil contributed ideas and text sufficient to be 225 considered co-authors. Other important suggestions, text, or 226 encouragement came from Harald Alvestrand, Jim Conklin, Mark 227 Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per Hedeland, 228 Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, Keith 229 Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John Wagner, 230 Rayan Zachariassen, and the contributions of the entire IETF SMTP 231 Working Group. Of course, none of the individuals are necessarily 232 responsible for the combination of ideas represented here. 233 Indeed, in some cases, the response to a particular criticism was 234 to accept the problem identification but to include an entirely 235 different solution from the one originally proposed. 237 7. Normative References 239 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 240 Extensions (MIME) Part One: Format of Internet Message 241 Bodies", RFC 2045, November 1996. 243 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 244 Extensions (MIME) Part Two: Media Types", RFC 2046, 245 November 1996. 247 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 248 Specifications: ABNF", STD 68, RFC 5234, January 2008. 250 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 251 October 2008. 253 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 254 October 2008. 256 Authors' Addresses 258 John C Klensin 259 1770 Massachusetts Ave, Ste 322 260 Cambridge, MA 02140 261 USA 263 Phone: +1 617 245 1457 264 Email: john+ietf@jck.com 265 Ned Freed 266 Sun Microsystems 267 800 Royal Oaks 268 Monrovia, CA 91016-6347 269 USA 271 Phone: +1 909 457 4293 272 Email: ned.freed@mrochek.com 274 M. Rose 275 Dover Beach Consulting, Inc. 276 POB 255268 277 Sacramento, CA 95865-5268 279 Phone: +1 916 538 2535 280 Email: mrose17@gmail.com 282 D. Crocker (editor) 283 Brandenburg InternetWorking 284 675 Spruce Dr. 285 Sunnyvale, CA 286 USA 288 Phone: +1.408.246.8253 289 Email: dcrocker@bbiw.net 290 URI: http://bbiw.net