summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3030.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3030.txt')
-rw-r--r--doc/rfc/rfc3030.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc3030.txt b/doc/rfc/rfc3030.txt
new file mode 100644
index 0000000..821b675
--- /dev/null
+++ b/doc/rfc/rfc3030.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group G. Vaudreuil
+Request for Comments: 3030 Lucent Technologies
+Obsolete: 1830 December 2000
+Category: Standards Track
+
+
+ SMTP Service Extensions
+ for Transmission of Large
+ and Binary MIME Messages
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This memo defines two extensions to the SMTP (Simple Mail Transfer
+ Protocol) service. The first extension enables a SMTP client and
+ server to negotiate the use of an alternative to the DATA command,
+ called "BDAT", for efficiently sending large MIME (Multipurpose
+ Internet Mail Extensions) messages. The second extension takes
+ advantage of the BDAT command to permit the negotiated sending of
+ MIME messages that employ the binary transfer encoding. This
+ document is intended to update and obsolete RFC 1830.
+
+Working Group Summary
+
+ This protocol is not the product of an IETF working group, however
+ the specification resulted from discussions within the ESMTP working
+ group. The resulting protocol documented in RFC 1830 was classified
+ as experimental at that time due to questions about the robustness of
+ the Binary Content-Transfer-Encoding deployed in then existent MIME
+ implementations. As MIME has matured and other uses of the Binary
+ Content-Transfer-Encoding have been deployed, these concerns have
+ been allayed. With this document, Binary ESMTP is expected to become
+ standards-track.
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 1]
+
+RFC 3030 Binary ESMTP December 2000
+
+
+Document Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+Table of Contents
+
+ 1. Overview ................................................... 2
+ 2. Framework for the Large Message Extensions ................. 3
+ 3. Framework for the Binary Service Extension ................. 5
+ 4. Examples ................................................... 8
+ 4.1 Simple Chunking .......................................... 8
+ 4.2 Pipelining BINARYMIME .................................... 8
+ 5. Security Considerations .................................... 9
+ 6. References ................................................. 9
+ 7. Author's Address ........................................... 10
+ 8. Appendix A - Changes from RFC 1830 ......................... 11
+ 9. Full Copyright Statement ................................... 12
+
+1. Overview
+
+ The MIME extensions to the Internet message format provides for the
+ transmission of many kinds of data that were previously unsupported
+ in Internet mail. Anticipating the need to transport the new media
+ more efficiently, the SMTP protocol has been extended to provide
+ transport for new message types. RFC 1652 defines one such extension
+ for the transmission of unencoded 8-bit MIME messages [8BIT]. This
+ service extension permits the receiver SMTP to declare support for
+ 8-bit body parts and the sender to request 8-bit transmission of a
+ particular message.
+
+ One expected result of the use of MIME is that the Internet mail
+ system will be expected to carry very large mail messages. In such
+ transactions, there is a performance-based desire to eliminate the
+ requirement that the message be scanned for "CR LF . CR LF" sequences
+ upon sending and receiving to detect the end of message.
+
+ Independent of the need to send large messages, Internet mail is
+ increasingly multimedia. There is a need to avoid the overhead of
+ base64 and quoted-printable encoding of binary objects sent using the
+ MIME message format over SMTP between hosts that support binary
+ message processing.
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 2]
+
+RFC 3030 Binary ESMTP December 2000
+
+
+ This memo uses the mechanism defined in [ESMTP] to define two
+ extensions to the SMTP service whereby an SMTP server ("receiver-
+ SMTP") may declare support for the message chunking transmission mode
+ and support for the reception of Binary messages, which the SMTP
+ client ("sender-SMTP") is then free to use.
+
+2. Framework for the Large Message Extensions
+
+ The following service extension is hereby defined:
+
+ 1) The name of the data chunking service extension is "CHUNKING".
+
+ 2) The EHLO keyword value associated with this extension is
+ "CHUNKING".
+
+ 3) A new SMTP verb, BDAT, is defined as an alternative to the "DATA"
+ command of [RFC821]. The BDAT verb takes two arguments. The
+ first argument indicates the length, in octets, of the binary data
+ chunk. The second optional argument indicates that the data chunk
+ is the last.
+
+ bdat-cmd ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF
+ chunk-size ::= 1*DIGIT
+ end-marker ::= "LAST"
+
+ 4) This extension may be used for SMTP message submission. [Submit]
+
+ 5) Servers that offer the BDAT extension MUST continue to support the
+ regular SMTP DATA command. Clients are free to use DATA to
+ transfer appropriately encoded to servers that support the
+ CHUNKING extension if they wish to do so.
+
+ The CHUNKING service extension enables the use of the BDAT
+ alternative to the DATA command. This extension can be used for any
+ message, whether 7-bit, 8BITMIME or BINARYMIME.
+
+ When a sender-SMTP wishes to send (using the MAIL command) a large
+ message using the CHUNKING extension, it first issues the EHLO
+ command to the receiver-SMTP. If the receiver-SMTP responds with
+ code 250 to the EHLO command and the response includes the EHLO
+ keyword value CHUNKING, then the receiver-SMTP is indicating that it
+ supports the BDAT command and will accept the sending of messages in
+ chunks.
+
+ After all MAIL and RCPT responses are collected and processed, the
+ message is sent using a series of BDAT commands. The BDAT command
+ takes one required argument, the exact length of the data segment in
+
+
+
+
+Vaudreuil Standards Track [Page 3]
+
+RFC 3030 Binary ESMTP December 2000
+
+
+ octets. The message data is sent immediately after the trailing <CR>
+ <LF> of the BDAT command line. Once the receiver-SMTP receives the
+ specified number of octets, it will return a 250 reply code.
+
+ The optional LAST parameter on the BDAT command indicates that this
+ is the last chunk of message data to be sent. The last BDAT command
+ MAY have a byte-count of zero indicating there is no additional data
+ to be sent. Any BDAT command sent after the BDAT LAST is illegal and
+ MUST be replied to with a 503 "Bad sequence of commands" reply code.
+ The state resulting from this error is indeterminate. A RSET command
+ MUST be sent to clear the transaction before continuing.
+
+ A 250 response MUST be sent to each successful BDAT data block within
+ a mail transaction. If a failure occurs after a BDAT command is
+ received, the receiver-SMTP MUST accept and discard the associated
+ message data before sending the appropriate 5XX or 4XX code. If a
+ 5XX or 4XX code is received by the sender-SMTP in response to a BDAT
+ chunk, the transaction should be considered failed and the sender-
+ SMTP MUST NOT send any additional BDAT segments. If the receiver-
+ SMTP has declared support for command pipelining [PIPE], the receiver
+ SMTP MUST be prepared to accept and discard additional BDAT chunks
+ already in the pipeline after the failed BDAT.
+
+ Note: An error on the receiver-SMTP such as disk full or imminent
+ shutdown can only be reported after the BDAT segment has been
+ received. It is therefore important to choose a reasonable chunk
+ size given the expected end-to-end bandwidth.
+
+ Note: Because the receiver-SMTP does not acknowledge the BDAT
+ command before the message data is sent, it is important to send
+ the BDAT only to systems that have declared their capability to
+ accept BDAT commands. Illegally sending a BDAT command and
+ associated message data to a non-CHUNKING capable system will
+ result in the receiver-SMTP parsing the associated message data as
+ if it were a potentially very long, ESMTP command line containing
+ binary data.
+
+ The resulting state from a failed BDAT command is indeterminate. A
+ RSET command MUST be issued to clear the transaction before
+ additional commands may be sent. The RSET command, when issued after
+ the first BDAT and before the BDAT LAST, clears all segments sent
+ during that transaction and resets the session.
+
+ DATA and BDAT commands cannot be used in the same transaction. If a
+ DATA statement is issued after a BDAT for the current transaction, a
+ 503 "Bad sequence of commands" MUST be issued. The state resulting
+ from this error is indeterminate. A RSET command MUST be sent to
+
+
+
+
+Vaudreuil Standards Track [Page 4]
+
+RFC 3030 Binary ESMTP December 2000
+
+
+ clear the transaction before continuing. There is no prohibition on
+ using DATA and BDAT in the same session, so long as they are not
+ mixed in the same transaction.
+
+ The local storage size of a message may not accurately reflect the
+ actual size of the message sent due to local storage conventions. In
+ particular, text messages sent with the BDAT command MUST be sent in
+ the canonical MIME format with lines delimited with a <CR><LF>. It
+ may not be possible to convert the entire message to the canonical
+ format at once. CHUNKING provides a mechanism to convert the message
+ to canonical form, accurately count the bytes, and send the message a
+ single chunk at a time.
+
+ Note: Correct byte counting is essential. If the sender-SMTP
+ indicates a chunk-size larger than the actual chunk-size, the
+ receiver-SMTP will continue to wait for the remainder of the data
+ or when using streaming, will read the subsequent command as
+ additional message data. In the case where a portion of the
+ previous command was read as data, the parser will return a syntax
+ error when the incomplete command is read.
+
+ If the sender-SMTP indicates a chunk-size smaller than the actual
+ chunk-size, the receiver-SMTP will interpret the remainder of the
+ message data as invalid commands. Note that the remainder of the
+ message data may be binary and as such lexicographical parsers
+ MUST be prepared to receive, process, and reject lines of
+ arbitrary octets.
+
+3. Framework for the Binary Service Extension
+
+ The following service extension is hereby defined:
+
+ 1) The name of the binary service extension is "BINARYMIME".
+
+ 2) The EHLO keyword value associated with this extension is
+ "BINARYMIME".
+
+ 3) The BINARYMIME service extension can only be used with the
+ "CHUNKING" service extension.
+
+ 4) No parameter is used with the BINARYMIME keyword.
+
+ 5) [8BIT] defines the BODY parameter for the MAIL command. This
+ extension defines an additional value for the BODY parameter,
+ "BINARYMIME". The value "BINARYMIME" associated with this
+ parameter indicates that this message is a Binary MIME message (in
+
+
+
+
+
+Vaudreuil Standards Track [Page 5]
+
+RFC 3030 Binary ESMTP December 2000
+
+
+ strict compliance with [MIME]) with arbitrary octet content being
+ sent. The revised syntax of the value is as follows, using the
+ ABNF notation of [RFC822]:
+
+ body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
+
+ 6) No new verbs are defined for the BINARYMIME extension.
+
+ 7) This extension may be used for SMTP message submission. [Submit]
+
+ 8) The maximum length of a MAIL FROM command line is increased by 16
+ characters by the possible addition of the BODY=BINARYMIME keyword
+ and value;.
+
+ A sender-SMTP may request that a binary MIME message be sent without
+ transport encoding by sending a BODY parameter with a value of
+ "BINARYMIME" with the MAIL command. When the receiver-SMTP accepts a
+ MAIL command with the BINARYMIME body-value, it agrees to preserve
+ all bits in each octet passed using the BDAT command. Once a
+ receiver-SMTP supporting the BINARYMIME service extension accepts a
+ message containing binary material, the receiver-SMTP MUST deliver or
+ relay the message in such a way as to preserve all bits in each
+ octet.
+
+ BINARYMIME cannot be used with the DATA command. If a DATA command
+ is issued after a MAIL command containing the body-value of
+ "BINARYMIME", a 503 "Bad sequence of commands" response MUST be sent.
+ The resulting state from this error condition is indeterminate and
+ the transaction MUST be reset with the RSET command.
+
+ It is especially important when using BINARYMIME to ensure that the
+ MIME message itself is properly formed. In particular, it is
+ essential that text be canonically encoded with each line properly
+ terminated with <CR><LF>. Any transformation of text into non-
+ canonical MIME to observe local storage conventions MUST be reversed
+ before sending as BINARYMIME. Some line-oriented shortcuts will
+ break if used with BINARYMIME. A sender-SMTP MUST use the canonical
+ encoding for a given MIME content-type. In particular, text/* MUST
+ be sent with <CR><LF> terminated lines.
+
+ Note: Although CR and LF do not necessarily represent ends of text
+ lines in BDAT chunks and use of the binary transfer encoding is
+ allowed, the RFC 2781 prohibition against using a UTF-16 charset
+ within the text top-level media type remains.
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 6]
+
+RFC 3030 Binary ESMTP December 2000
+
+
+ The syntax of the extended MAIL command is identical to the MAIL
+ command in [RFC821], except that a BODY=BINARYMIME parameter and
+ value MUST be added. The complete syntax of this extended command is
+ defined in [ESMTP].
+
+ If a receiver-SMTP does not indicate support the BINARYMIME message
+ format then the sender-SMTP MUST NOT, under any circumstances, send
+ binary data.
+
+ If the receiver-SMTP does not support BINARYMIME and the message to
+ be sent is a MIME object with a binary encoding, a sender-SMTP has
+ three options with which to forward the message. First, if the
+ receiver-SMTP supports the 8bit-MIMEtransport extension [8bit] and
+ the content is amenable to being encoded in 8bit, the sender-SMTP may
+ implement a gateway transformation to convert the message into valid
+ 8bit-encoded MIME. Second, it may implement a gateway transformation
+ to convert the message into valid 7bit-encoded MIME. Third, it may
+ treat this as a permanent error and handle it in the usual manner for
+ delivery failures. The specifics of MIME content-transfer-encodings,
+ including transformations from Binary MIME to 8bit or 7bit MIME are
+ not described by this RFC; the conversion is nevertheless constrained
+ in the following ways:
+
+ 1. The conversion MUST cause no loss of information; MIME
+ transport encodings MUST be employed as needed to insure this
+ is the case.
+
+ 2. The resulting message MUST be valid 7bit or 8bit MIME. In
+ particular, the transformation MUST NOT result in nested Base-
+ 64 or Quoted-Printable content-transfer-encodings.
+
+ Note that at the time of this writing there are no mechanisms for
+ converting a binary MIME object into an 8-bit MIME object. Such a
+ transformation will require the specification of a new MIME content-
+ transfer-encoding.
+
+ If the MIME message contains a "Binary" content-transfer-encoding and
+ the BODY parameter does not indicate BINARYMIME, the message MUST be
+ accepted. The message SHOULD be returned to the sender with an
+ appropriate DSN. The message contents MAY be returned to the sender
+ if the offending content can be mangled into a legal DSN structure.
+ "Fixing" and forwarding the offending content is beyond the scope of
+ this document.
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 7]
+
+RFC 3030 Binary ESMTP December 2000
+
+
+4. Examples
+
+4.1 Simple Chunking
+
+ The following simple dialogue illustrates the use of the large
+ message extension to send a short pseudo-RFC 822 message to one
+ recipient using the CHUNKING extension:
+
+ R: <wait for connection on TCP port 25>
+ S: <open connection to server>
+ R: 220 cnri.reston.va.us SMTP service ready
+ S: EHLO ymir.claremont.edu
+ R: 250-cnri.reston.va.us says hello
+ R: 250 CHUNKING
+ S: MAIL FROM:<Sam@Random.com>
+ R: 250 <Sam@Random.com> Sender ok
+ S: RCPT TO:<Susan@Random.com>
+ R: 250 <Susan@random.com> Recipient ok
+ S: BDAT 86 LAST
+ S: To: Susan@random.com<CR><LF>
+ S: From: Sam@random.com<CR><LF>
+ S: Subject: This is a bodyless test message<CR><LF>
+ R: 250 Message OK, 86 octets received
+ S: QUIT
+ R: 221 Goodbye
+
+4.2 Pipelining BINARYMIME
+
+ The following dialogue illustrates the use of the large message
+ extension to send a BINARYMIME object to two recipients using the
+ CHUNKING and PIPELINING extensions:
+
+ R: <wait for connection on TCP port
+ S: <open connection to server>
+ R: 220 cnri.reston.va.us SMTP service ready
+ S: EHLO ymir.claremont.edu
+ R: 250-cnri.reston.va.us says hello
+ R: 250-PIPELINING
+ R: 250-BINARYMIME
+ R: 250 CHUNKING
+ S: MAIL FROM:<ned@ymir.claremont.edu> BODY=BINARYMIME
+ S: RCPT TO:<gvaudre@cnri.reston.va.us>
+ S: RCPT TO:<jstewart@cnri.reston.va.us>
+ R: 250 <ned@ymir.claremont.edu>... Sender and BINARYMIME ok
+ R: 250 <gvaudre@cnri.reston.va.us>... Recipient ok
+ R: 250 <jstewart@cnri.reston.va.us>... Recipient ok
+ S: BDAT 100000
+ S: (First 10000 octets of canonical MIME message data)
+
+
+
+Vaudreuil Standards Track [Page 8]
+
+RFC 3030 Binary ESMTP December 2000
+
+
+ S: BDAT 324
+ S: (Remaining 324 octets of canonical MIME message data)
+ S: BDAT 0 LAST
+ R: 250 100000 octets received
+ R: 250 324 octets received
+ R: 250 Message OK, 100324 octets received
+ S: QUIT
+ R: 221 Goodbye
+
+5. Security Considerations
+
+ This extension is not known to present any additional security issues
+ not already endemic to electronic mail and present in fully
+ conforming implementations of [RFC821], or otherwise made possible by
+ [MIME].
+
+6. References
+
+ [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of
+ Large and Binary MIME Messages", RFC 1830, August 1995.
+
+ [RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
+ 821, August 1982.
+
+ [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text
+ Messages", STD 11, RFC 822, August 1982.
+
+ [MIME] Borenstein, N. and N. Freed, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message
+ Bodies", RFC 2045, November 1996.
+
+ [SUBMIT] Gellens, R. and J. Klensin, "Message Submission", RFC 2476,
+ December 1998.
+
+ [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
+ Crocker, "SMTP Service Extensions", RFC 1869, November
+ 1995.
+
+ [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
+ Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
+ RFC 1652, July 1994.
+
+ [PIPE] Freed, N., "SMTP Service Extensions for Command
+ Pipelining", RFC 2920, September 2000.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+Vaudreuil Standards Track [Page 9]
+
+RFC 3030 Binary ESMTP December 2000
+
+
+7. Author's Address
+
+ Gregory M. Vaudreuil
+ Lucent Technologies
+ 17080 Dallas Parkway
+ Dallas, TX 75248-1905
+
+ Phone/Fax: +1-972-733-2722
+ EMail: GregV@ieee.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 10]
+
+RFC 3030 Binary ESMTP December 2000
+
+
+Appendix A - Changes from RFC 1830
+
+ Numerous editorial changes including required intellectual property
+ boilerplate and revised authors contact information
+
+ Corrected the simple chunking example to use the correct number of
+ bytes. Updated the pipelining example to illustrate use of the BDAT
+ 0 LAST construct.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 11]
+
+RFC 3030 Binary ESMTP December 2000
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil Standards Track [Page 12]
+