1
2
3
4
5
6
7Network Working Group G. Vaudreuil
8Request for Comments: 3030 Lucent Technologies
9Obsolete: 1830 December 2000
10Category: Standards Track
11
12
13 SMTP Service Extensions
14 for Transmission of Large
15 and Binary MIME Messages
16
17Status of this Memo
18
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
24
25Copyright Notice
26
27 Copyright (C) The Internet Society (2000). All Rights Reserved.
28
29Abstract
30
31 This memo defines two extensions to the SMTP (Simple Mail Transfer
32 Protocol) service. The first extension enables a SMTP client and
33 server to negotiate the use of an alternative to the DATA command,
34 called "BDAT", for efficiently sending large MIME (Multipurpose
35 Internet Mail Extensions) messages. The second extension takes
36 advantage of the BDAT command to permit the negotiated sending of
37 MIME messages that employ the binary transfer encoding. This
38 document is intended to update and obsolete RFC 1830.
39
40Working Group Summary
41
42 This protocol is not the product of an IETF working group, however
43 the specification resulted from discussions within the ESMTP working
44 group. The resulting protocol documented in RFC 1830 was classified
45 as experimental at that time due to questions about the robustness of
46 the Binary Content-Transfer-Encoding deployed in then existent MIME
47 implementations. As MIME has matured and other uses of the Binary
48 Content-Transfer-Encoding have been deployed, these concerns have
49 been allayed. With this document, Binary ESMTP is expected to become
50 standards-track.
51
52
53
54
55
56
57
58Vaudreuil Standards Track [Page 1]
59
60RFC 3030 Binary ESMTP December 2000
61
62
63Document Conventions
64
65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
67 document are to be interpreted as described in RFC 2119 [RFC2119].
68
69Table of Contents
70
71 1. Overview ................................................... 2
72 2. Framework for the Large Message Extensions ................. 3
73 3. Framework for the Binary Service Extension ................. 5
74 4. Examples ................................................... 8
75 4.1 Simple Chunking .......................................... 8
76 4.2 Pipelining BINARYMIME .................................... 8
77 5. Security Considerations .................................... 9
78 6. References ................................................. 9
79 7. Author's Address ........................................... 10
80 8. Appendix A - Changes from RFC 1830 ......................... 11
81 9. Full Copyright Statement ................................... 12
82
831. Overview
84
85 The MIME extensions to the Internet message format provides for the
86 transmission of many kinds of data that were previously unsupported
87 in Internet mail. Anticipating the need to transport the new media
88 more efficiently, the SMTP protocol has been extended to provide
89 transport for new message types. RFC 1652 defines one such extension
90 for the transmission of unencoded 8-bit MIME messages [8BIT]. This
91 service extension permits the receiver SMTP to declare support for
92 8-bit body parts and the sender to request 8-bit transmission of a
93 particular message.
94
95 One expected result of the use of MIME is that the Internet mail
96 system will be expected to carry very large mail messages. In such
97 transactions, there is a performance-based desire to eliminate the
98 requirement that the message be scanned for "CR LF . CR LF" sequences
99 upon sending and receiving to detect the end of message.
100
101 Independent of the need to send large messages, Internet mail is
102 increasingly multimedia. There is a need to avoid the overhead of
103 base64 and quoted-printable encoding of binary objects sent using the
104 MIME message format over SMTP between hosts that support binary
105 message processing.
106
107
108
109
110
111
112
113
114Vaudreuil Standards Track [Page 2]
115
116RFC 3030 Binary ESMTP December 2000
117
118
119 This memo uses the mechanism defined in [ESMTP] to define two
120 extensions to the SMTP service whereby an SMTP server ("receiver-
121 SMTP") may declare support for the message chunking transmission mode
122 and support for the reception of Binary messages, which the SMTP
123 client ("sender-SMTP") is then free to use.
124
1252. Framework for the Large Message Extensions
126
127 The following service extension is hereby defined:
128
129 1) The name of the data chunking service extension is "CHUNKING".
130
131 2) The EHLO keyword value associated with this extension is
132 "CHUNKING".
133
134 3) A new SMTP verb, BDAT, is defined as an alternative to the "DATA"
135 command of [RFC821]. The BDAT verb takes two arguments. The
136 first argument indicates the length, in octets, of the binary data
137 chunk. The second optional argument indicates that the data chunk
138 is the last.
139
140 bdat-cmd ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF
141 chunk-size ::= 1*DIGIT
142 end-marker ::= "LAST"
143
144 4) This extension may be used for SMTP message submission. [Submit]
145
146 5) Servers that offer the BDAT extension MUST continue to support the
147 regular SMTP DATA command. Clients are free to use DATA to
148 transfer appropriately encoded to servers that support the
149 CHUNKING extension if they wish to do so.
150
151 The CHUNKING service extension enables the use of the BDAT
152 alternative to the DATA command. This extension can be used for any
153 message, whether 7-bit, 8BITMIME or BINARYMIME.
154
155 When a sender-SMTP wishes to send (using the MAIL command) a large
156 message using the CHUNKING extension, it first issues the EHLO
157 command to the receiver-SMTP. If the receiver-SMTP responds with
158 code 250 to the EHLO command and the response includes the EHLO
159 keyword value CHUNKING, then the receiver-SMTP is indicating that it
160 supports the BDAT command and will accept the sending of messages in
161 chunks.
162
163 After all MAIL and RCPT responses are collected and processed, the
164 message is sent using a series of BDAT commands. The BDAT command
165 takes one required argument, the exact length of the data segment in
166
167
168
169
170Vaudreuil Standards Track [Page 3]
171
172RFC 3030 Binary ESMTP December 2000
173
174
175 octets. The message data is sent immediately after the trailing <CR>
176 <LF> of the BDAT command line. Once the receiver-SMTP receives the
177 specified number of octets, it will return a 250 reply code.
178
179 The optional LAST parameter on the BDAT command indicates that this
180 is the last chunk of message data to be sent. The last BDAT command
181 MAY have a byte-count of zero indicating there is no additional data
182 to be sent. Any BDAT command sent after the BDAT LAST is illegal and
183 MUST be replied to with a 503 "Bad sequence of commands" reply code.
184 The state resulting from this error is indeterminate. A RSET command
185 MUST be sent to clear the transaction before continuing.
186
187 A 250 response MUST be sent to each successful BDAT data block within
188 a mail transaction. If a failure occurs after a BDAT command is
189 received, the receiver-SMTP MUST accept and discard the associated
190 message data before sending the appropriate 5XX or 4XX code. If a
191 5XX or 4XX code is received by the sender-SMTP in response to a BDAT
192 chunk, the transaction should be considered failed and the sender-
193 SMTP MUST NOT send any additional BDAT segments. If the receiver-
194 SMTP has declared support for command pipelining [PIPE], the receiver
195 SMTP MUST be prepared to accept and discard additional BDAT chunks
196 already in the pipeline after the failed BDAT.
197
198 Note: An error on the receiver-SMTP such as disk full or imminent
199 shutdown can only be reported after the BDAT segment has been
200 received. It is therefore important to choose a reasonable chunk
201 size given the expected end-to-end bandwidth.
202
203 Note: Because the receiver-SMTP does not acknowledge the BDAT
204 command before the message data is sent, it is important to send
205 the BDAT only to systems that have declared their capability to
206 accept BDAT commands. Illegally sending a BDAT command and
207 associated message data to a non-CHUNKING capable system will
208 result in the receiver-SMTP parsing the associated message data as
209 if it were a potentially very long, ESMTP command line containing
210 binary data.
211
212 The resulting state from a failed BDAT command is indeterminate. A
213 RSET command MUST be issued to clear the transaction before
214 additional commands may be sent. The RSET command, when issued after
215 the first BDAT and before the BDAT LAST, clears all segments sent
216 during that transaction and resets the session.
217
218 DATA and BDAT commands cannot be used in the same transaction. If a
219 DATA statement is issued after a BDAT for the current transaction, a
220 503 "Bad sequence of commands" MUST be issued. The state resulting
221 from this error is indeterminate. A RSET command MUST be sent to
222
223
224
225
226Vaudreuil Standards Track [Page 4]
227
228RFC 3030 Binary ESMTP December 2000
229
230
231 clear the transaction before continuing. There is no prohibition on
232 using DATA and BDAT in the same session, so long as they are not
233 mixed in the same transaction.
234
235 The local storage size of a message may not accurately reflect the
236 actual size of the message sent due to local storage conventions. In
237 particular, text messages sent with the BDAT command MUST be sent in
238 the canonical MIME format with lines delimited with a <CR><LF>. It
239 may not be possible to convert the entire message to the canonical
240 format at once. CHUNKING provides a mechanism to convert the message
241 to canonical form, accurately count the bytes, and send the message a
242 single chunk at a time.
243
244 Note: Correct byte counting is essential. If the sender-SMTP
245 indicates a chunk-size larger than the actual chunk-size, the
246 receiver-SMTP will continue to wait for the remainder of the data
247 or when using streaming, will read the subsequent command as
248 additional message data. In the case where a portion of the
249 previous command was read as data, the parser will return a syntax
250 error when the incomplete command is read.
251
252 If the sender-SMTP indicates a chunk-size smaller than the actual
253 chunk-size, the receiver-SMTP will interpret the remainder of the
254 message data as invalid commands. Note that the remainder of the
255 message data may be binary and as such lexicographical parsers
256 MUST be prepared to receive, process, and reject lines of
257 arbitrary octets.
258
2593. Framework for the Binary Service Extension
260
261 The following service extension is hereby defined:
262
263 1) The name of the binary service extension is "BINARYMIME".
264
265 2) The EHLO keyword value associated with this extension is
266 "BINARYMIME".
267
268 3) The BINARYMIME service extension can only be used with the
269 "CHUNKING" service extension.
270
271 4) No parameter is used with the BINARYMIME keyword.
272
273 5) [8BIT] defines the BODY parameter for the MAIL command. This
274 extension defines an additional value for the BODY parameter,
275 "BINARYMIME". The value "BINARYMIME" associated with this
276 parameter indicates that this message is a Binary MIME message (in
277
278
279
280
281
282Vaudreuil Standards Track [Page 5]
283
284RFC 3030 Binary ESMTP December 2000
285
286
287 strict compliance with [MIME]) with arbitrary octet content being
288 sent. The revised syntax of the value is as follows, using the
289 ABNF notation of [RFC822]:
290
291 body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
292
293 6) No new verbs are defined for the BINARYMIME extension.
294
295 7) This extension may be used for SMTP message submission. [Submit]
296
297 8) The maximum length of a MAIL FROM command line is increased by 16
298 characters by the possible addition of the BODY=BINARYMIME keyword
299 and value;.
300
301 A sender-SMTP may request that a binary MIME message be sent without
302 transport encoding by sending a BODY parameter with a value of
303 "BINARYMIME" with the MAIL command. When the receiver-SMTP accepts a
304 MAIL command with the BINARYMIME body-value, it agrees to preserve
305 all bits in each octet passed using the BDAT command. Once a
306 receiver-SMTP supporting the BINARYMIME service extension accepts a
307 message containing binary material, the receiver-SMTP MUST deliver or
308 relay the message in such a way as to preserve all bits in each
309 octet.
310
311 BINARYMIME cannot be used with the DATA command. If a DATA command
312 is issued after a MAIL command containing the body-value of
313 "BINARYMIME", a 503 "Bad sequence of commands" response MUST be sent.
314 The resulting state from this error condition is indeterminate and
315 the transaction MUST be reset with the RSET command.
316
317 It is especially important when using BINARYMIME to ensure that the
318 MIME message itself is properly formed. In particular, it is
319 essential that text be canonically encoded with each line properly
320 terminated with <CR><LF>. Any transformation of text into non-
321 canonical MIME to observe local storage conventions MUST be reversed
322 before sending as BINARYMIME. Some line-oriented shortcuts will
323 break if used with BINARYMIME. A sender-SMTP MUST use the canonical
324 encoding for a given MIME content-type. In particular, text/* MUST
325 be sent with <CR><LF> terminated lines.
326
327 Note: Although CR and LF do not necessarily represent ends of text
328 lines in BDAT chunks and use of the binary transfer encoding is
329 allowed, the RFC 2781 prohibition against using a UTF-16 charset
330 within the text top-level media type remains.
331
332
333
334
335
336
337
338Vaudreuil Standards Track [Page 6]
339
340RFC 3030 Binary ESMTP December 2000
341
342
343 The syntax of the extended MAIL command is identical to the MAIL
344 command in [RFC821], except that a BODY=BINARYMIME parameter and
345 value MUST be added. The complete syntax of this extended command is
346 defined in [ESMTP].
347
348 If a receiver-SMTP does not indicate support the BINARYMIME message
349 format then the sender-SMTP MUST NOT, under any circumstances, send
350 binary data.
351
352 If the receiver-SMTP does not support BINARYMIME and the message to
353 be sent is a MIME object with a binary encoding, a sender-SMTP has
354 three options with which to forward the message. First, if the
355 receiver-SMTP supports the 8bit-MIMEtransport extension [8bit] and
356 the content is amenable to being encoded in 8bit, the sender-SMTP may
357 implement a gateway transformation to convert the message into valid
358 8bit-encoded MIME. Second, it may implement a gateway transformation
359 to convert the message into valid 7bit-encoded MIME. Third, it may
360 treat this as a permanent error and handle it in the usual manner for
361 delivery failures. The specifics of MIME content-transfer-encodings,
362 including transformations from Binary MIME to 8bit or 7bit MIME are
363 not described by this RFC; the conversion is nevertheless constrained
364 in the following ways:
365
366 1. The conversion MUST cause no loss of information; MIME
367 transport encodings MUST be employed as needed to insure this
368 is the case.
369
370 2. The resulting message MUST be valid 7bit or 8bit MIME. In
371 particular, the transformation MUST NOT result in nested Base-
372 64 or Quoted-Printable content-transfer-encodings.
373
374 Note that at the time of this writing there are no mechanisms for
375 converting a binary MIME object into an 8-bit MIME object. Such a
376 transformation will require the specification of a new MIME content-
377 transfer-encoding.
378
379 If the MIME message contains a "Binary" content-transfer-encoding and
380 the BODY parameter does not indicate BINARYMIME, the message MUST be
381 accepted. The message SHOULD be returned to the sender with an
382 appropriate DSN. The message contents MAY be returned to the sender
383 if the offending content can be mangled into a legal DSN structure.
384 "Fixing" and forwarding the offending content is beyond the scope of
385 this document.
386
387
388
389
390
391
392
393
394Vaudreuil Standards Track [Page 7]
395
396RFC 3030 Binary ESMTP December 2000
397
398
3994. Examples
400
4014.1 Simple Chunking
402
403 The following simple dialogue illustrates the use of the large
404 message extension to send a short pseudo-RFC 822 message to one
405 recipient using the CHUNKING extension:
406
407 R: <wait for connection on TCP port 25>
408 S: <open connection to server>
409 R: 220 cnri.reston.va.us SMTP service ready
410 S: EHLO ymir.claremont.edu
411 R: 250-cnri.reston.va.us says hello
412 R: 250 CHUNKING
413 S: MAIL FROM:<Sam@Random.com>
414 R: 250 <Sam@Random.com> Sender ok
415 S: RCPT TO:<Susan@Random.com>
416 R: 250 <Susan@random.com> Recipient ok
417 S: BDAT 86 LAST
418 S: To: Susan@random.com<CR><LF>
419 S: From: Sam@random.com<CR><LF>
420 S: Subject: This is a bodyless test message<CR><LF>
421 R: 250 Message OK, 86 octets received
422 S: QUIT
423 R: 221 Goodbye
424
4254.2 Pipelining BINARYMIME
426
427 The following dialogue illustrates the use of the large message
428 extension to send a BINARYMIME object to two recipients using the
429 CHUNKING and PIPELINING extensions:
430
431 R: <wait for connection on TCP port
432 S: <open connection to server>
433 R: 220 cnri.reston.va.us SMTP service ready
434 S: EHLO ymir.claremont.edu
435 R: 250-cnri.reston.va.us says hello
436 R: 250-PIPELINING
437 R: 250-BINARYMIME
438 R: 250 CHUNKING
439 S: MAIL FROM:<ned@ymir.claremont.edu> BODY=BINARYMIME
440 S: RCPT TO:<gvaudre@cnri.reston.va.us>
441 S: RCPT TO:<jstewart@cnri.reston.va.us>
442 R: 250 <ned@ymir.claremont.edu>... Sender and BINARYMIME ok
443 R: 250 <gvaudre@cnri.reston.va.us>... Recipient ok
444 R: 250 <jstewart@cnri.reston.va.us>... Recipient ok
445 S: BDAT 100000
446 S: (First 10000 octets of canonical MIME message data)
447
448
449
450Vaudreuil Standards Track [Page 8]
451
452RFC 3030 Binary ESMTP December 2000
453
454
455 S: BDAT 324
456 S: (Remaining 324 octets of canonical MIME message data)
457 S: BDAT 0 LAST
458 R: 250 100000 octets received
459 R: 250 324 octets received
460 R: 250 Message OK, 100324 octets received
461 S: QUIT
462 R: 221 Goodbye
463
4645. Security Considerations
465
466 This extension is not known to present any additional security issues
467 not already endemic to electronic mail and present in fully
468 conforming implementations of [RFC821], or otherwise made possible by
469 [MIME].
470
4716. References
472
473 [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of
474 Large and Binary MIME Messages", RFC 1830, August 1995.
475
476 [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
477 821, August 1982.
478
479 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
480 Messages", STD 11, RFC 822, August 1982.
481
482 [MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail
483 Extensions (MIME) Part One: Format of Internet Message
484 Bodies", RFC 2045, November 1996.
485
486 [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
487 December 1998.
488
489 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
490 Crocker, "SMTP Service Extensions", RFC 1869, November
491 1995.
492
493 [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
494 Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
495 RFC 1652, July 1994.
496
497 [PIPE] Freed, N., "SMTP Service Extensions for Command
498 Pipelining", RFC 2920, September 2000.
499
500 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
501 Requirement Levels", BCP 14, RFC 2119, March 1997.
502
503
504
505
506Vaudreuil Standards Track [Page 9]
507
508RFC 3030 Binary ESMTP December 2000
509
510
5117. Author's Address
512
513 Gregory M. Vaudreuil
514 Lucent Technologies
515 17080 Dallas Parkway
516 Dallas, TX 75248-1905
517
518 Phone/Fax: +1-972-733-2722
519 EMail: GregV@ieee.org
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562Vaudreuil Standards Track [Page 10]
563
564RFC 3030 Binary ESMTP December 2000
565
566
567Appendix A - Changes from RFC 1830
568
569 Numerous editorial changes including required intellectual property
570 boilerplate and revised authors contact information
571
572 Corrected the simple chunking example to use the correct number of
573 bytes. Updated the pipelining example to illustrate use of the BDAT
574 0 LAST construct.
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618Vaudreuil Standards Track [Page 11]
619
620RFC 3030 Binary ESMTP December 2000
621
622
623Full Copyright Statement
624
625 Copyright (C) The Internet Society (2000). All Rights Reserved.
626
627 This document and translations of it may be copied and furnished to
628 others, and derivative works that comment on or otherwise explain it
629 or assist in its implementation may be prepared, copied, published
630 and distributed, in whole or in part, without restriction of any
631 kind, provided that the above copyright notice and this paragraph are
632 included on all such copies and derivative works. However, this
633 document itself may not be modified in any way, such as by removing
634 the copyright notice or references to the Internet Society or other
635 Internet organizations, except as needed for the purpose of
636 developing Internet standards in which case the procedures for
637 copyrights defined in the Internet Standards process must be
638 followed, or as required to translate it into languages other than
639 English.
640
641 The limited permissions granted above are perpetual and will not be
642 revoked by the Internet Society or its successors or assigns.
643
644 This document and the information contained herein is provided on an
645 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
646 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
647 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
648 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
649 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
650
651Acknowledgement
652
653 Funding for the RFC Editor function is currently provided by the
654 Internet Society.
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674Vaudreuil Standards Track [Page 12]
675
676