idnits 2.17.1 draft-ietf-smtpext-8bitmime-02.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. == Mismatching filename: the document gives the document name as 'draft-ietf-smtpext-8bitmime-00', but the file name used is 'draft-ietf-smtpext-8bitmime-02' == 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 140: '...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 (April 11, 1995) is 10607 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 232, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 240, 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 (~~), 5 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 April 11, 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) no additional SMTP verbs are defined by this extension; 84 and, 86 (6) the next section specifies how support for the 87 extension affects the behavior of a server and client 88 SMTP. 90 4. The 8bit-MIMEtransport service extension 92 When a client SMTP wishes to submit (using the MAIL command) a 93 content body consisting of a MIME message containing arbitrary 94 lines of octet-aligned material, it first issues the EHLO 95 command to the server SMTP. If the server SMTP responds with 96 code 250 to the EHLO command, and the response includes the 97 EHLO keyword value 8BITMIME, then the server SMTP is 98 indicating that it supports the extended MAIL command and will 99 accept MIME messages that use the capabilities of the 8bit 100 MIME content-transfer-encoding. 102 The extended MAIL command is issued by a client SMTP when it 103 wishes to transmit a content body consisting of a MIME message 104 containing arbitrary lines of octet-aligned material. The 105 syntax for this command is identical to the MAIL command in 106 [1], except that a BODY parameter must appear after the 107 address. Only one BODY parameter may be used in a single MAIL 108 command. 110 The complete syntax of this extended command is defined in 111 [5]. The esmtp-keyword is BODY and the syntax for esmtp-value 112 is given by the syntax for body-value shown above. 114 The value associated with the BODY parameter indicates whether 115 the content body which will be passed using the DATA command 116 consists of a MIME message containing some 8-bit material 117 ("8BITMIME") in accordance with [3] or is encoded entirely in 118 accordance with [1] ("7BIT"). 120 A server which supports the 8-bit MIME transport service 121 extension shall preserve all bits in each octet passed using 122 the DATA command. 124 Naturally, the usual SMTP data-stuffing algorithm applies so 125 that a content which contains the five-character sequence of 127 129 or a content that begins with the three-character sequence of 130 132 does not prematurely terminate the transfer of the content. 133 Further, it should be noted that the CR-LF pair immediately 134 preceeding the final dot is considered part of the content. 135 Finally, although the content body contains arbitrary lines of 136 octet-aligned material, the length of each line (number of 137 octets between two CR-LF pairs), is still subject to SMTP 138 server line length restrictions (which may allow as few as 139 1000 octets on a single line). This restriction means that 140 this extension MAY provide the necessary facilities for 141 transferring a MIME object with the 8BIT content-transfer- 142 encoding, it DOES NOT provide a means of transferring an 143 object with the BINARY content-transfer-encoding. 145 Once a server SMTP supporting the 8bit-MIMEtransport service 146 extension accepts a content body containing octets with the 147 high-order (8th) bit set, the server SMTP must deliver or 148 relay the content in such a way as to preserve all bits in 149 each octet. 151 If a server SMTP does not support the 8-bit MIME transport 152 extension (either by not responding with code 250 to the EHLO 153 command, or by not including the EHLO keyword value 8BITMIME 154 in its response), then the client SMTP must not, under any 155 circumstances, attempt to transfer a content which contains 156 characters with values greater than hex 7F. 158 A client SMTP has two options in this case: first, it may 159 implement a gateway transformation to convert the message into 160 valid 7bit MIME, or second, or may treat this as a permanent 161 error and handle it in the usual manner for delivery failures. 162 The specifics of the transformation from 8bit MIME to 7bit 163 MIME are not described by this RFC; the conversion is 164 nevertheless constrained in the following ways: 166 (1) it must cause no loss of information; MIME transport 167 encodings must be employed as needed to insure this is 168 the case, and 170 (2) the resulting message must be valid 7bit MIME. 172 5. Usage Example 174 The following dialogue illustrates the use of the 8bit- 175 MIMEtransport service extension: 177 S: 178 C: 179 S: 220 dbc.mtview.ca.us SMTP service ready 180 C: EHLO ymir.claremont.edu 181 S: 250-dbc.mtview.ca.us says hello 182 S: 250 8BITMIME 183 C: MAIL FROM: BODY=8BITMIME 184 S: 250 ... Sender and 8BITMIME ok 185 C: RCPT TO: 186 S: 250 ... Recipient ok 187 C: DATA 188 S: 354 Send 8BITMIME message, ending in CRLF.CRLF. 189 ... 190 C: . 191 S: 250 OK 192 C: QUIT 193 S: 250 Goodbye 195 6. Security Considerations 197 This RFC does not discuss security issues and is not believed 198 to raise any security issues not already endemic in electronic 199 mail and present in fully conforming implementations of [1]. 201 7. Acknowledgements 203 This document represents a synthesis of the ideas of many 204 people and reactions to the ideas and proposals of others. 205 Randall Atkinson, Craig Everhart, Risto Kankkunen, and Greg 206 Vaudreuil contributed ideas and text sufficient to be 207 considered co-authors. Other important suggestions, text, or 208 encouragement came from Harald Alvestrand, Jim Conklin, Mark 209 Crispin, Frank da Cruz, 'Olafur Gudmundsson, Per Hedeland, 210 Christian Huitma, Neil Katin, Eliot Lear, Harold A. Miller, 211 Keith Moore, Dan Oscarsson, Julian Onions, Neil Rickert, John 212 Wagner, Rayan Zachariassen, and the contributions of the 213 entire IETF SMTP Working Group. Of course, none of the 214 individuals are necessarily responsible for the combination of 215 ideas represented here. Indeed, in some cases, the response to 216 a particular criticism was to accept the problem 217 identification but to include an entirely different solution 218 from the one originally proposed. 220 8. References 222 [1] J.B. Postel. Simple Mail Transfer Protocol. Request for 223 Comments 821, (August, 1982). 225 [2] D.H. Crocker. Standard for the Format of ARPA Internet 226 Text Messages. Request for Comments 822, (August, 1982). 228 [3] N.S. Borenstein, N. Freed. Multipurpose Internet Mail 229 Extensions. Request for Comments 1521, (September, 230 1993). 232 [4] K. Moore. Representation of Non-ASCII Text in Internet 233 Message Headers. Request for Comments 1522, (September, 234 1993). 236 [5] M.T. Rose, E.A. Stefferud, D.H. Crocker, J.C. Klensin, 237 N. Freed. SMTP Service Extensions. Internet-Draft, 238 (April, 1995). 240 [6] C. Partridge. Mail Routing and the Domain System. 241 Request for Comments 974, (January, 1986). 243 9. Chair, Editor, and Author Addresses 245 John Klensin, WG Chair 246 MCI 247 2100 Reston Parkway 248 Reston, VA 22091 249 tel: +1 703 715-7361 fax: +1 703 715-7436 250 email: klensin@mci.net 252 Ned Freed, Editor 253 Innosoft International, Inc. 254 1050 East Garvey Avenue South 255 West Covina, CA 91790 256 USA 257 tel: +1 818 919 3600 fax: +1 818 919 3614 258 email: ned@innosoft.com 260 Marshall T. Rose 261 Dover Beach Consulting, Inc. 262 420 Whisman Court 263 Moutain View, CA 94043-2186 264 USA 265 tel: +1 415 968 1052 fax: +1 415 968 2510 266 email: mrose@dbc.mtview.ca.us 268 Einar A. Stefferud 269 Network Management Associates, Inc. 270 17301 Drey Lane 271 Huntington Beach, CA, 92647-5615 272 USA 273 tel: +1 714 842 3711 fax: +1 714 848 2091 274 email: stef@nma.com 276 Dave Crocker 277 Brandenburg Consulting 278 675 Spruce Dr. 279 Sunnyvale, CA 94086 USA 280 USA 281 tel: +1 408 246 8253 fax: +1 408 249 6205 282 email: dcrocker@mordor.stanford.edu