idnits 2.17.1 draft-ietf-mailext-smtp-binary-06.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-19) 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. ** 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-mailext-smtp-binary-06', but the file name used is 'draft-ietf-mailext-smtp-binary-06' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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.) ** There are 5 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 22, 1995) is 10621 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) -- Missing reference section? '4' on line 331 looks like a reference -- Missing reference section? '1' on line 322 looks like a reference -- Missing reference section? '5' on line 335 looks like a reference -- Missing reference section? '3' on line 328 looks like a reference -- Missing reference section? '2' on line 325 looks like a reference Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Greg Vaudreuil 2 Internet Draft Octel Network Services 3 Expires: 2/20/95 March 22, 1995 5 SMTP Service Extensions 6 for Transmission of Large 7 and Binary MIME Messages 9 11 Changes from Previous Draft 13 1) Numerous typo's corrected. 15 1.Status of this Memo 17 This document is an Internet Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its 19 Areas, and its Working Groups. Note that other groups may also 20 distribute working documents as Internet Drafts. 22 Internet Drafts are valid for a maximum of six months and may be 23 updated, replaced, or obsoleted by other documents at any time. 24 It is inappropriate to use Internet Drafts as reference material 25 or to cite them other than as a "work in progress". 27 2.Abstract 29 This memo defines two extensions to the SMTP service. The first 30 service. enables a SMTP client and server to negotiate the use of 31 an alternate DATA command "BDAT" for efficiently sending large 32 MIME messages. The second extension takes advantage of the BDAT 33 command to permit the negotiated sending of unencoded binary 34 data. 36 3.Introduction 38 The MIME extensions to the Internet message protocol provides for 39 the transmission of many kinds of data which were previously 40 unsupported in Internet mail. Anticipating the need to more 41 efficiently transport the new media made possible with MIME, the 42 SMTP protocol has been extended to provide transport for new 43 message types. RFC 1426 defines one such extension for the 44 transmission of unencoded 8 bit MIME messages. This service 45 extension permits the receiver SMTP to declare support for 8 bit 46 body parts and the sender to request 8 bit transmission of a 47 particular message. 49 One expected result of the use of MIME is that the Internet mail 50 system will be expected to carry very large mail messages. In 51 such transactions, there is a need to eliminate the requirement 52 that the message be scanned for "CR LF . CR LF" sequences upon 53 sending and receiving to detect the end of message. 55 Message Transport 57 Independent of the need to send large messages, Internet mail is 58 increasingly multi-media there is a need to avoid the overhead of 59 base64 and quoted-printable encoding of binary objects sent using 60 the MIME message format over SMTP between hosts which support 61 binary message processing. 63 This memo uses the mechanism defined in [4] to define two 64 extensions to the SMTP service whereby a client ("sender-SMTP") 65 may declare support for the message chunking transmission mode 66 using the BDAT command and support for the sending of Binary 67 messages. 69 4.Framework for the Large Message Extensions 71 The following service extension is hereby defined: 73 1) The name of the data chunking service extension is 74 "CHUNKING". 76 2) The EHLO keyword value associated with this extension is 77 "CHUNKING". 79 3) A new SMTP verb is defined "BDAT" as an alternative to 80 the "DATA" command of [1]. The BDAT verb takes two 81 arguments. The first argument indicates the length of the 82 binary data packet. The second optional argument indicates 83 that the data packet is the last. 85 bdat-cmd ::= "BDAT" SP chunk-size 86 [ SP end-marker ] CR LF 87 chunk-size ::= 1*DIGIT 88 end-marker ::= "LAST" 90 The CHUNKING service extension enables the use of the BDAT 91 alternative to the DATA command. This extension can be used for 92 any message, whether 7 bit, 8BITMIME or BINARYMIME. 94 When a client SMTP wishes to submit (using the MAIL command) a 95 large message using the CHUNKING extension, it first issues the 96 EHLO command to the server SMTP. If the server SMTP responds 97 with code 250 to the EHLO command, and the response includes the 98 EHLO keyword value CHUNKING, then the server SMTP is indicating 99 that it supports the BDAT command and will accept the sending of 100 messages in chunks. 102 After all MAIL FROM and RCPT TO responses are collected and 103 processed, the message is sent using a series of BDAT commands. 104 The BDAT command takes one argument, the exact length of the data 105 segment in octets. The message data is sent immediately after 106 the BDAT command. Once the receiver-SMTP receives the specified 107 number of octets, it will return a 250 reply code. 109 The LAST parameter on the BDAT command indicates that this is the 110 last chunk of message data to be sent. 112 Message Transport 114 A 250 response should be sent to each BDAT data block. If a 5XX 115 code is sent in response to a BDAT chunk the message should be 116 considered failed and, the sender SMTP must not send any 117 additional BDAT segments. If streaming, the sender SMTP must 118 complete the sending of the current segment and not send any more 119 BDATs. When streaming, the receiver SMTP must accept and discard 120 additional BDAT chunks after the failed BDAT. After receiving a 121 5XX error in response to a BDAT command, the resulting state is 122 indeterminate. A RSET command must be issued to clear the 123 transaction before additional commands may be sent. 125 Note that an error on the receiver SMTP such as disk full or 126 imminent shutdown can only be reported after the BDAT 127 segment has been sent. It is therefore important to choose 128 a reasonable chunk size given the expected end to end 129 bandwidth. 131 The RSET command when issued during afer the first BDAT and 132 before the BDAT LAST clears all segments sent during that 133 transaction and resets the session. 135 DATA and BDAT commands cannot be used in the same transaction. 136 If a DATA statement is issued after a BDAT for the current 137 transaction, a 503 `` 138 The state resulting from this error is indeterminate. A RSET 139 command must be sent to clear the transaction before continuing. 140 There is no prohibition on using DATA and BDAT in the same 141 session, so long as they are not mixed in the same transaction. 143 The local storage size of a message may not accurately reflect 144 the actual size of the message sent due to local storage 145 conventions. In particular, text messages sent with the BDAT 146 command must be sent in the canonical MIME format with lines 147 delimited with a . It may not be possible to convert the 148 entire message to the canonical format at once. Chunking provides 149 a mechanism to convert the message to canonical form, accurately 150 count the bytes, and send the message a single chunk at a time. 152 Note that correct byte counting is essential. If too many bytes are 153 indicated by the sender SMTP, the receiver SMTP will continue to wait 154 for the remainder of the data or will read the subsequent command as 155 additional message data. In the case where a portion of the previous 156 command was read as data, the parser will return a syntax error when 157 the incomplete command is read. 159 If too few bytes are indicated by the sender SMTP, the 160 receiver SMTP will interpret the remainder of the message 161 data as invalid commands. Note that the remainder of the 162 message data may be binary and as such lexigraphical parsers 163 must be prepared to receive, process, and reject lines of 164 arbitrary octets. 166 Message Transport 168 5.Framework for the Binary Service Extension 170 The following service extension is hereby defined: 172 1) The name of the binary service extension is "BINARYMIME". 174 2) The EHLO keyword value associated with this extension is 175 "BINARYMIME". 177 3) The BINARYMIME service extension can only be used with 178 the "CHUNKING" service extension. 180 4) No parameter is used with the BINARYMIME keyword. 182 5) One additional parameter to the BODY keyword defined [5] 183 for the MAIL FROM command is defined, "BINARYMIME". The 184 value "BINARYMIME" associated with this parameter indicates 185 that this message is a Binary MIME message (in strict 186 compliance with [3]) with arbitrary octet content being 187 sent. The revised syntax of the value is as follows, using 188 the ABNF notation of [2]: 190 body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME" 192 6) No new verbs are defined for the BINARYMIME extension. 194 A sender SMTP may request that a binary MIME message be sent 195 without transport encoding by sending a BINARYMIME parameter with 196 the MAIL FROM command. When the receiver SMTP accepts a MAIL 197 FROM command with the BINARYMIME body type requested, it agrees 198 to preserve all bits in each octet passed using the BDAT command. 200 BINARYMIME cannot be used with the DATA command. If a DATA 201 command is issued after a MAIL FROM command containing the body- 202 value of BINARYMIME 203 resulting state from this error condition is indeterminate and 204 the transaction should be reset with the RSET command. 206 It is important to note that when using BINARYMIME, it is 207 especially important to ensure that the MIME message itself 208 is properly formed. In particular, it is essential that 209 text be canonically encoded with each line properly 210 terminated with . Any transformation of text into 211 non-canonical MIME to observe local storage conventions must 212 be reversed before sending as BINARYMIME. The usual line- 213 oriented shortcuts will break if used with BINARYMIME. 215 The syntax of the extended MAIL command is identical to the MAIL 216 command in [1], except that a BODY parameter must appear after 217 the address. The complete syntax of this extended command is 218 defined in [4]. The ESMTP-keyword is BODY and the syntax for 219 ESMTP-value is given by the syntax for body-value in [4]. 221 Message Transport 223 If a receiver SMTP does not support the BINARYMIME message format 224 (either by not responding with code 250 to the EHLO command, or 225 by rejecting the BINARYMIME parameter to the MAIL FROM command, 226 then the client SMTP must not, under any circumstances, send 227 binary data using the DATA or BDAT commands. 229 If the receiver-SMTP does not support BINARYMIME and the message 230 content is a MIME object with a binary encoding, a client SMTP 231 has two options in this case: first, it may implement a gateway 232 transformation to convert the message into valid 7bit encoded 233 MIME, or second, it may treat this as a permanent error and 234 handle it in the usual manner for delivery failures. The 235 specifics of the transformation from Binary MIME to 7bit MIME are 236 not described by this RFC; the conversion is nevertheless 237 constrained in the following ways: 239 The conversion must cause no loss of information; MIME 240 transport encodings must be employed as needed to insure this 241 is the case. 243 The resulting message must be valid 7bit MIME. 245 As of present there are no mechanisms for converting a binary 246 MIME object into a 8 bit-MIME object. Such a transformation will 247 require the specification of a new MIME content-transfer- 248 encoding, the standardization of which is discouraged by [3]. 250 6.Examples 252 6.1. Simple Chunking 254 The following simple dialogue illustrates the use of the large 255 message extension to send a short psudo-RFC822 message to one 256 recipient using the CHUNKING extension: 258 R: 259 S: 260 R: 220 cnri.reston.va.us SMTP service ready 261 S: EHLO ymir.claremont.edu 262 R: 250-cnri.reston.va.us says hello 263 R: 250 CHUNKING 264 S: MAIL FROM: 265 R: 250 ... Sender ok 266 S: RCPT TO: 267 R: 250 ... Recipient ok 268 S: BDAT 69 LAST 269 S: To: Susan@random.com 270 S: From: Sam@random.com 271 S: Subject: This is a bodyless test message 272 R: 250 Message OK, 69 octets received 273 S: QUIT 274 R: 221 Goodbye 275 Message Transport 277 6.2. Streaming Binarymime 279 The following dialogue illustrates the use of the large message 280 extension to send a BINARYMIME object to two recipients using the 281 CHUNKING and STREAMING extensions: 283 R: 284 S: 285 R: 220 cnri.reston.va.us SMTP service ready 286 S: EHLO ymir.claremont.edu 287 R: 250-cnri.reston.va.us says hello 288 R: 250-STREAMING 289 R: 250-BINARYMIME 290 R: 250 CHUNKING 291 S: MAIL FROM: BODY=BINARYMIME 292 S: RCPT TO: 293 S: RCPT TO: 294 R: 250 ... Sender and BINARYMIME ok 295 R: 250 ... Recipient ok 296 R: 250 ... Recipient ok 297 S: BDAT 100000 298 S: (First 10000 octets of canonical MIME message data) 299 S: BDAT 324 LAST 300 S: (Remaining 324 octets of canonical MIME message data) 301 R: 250 100000 bytes received 302 R: 250 Message OK, 100324 octets received 303 S: QUIT 304 R: 221 Goodbye 305 Message Transport 307 7.Security Considerations 309 This RFC does not discuss security issues and is not believed to 310 raise any security issues not already endemic in electronic mail 311 and present in fully conforming implementations of [1], or 312 otherwise made possible by [3]. 314 8.Acknowledgments 316 This document is the result of numerous discussions in the IETF 317 SMTP Extensions Working Group and in particular due to the 318 continued advocacy of "chunking" by Neil Katin. 320 9.References 322 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 323 USC/Information Sciences Institute, August 1982. 325 [2] Crocker, D., "Standard for the Format of ARPA Internet Text 326 Messages", STD 11, RFC 822, UDEL, August 1982. 328 [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail 329 Extensions", RFC 1341, Bellcore, Innosoft, June 1992. 331 [4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., 332 Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC 333 1425, 335 [5] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., 336 Stefferud, E., and D. Crocker, "SMTP Service Extension for 337 8bit-MIMEtransport" RFC 1426, United Nations University, 338 Innosoft International, Inc., Dover Beach Consulting, Inc., 339 Network Management Associates, Inc., The Branch Office, 340 February 1993. 342 10. Author's Address 344 Gregory M. Vaudreuil 345 Octel Network Services 346 17060 Dallas Parkway 347 Suite 214 348 Dallas, TX 75248-1905 349 Greg.Vaudreuil@ons.octel.com