idnits 2.17.1 draft-ietf-smtpext-8bitmime-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 144: '...this extension MAY provide the necessa...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 6, 1995) is 10582 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) == Unused Reference: '4' is defined on line 236, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 244, but no explicit reference was found in the text ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1521 (ref. '3') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1522 (ref. '4') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 974 (ref. '6') (Obsoleted by RFC 2821) Summary: 16 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group John Klensin, WG Chair 2 Internet Draft Ned Freed, Editor 3 Marshall Rose 4 Einar Stefferud 5 David Crocker 7 SMTP Service Extension 8 for 8bit-MIMEtransport 10 May 6, 1995 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are 15 working documents of the Internet Engineering Task Force 16 (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months. Internet-Drafts may be updated, replaced, or obsoleted 22 by other documents at any time. It is not appropriate to use 23 Internet-Drafts as reference material or to cite them other 24 than as a "working draft" or "work in progress". 26 To learn the current status of any Internet-Draft, please 27 check the 1id-abstracts.txt listing contained in the 28 Internet-Drafts Shadow Directories on ds.internic.net (US East 29 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), 30 or munnari.oz.au (Pacific Rim). 32 This draft is intended to supercede RFC 1652. The only 33 significant change has been to bring the definition of 34 8bitMIME into alignment with the definition in the MIME 35 specification. 37 1. Abstract 39 This memo defines an extension to the SMTP service whereby an 40 SMTP content body consisting of text containing octets outside 41 of the US ASCII octet range (hex 00-7F) may be relayed using 42 SMTP. 44 2. Introduction 46 Although SMTP is widely and robustly deployed, various 47 extensions have been requested by parts of the Internet 48 community. In particular, a significant portion of the 49 Internet community wishes to exchange messages in which the 50 content body consists of a MIME message [3] containing 51 arbitrary octet-aligned material. This memo uses the mechanism 52 described in [5] to define an extension to the SMTP service 53 whereby such contents may be exchanged. Note that this 54 extension does NOT eliminate the possibility of an SMTP server 55 limiting line length; servers are free to implement this 56 extension but nevertheless set a line length limit no lower 57 than 1000 octets. Given that this restriction still applies, 58 this extension does NOT provide a means for transferring 59 unencoded binary via SMTP. 61 3. Framework for the 8bit MIME Transport Extension 63 The 8bit MIME transport extension is laid out as follows: 65 (1) the name of the SMTP service extension defined here is 66 8bit-MIMEtransport; 68 (2) the EHLO keyword value associated with the extension is 69 8BITMIME; 71 (3) no parameter is used with the 8BITMIME EHLO keyword; 73 (4) one optional parameter using the keyword BODY is added 74 to the MAIL FROM command. The value associated with 75 this parameter is a keyword indicating whether a 7bit 76 message (in strict compliance with [1]) or a MIME 77 message (in strict compliance with [3]) with arbitrary 78 octet content is being sent. The syntax of the value is 79 as follows, using the ABNF notation of [2]: 81 body-value ::= "7BIT" / "8BITMIME" 83 (5) The maximum length of a MAIL FROM command line is 84 increased by 14 characters by the possible addition of 85 the BODY keyword and value; 87 (6) no additional SMTP verbs are defined by this extension; 88 and, 90 (7) the next section specifies how support for the 91 extension affects the behavior of a server and client 92 SMTP. 94 4. The 8bit-MIMEtransport service extension 96 When a client SMTP wishes to submit (using the MAIL command) a 97 content body consisting of a MIME message containing arbitrary 98 lines of octet-aligned material, it first issues the EHLO 99 command to the server SMTP. If the server SMTP responds with 100 code 250 to the EHLO command, and the response includes the 101 EHLO keyword value 8BITMIME, then the server SMTP is 102 indicating that it supports the extended MAIL command and will 103 accept MIME messages that use the capabilities of the 8bit 104 MIME content-transfer-encoding. 106 The extended MAIL command is issued by a client SMTP when it 107 wishes to transmit a content body consisting of a MIME message 108 containing arbitrary lines of octet-aligned material. The 109 syntax for this command is identical to the MAIL command in 110 [1], except that a BODY parameter must appear after the 111 address. Only one BODY parameter may be used in a single MAIL 112 command. 114 The complete syntax of this extended command is defined in 115 [5]. The esmtp-keyword is BODY and the syntax for esmtp-value 116 is given by the syntax for body-value shown above. 118 The value associated with the BODY parameter indicates whether 119 the content body which will be passed using the DATA command 120 consists of a MIME message containing some 8-bit material 121 ("8BITMIME") in accordance with [3] or is encoded entirely in 122 accordance with [1] ("7BIT"). 124 A server which supports the 8-bit MIME transport service 125 extension shall preserve all bits in each octet passed using 126 the DATA command. 128 Naturally, the usual SMTP data-stuffing algorithm applies so 129 that a content which contains the five-character sequence of 130 132 or a content that begins with the three-character sequence of 134 136 does not prematurely terminate the transfer of the content. 137 Further, it should be noted that the CR-LF pair immediately 138 preceeding the final dot is considered part of the content. 139 Finally, although the content body contains arbitrary lines of 140 octet-aligned material, the length of each line (number of 141 octets between two CR-LF pairs), is still subject to SMTP 142 server line length restrictions (which may allow as few as 143 1000 octets on a single line). This restriction means that 144 this extension MAY provide the necessary facilities for 145 transferring a MIME object with the 8BIT content-transfer- 146 encoding, it DOES NOT provide a means of transferring an 147 object with the BINARY content-transfer-encoding. 149 Once a server SMTP supporting the 8bit-MIMEtransport service 150 extension accepts a content body containing octets with the 151 high-order (8th) bit set, the server SMTP must deliver or 152 relay the content in such a way as to preserve all bits in 153 each octet. 155 If a server SMTP does not support the 8-bit MIME transport 156 extension (either by not responding with code 250 to the EHLO 157 command, or by not including the EHLO keyword value 8BITMIME 158 in its response), then the client SMTP must not, under any 159 circumstances, attempt to transfer a content which contains 160 characters with values greater than hex 7F. 162 A client SMTP has two options in this case: first, it may 163 implement a gateway transformation to convert the message into 164 valid 7bit MIME, or second, or may treat this as a permanent 165 error and handle it in the usual manner for delivery failures. 166 The specifics of the transformation from 8bit MIME to 7bit 167 MIME are not described by this RFC; the conversion is 168 nevertheless constrained in the following ways: 170 (1) it must cause no loss of information; MIME transport 171 encodings must be employed as needed to insure this is 172 the case, and 174 (2) the resulting message must be valid 7bit MIME. 176 5. Usage Example 178 The following dialogue illustrates the use of the 8bit- 179 MIMEtransport service extension: 181 S: 182 C: 183 S: 220 dbc.mtview.ca.us SMTP service ready 184 C: EHLO ymir.claremont.edu 185 S: 250-dbc.mtview.ca.us says hello 186 S: 250 8BITMIME 187 C: MAIL FROM: BODY=8BITMIME 188 S: 250 ... Sender and 8BITMIME ok 189 C: RCPT TO: 190 S: 250 ... Recipient ok 191 C: DATA 192 S: 354 Send 8BITMIME message, ending in CRLF.CRLF. 193 ... 194 C: . 195 S: 250 OK 196 C: QUIT 197 S: 250 Goodbye 199 6. Security Considerations 201 This RFC does not discuss security issues and is not believed 202 to raise any security issues not already endemic in electronic 203 mail and present in fully conforming implementations of [1]. 205 7. Acknowledgements 207 This document represents a synthesis of the ideas of many 208 people and reactions to the ideas and proposals of others. 209 Randall Atkinson, Craig Everhart, Risto Kankkunen, and Greg 210 Vaudreuil contributed ideas and text sufficient to be 211 considered co-authors. Other important suggestions, text, or 212 encouragement came from Harald Alvestrand, Jim Conklin, Mark 213 Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per Hedeland, 214 Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, 215 Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John 216 Wagner, Rayan Zachariassen, and the contributions of the 217 entire IETF SMTP Working Group. Of course, none of the 218 individuals are necessarily responsible for the combination of 219 ideas represented here. Indeed, in some cases, the response to 220 a particular criticism was to accept the problem 221 identification but to include an entirely different solution 222 from the one originally proposed. 224 8. References 226 [1] J.B. Postel. Simple Mail Transfer Protocol. Request for 227 Comments 821, (August, 1982). 229 [2] D.H. Crocker. Standard for the Format of ARPA Internet 230 Text Messages. Request for Comments 822, (August, 1982). 232 [3] N.S. Borenstein, N. Freed. Multipurpose Internet Mail 233 Extensions. Request for Comments 1521, (September, 234 1993). 236 [4] K. Moore. Representation of Non-ASCII Text in Internet 237 Message Headers. Request for Comments 1522, (September, 238 1993). 240 [5] M.T. Rose, E.A. Stefferud, D.H. Crocker, J.C. Klensin, 241 N. Freed. SMTP Service Extensions. Internet-Draft, 242 (April, 1995). 244 [6] C. Partridge. Mail Routing and the Domain System. 245 Request for Comments 974, (January, 1986). 247 9. Chair, Editor, and Author Addresses 249 John Klensin, WG Chair 250 MCI 251 2100 Reston Parkway 252 Reston, VA 22091 253 tel: +1 703 715-7361 fax: +1 703 715-7436 254 email: klensin@mci.net 256 Ned Freed, Editor 257 Innosoft International, Inc. 258 1050 East Garvey Avenue South 259 West Covina, CA 91790 260 USA 261 tel: +1 818 919 3600 fax: +1 818 919 3614 262 email: ned@innosoft.com 264 Marshall T. Rose 265 Dover Beach Consulting, Inc. 266 420 Whisman Court 267 Moutain View, CA 94043-2186 268 USA 269 tel: +1 415 968 1052 fax: +1 415 968 2510 270 email: mrose@dbc.mtview.ca.us 272 Einar A. Stefferud 273 Network Management Associates, Inc. 274 17301 Drey Lane 275 Huntington Beach, CA, 92647-5615 276 USA 277 tel: +1 714 842 3711 fax: +1 714 848 2091 278 email: stef@nma.com 280 Dave Crocker 281 Brandenburg Consulting 282 675 Spruce Dr. 283 Sunnyvale, CA 94086 USA 284 USA 285 tel: +1 408 246 8253 fax: +1 408 249 6205 286 email: dcrocker@mordor.stanford.edu