< draft-vaudreuil-esmtp-binary2-02.txt   draft-vaudreuil-esmtp-binary2-03.txt >
Internet Draft Greg Vaudreuil Internet Draft Greg Vaudreuil
Expires in six months Lucent Technologies Expires in six months Lucent Technologies
August 10, 2000 October 19, 2000
SMTP Service Extensions SMTP Service Extensions
for Transmission of Large for Transmission of Large
and Binary MIME Messages and Binary MIME Messages
<draft-vaudreuil-esmtp-binary2-02.txt <draft-vaudreuil-esmtp-binary2-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts. working documents as Internet Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
This Internet-Draft is in conformance with Section 10 of RFC 2026. This Internet-Draft is in conformance with Section 10 of RFC 2026.
Abstract Abstract
This memo defines two extensions to the SMTP service. The first This memo defines two extensions to the SMTP service. The first
service enables a SMTP client and server to negotiate the use of an extension enables a SMTP client and server to negotiate the use of an
alternative to the DATA command, called "BDAT" for efficiently sending alternative to the DATA command, called "BDAT", for efficiently
large MIME messages. The second extension takes advantage of the BDAT sending large MIME messages. The second extension takes advantage of
command to permit the negotiated sending of binary contents wrapped in the BDAT command to permit the negotiated sending of MIME messages
MIME but without a transport encoding. This document is intended to that employ the binary transfer encoding. This document is intended to
update and obsolete RFC1830. update and obsolete RFC1830.
Working Group Summary Working Group Summary
This protocol is not the product of an IETF working group, however the This protocol is not the product of an IETF working group, however the
specification resulted from discussions within the ESMTP working specification resulted from discussions within the ESMTP working
group. The resulting protocol documented in RFC1830 was classified as group. The resulting protocol documented in RFC1830 was classified as
experimental at that time due to questions about the robustness of the experimental at that time due to questions about the robustness of the
Binary Content-Transport-Encoding deployed in then existent MIME Binary Content-Transfer-Encoding deployed in then existent MIME
implementations. As MIME has matured and other uses of the Binary implementations. As MIME has matured and other uses of the Binary
Content-Transport-Encoding have been deployed, these concerns have Content-Transfer-Encoding have been deployed, these concerns have been
been allayed. With this document, Binary ESMTP is expected to become allayed. With this document, Binary ESMTP is expected to become
standards-track. standards-track.
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 Table of Contents
1. OVERVIEW ..........................................................2 1. OVERVIEW ..........................................................2
2. FRAMEWORK FOR THE LARGE MESSAGE EXTENSIONS ........................3 2. FRAMEWORK FOR THE LARGE MESSAGE EXTENSIONS ........................3
3. FRAMEWORK FOR THE BINARY SERVICE EXTENSION ........................6 3. FRAMEWORK FOR THE BINARY SERVICE EXTENSION ........................6
4. EXAMPLES ..........................................................8 4. EXAMPLES ..........................................................8
4.1 Simple Chunking .................................................8 4.1 Simple Chunking .................................................8
4.2 Pipelining BINARYMIME ...........................................9 4.2 Pipelining BINARYMIME ...........................................9
5. SECURITY CONSIDERATIONS ..........................................10 5. SECURITY CONSIDERATIONS ..........................................10
6. REFERENCES .......................................................10 6. REFERENCES .......................................................10
7. COPYRIGHT NOTICE .................................................10 7. COPYRIGHT NOTICE .................................................10
8. AUTHOR'S ADDRESS .................................................11 8. AUTHOR'S ADDRESS .................................................11
9. APPENDIX A - CHANGES FROM RFC1830 ................................12 9. APPENDIX A - CHANGES FROM RFC1830 ................................12
1. Overview 1. Overview
The MIME extensions to the Internet message protocol provides for the The MIME extensions to the Internet message format provides for the
transmission of many kinds of data that were previously unsupported in transmission of many kinds of data that were previously unsupported in
Internet mail. Anticipating the need to more efficiently transport Internet mail. Anticipating the need to transport the new media more
the new media made possible with MIME, the SMTP protocol has been efficiently, the SMTP protocol has been extended to provide transport
extended to provide transport for new message types. RFC 1652 defines for new message types. RFC 1652 defines one such extension for the
one such extension for the transmission of unencoded 8-bit MIME transmission of unencoded 8-bit MIME messages [8BIT]. This service
messages [8BIT]. This service extension permits the receiver SMTP to extension permits the receiver SMTP to declare support for 8-bit body
declare support for 8-bit body parts and the sender to request 8-bit parts and the sender to request 8-bit transmission of a particular
transmission of a particular message. message.
One expected result of the use of MIME is that the Internet mail 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 system will be expected to carry very large mail messages. In such
transactions, there is a performance-based desire to eliminate the transactions, there is a performance-based desire to eliminate the
requirement that the message be scanned for "CR LF . CR LF" sequences requirement that the message be scanned for "CR LF . CR LF" sequences
upon sending and receiving to detect the end of message. upon sending and receiving to detect the end of message.
Independent of the need to send large messages, Internet mail is Independent of the need to send large messages, Internet mail is
increasingly multimedia. There is a need to avoid the overhead of increasingly multimedia. There is a need to avoid the overhead of
base64 and quoted-printable encoding of binary objects sent using the base64 and quoted-printable encoding of binary objects sent using the
MIME message format over SMTP between hosts that support binary MIME message format over SMTP between hosts that support binary
message processing. message processing.
This memo uses the mechanism defined in [ESMTP] to define two This memo uses the mechanism defined in [ESMTP] to define two
extensions to the SMTP service whereby a client ("sender-SMTP") may extensions to the SMTP service whereby an SMTP server ("receiver-
declare support for the message chunking transmission mode and support SMTP") may declare support for the message chunking transmission mode
for the receiption of Binary messages. and support for the receiption of Binary messages, which the SMTP
client ("sender-SMTP") is then free to use.
2. Framework for the Large Message Extensions 2. Framework for the Large Message Extensions
The following service extension is hereby defined: The following service extension is hereby defined:
1) The name of the data chunking service extension is "CHUNKING". 1) The name of the data chunking service extension is "CHUNKING".
2) The EHLO keyword value associated with this extension is 2) The EHLO keyword value associated with this extension is
"CHUNKING". "CHUNKING".
3) A new SMTP verb is defined "BDAT" as an alternative to the "DATA" 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 command of [RFC821]. The BDAT verb takes two arguments. The first
argument indicates the length, in octets, of the binary data chunk. argument indicates the length, in octets, of the binary data chunk.
The second optional argument indicates that the data chunk is the The second optional argument indicates that the data chunk is the
last. last.
bdat-cmd ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF bdat-cmd ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF
chunk-size ::= 1*DIGIT chunk-size ::= 1*DIGIT
end-marker ::= "LAST" end-marker ::= "LAST"
4) This extension may be used for SMTP message submission. [Submit] 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 The CHUNKING service extension enables the use of the BDAT alternative
to the DATA command. This extension can be used for any message, to the DATA command. This extension can be used for any message,
whether 7-bit, 8BITMIME or BINARYMIME. whether 7-bit, 8BITMIME or BINARYMIME.
When a sender-SMTP wishes to send (using the MAIL command) a large When a sender-SMTP wishes to send (using the MAIL command) a large
message using the CHUNKING extension, it first issues the EHLO command message using the CHUNKING extension, it first issues the EHLO command
to the receiver-SMTP. If the receiver-SMTP responds with code 250 to to the receiver-SMTP. If the receiver-SMTP responds with code 250 to
the EHLO command and the response includes the EHLO keyword value the EHLO command and the response includes the EHLO keyword value
CHUNKING, then the receiver-SMTP is indicating that it supports the CHUNKING, then the receiver-SMTP is indicating that it supports the
BDAT command and will accept the sending of messages in chunks. BDAT command and will accept the sending of messages in chunks.
skipping to change at page 3, line 54 skipping to change at page 4, line 13
specified number of octets, it will return a 250 reply code. specified number of octets, it will return a 250 reply code.
The optional LAST parameter on the BDAT command indicates that this is 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 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 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 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 replied to with a 503 "Bad sequence of commands" reply code. The state
resulting from this error is indeterminate. A RSET command MUST be resulting from this error is indeterminate. A RSET command MUST be
sent to clear the transaction before continuing. sent to clear the transaction before continuing.
A 250 response MUST be sent to each successful BDAT data block within a A 250 response MUST be sent to each successful BDAT data block within
mail transaction. If a failure occurs after a BDAT command is received, a mail transaction. If a failure occurs after a BDAT command is
the receiver-SMTP MUST accept and discard the associated message data received, the receiver-SMTP MUST accept and discard the associated
before sending the appropriate 5XX or 4XX code. If a 5XX or 4XX code is message data before sending the appropriate 5XX or 4XX code. If a 5XX
received by the sender-SMTP in response to a BDAT chunk, the transaction or 4XX code is received by the sender-SMTP in response to a BDAT
should be considered failed and the sender-SMTP MUST NOT send any chunk, the transaction should be considered failed and the sender-SMTP
additional BDAT segments. If the receiver-SMTP has declared support for MUST NOT send any additional BDAT segments. If the receiver-SMTP has
command pipelining [PIPE], the receiver SMTP MUST be prepared to accept declared support for command pipelining [PIPE], the receiver SMTP MUST
and discard additional BDAT chunks already in the pipeline after the be prepared to accept and discard additional BDAT chunks already in
failed BDAT. the pipeline after the failed BDAT.
Note: An error on the receiver-SMTP such as disk full or imminent Note: An error on the receiver-SMTP such as disk full or imminent
shutdown can only be reported after the BDAT segment has been shutdown can only be reported after the BDAT segment has been
received. It is therefore important to choose a reasonable chunk received. It is therefore important to choose a reasonable chunk
size given the expected end-to-end bandwidth. size given the expected end-to-end bandwidth.
Note: Because the receiver-SMTP does not acknowledge the BDAT Note: Because the receiver-SMTP does not acknowledge the BDAT
command before the message data is sent, it is important to send command before the message data is sent, it is important to send
the BDAT only to systems that have declared their capability to the BDAT only to systems that have declared their capability to
accept BDAT commands. Illegally sending a BDAT command and accept BDAT commands. Illegally sending a BDAT command and
skipping to change at page 4, line 48 skipping to change at page 5, line 7
The local storage size of a message may not accurately reflect the The local storage size of a message may not accurately reflect the
actual size of the message sent due to local storage conventions. In actual size of the message sent due to local storage conventions. In
particular, text messages sent with the BDAT command MUST be sent 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 the canonical MIME format with lines delimited with a <CR><LF>. It
may not be possible to convert the entire message to the canonical may not be possible to convert the entire message to the canonical
format at once. CHUNKING provides a mechanism to convert the message format at once. CHUNKING provides a mechanism to convert the message
to canonical form, accurately count the bytes, and send the message a to canonical form, accurately count the bytes, and send the message a
single chunk at a time. single chunk at a time.
Note that correct byte counting is essential. If the sender- Note: Correct byte counting is essential. If the sender-SMTP
SMTP indicates a chunk-size larger than the actual chunk-size, indicates a chunk-size larger than the actual chunk-size, the
the receiver-SMTP will continue to wait for the remainder of the receiver-SMTP will continue to wait for the remainder of the
data or when using streaming, will read the subsequent command data or when using streaming, will read the subsequent command
as additional message data. In the case where a portion of the as additional message data. In the case where a portion of the
previous command was read as data, the parser will return a previous command was read as data, the parser will return a
syntax error when the incomplete command is read. syntax error when the incomplete command is read.
If the sender-SMTP indicates a chunk-size smaller than the If the sender-SMTP indicates a chunk-size smaller than the
actual chunk-size, the receiver-SMTP will interpret the actual chunk-size, the receiver-SMTP will interpret the
remainder of the message data as invalid commands. Note that remainder of the message data as invalid commands. Note that
the remainder of the message data may be binary and as such the remainder of the message data may be binary and as such
lexicographical parsers MUST be prepared to receive, process, lexicographical parsers MUST be prepared to receive, process,
skipping to change at page 6, line 33 skipping to change at page 6, line 33
compliance with [MIME]) with arbitrary octet content being sent. The compliance with [MIME]) with arbitrary octet content being sent. The
revised syntax of the value is as follows, using the ABNF notation of revised syntax of the value is as follows, using the ABNF notation of
[RFC822]: [RFC822]:
body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME" body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
6) No new verbs are defined for the BINARYMIME extension. 6) No new verbs are defined for the BINARYMIME extension.
7) This extension may be used for SMTP message submission. [Submit] 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 A sender-SMTP may request that a binary MIME message be sent without
transport encoding by sending a BODY parameter with a value of transport encoding by sending a BODY parameter with a value of
"BINARYMIME" with the MAIL command. When the receiver-SMTP accepts a "BINARYMIME" with the MAIL command. When the receiver-SMTP accepts a
MAIL command with the BINARYMIME body-value, it agrees to preserve all MAIL command with the BINARYMIME body-value, it agrees to preserve all
bits in each octet passed using the BDAT command. A receiver-SMTP MUST bits in each octet passed using the BDAT command. Once a receiver-SMTP
NOT advertise the BINARYMIME service extension unless it relays the supporting the BINARYMIME service extension accepts a message
MIME encoded message bodies octet-for-octet intact. 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 BINARYMIME cannot be used with the DATA command. If a DATA command is
issued after a MAIL command containing the body-value of "BINARYMIME", issued after a MAIL command containing the body-value of "BINARYMIME",
a 503 "Bad sequence of commands" response MUST be sent. The resulting a 503 "Bad sequence of commands" response MUST be sent. The resulting
state from this error condition is indeterminate and the transaction state from this error condition is indeterminate and the transaction
MUST be reset with the RSET command. MUST be reset with the RSET command.
It is important to note that when using BINARYMIME, it is especially It is especially important when using BINARYMIME to ensure that the
important to ensure that the MIME message itself is properly formed. MIME message itself is properly formed. In particular, it is
In particular, it is essential that text be canonically encoded with essential that text be canonically encoded with each line properly
each line properly terminated with <CR><LF>. Any transformation of terminated with <CR><LF>. Any transformation of text into non-
text into non-canonical MIME to observe local storage conventions MUST canonical MIME to observe local storage conventions MUST be reversed
be reversed before sending as BINARYMIME. Some line-oriented before sending as BINARYMIME. Some line-oriented shortcuts will break
shortcuts will break if used with BINARYMIME. A sender-SMTP MUST use if used with BINARYMIME. A sender-SMTP MUST use the canonical encoding
the canonical encoding for a given MIME content-type. In particular, for a given MIME content-type. In particular, text/* MUST be sent
text/* MUST be sent with <CR><LF> terminated lines. with <CR><LF> terminated lines.
Note: Although CR and LF do not represent SMTP command line Note: Although CR and LF do not necessarily represent ends of text
endings in BDAT chunks, and the 7-bit and 8-bit encodings are lines in BDAT chunks and use of the binary transfer encoding is
not required with BINARYMIME, the RFC 2781 prohibition against allowed, the RFC 2781 prohibition against using a UTF-16 charset
using a UTF-16 charset within the text top-level media type or within the text top-level media type remains.
remains.
The syntax of the extended MAIL command is identical to the MAIL The syntax of the extended MAIL command is identical to the MAIL
command in [RFC821], except that a BODY parameter MUST appear after command in [RFC821], except that a BODY=BINARYMIME parameter and value
the address. The complete syntax of this extended command is defined MUST be added. The complete syntax of this extended command is defined
in [ESMTP]. in [ESMTP].
If a receiver-SMTP does not indicate support the BINARYMIME message If a receiver-SMTP does not indicate support the BINARYMIME message
format then the sender-SMTP MUST NOT, under any circumstances, send format then the sender-SMTP MUST NOT, under any circumstances, send
binary data. binary data.
If the receiver-SMTP does not support BINARYMIME and the message to be 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 two sent is a MIME object with a binary encoding, a sender-SMTP has three
options with which to forward the message. First, it may implement a options with which to forward the message. First, if the receiver-SMTP
gateway transformation to convert the message into valid 7bit-encoded supports the 8bit-MIMEtransport extension [8bit] and the content is
MIME. Second, it may treat this as a permanent error and handle it in amenable to being encoded in 8bit, the sender-SMTP may implement a
the usual manner for delivery failures. The specifics of MIME gateway transformation to convert the message into valid 8bit-encoded
content-transfer-encodings, including transformations from Binary MIME MIME. Second, it may implement a gateway transformation to convert the
to 7bit MIME are not described by this RFC; the conversion is message into valid 7bit-encoded MIME. Third, it may treat this as a
nevertheless constrained in the following ways: 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 1. The conversion MUST cause no loss of information; MIME
encodings MUST be employed as needed to insure this is the case. transport encodings MUST be employed as needed to insure this is the
case.
2. The resulting message MUST be valid 7bit MIME. In particular, the 2. The resulting message MUST be valid 7bit or 8bit MIME. In
transformation may not result in nested Base-64 or Quoted-Printable particular, the transformation MUST NOT result in nested Base-64 or
content-transfer-encodings. Quoted-Printable content-transfer-encodings.
As of present there are no mechanisms for converting a binary MIME Note that at the time of this writing there are no mechanisms for
object into an 8-bit MIME object. Such a transformation will require converting a binary MIME object into an 8-bit MIME object. Such a
the specification of a new MIME content-transfer-encoding, the transformation will require the specification of a new MIME content-
standardization of which is discouraged by [MIME]. transfer-encoding.
If the MIME message contains a "Binary" content-transfer-encoding and If the MIME message contains a "Binary" content-transfer-encoding and
the BODY parameter does not indicate BINARYMIME, the message MUST be the BODY parameter does not indicate BINARYMIME, the message MUST be
accepted. The message SHOULD be returned to the sender with an accepted. The message SHOULD be returned to the sender with an
appropriate DSN. The message contents MAY be returned to the sender appropriate DSN. The message contents MAY be returned to the sender
if the offending content can be mangled into a legal DSN structure. if the offending content can be mangled into a legal DSN structure.
"Fixing" and forwarding the offending content is beyond the scope of "Fixing" and forwarding the offending content is beyond the scope of
this document. this document.
4. Examples 4. Examples
4.1 Simple Chunking 4.1 Simple Chunking
The following simple dialogue illustrates the use of the large message The following simple dialogue illustrates the use of the large message
extension to send a short psudo-RFC822 message to one recipient using extension to send a short pseudo-RFC822 message to one recipient using
the CHUNKING extension: the CHUNKING extension:
R: <wait for connection on TCP port 25> R: <wait for connection on TCP port 25>
S: <open connection to server> S: <open connection to server>
R: 220 cnri.reston.va.us SMTP service ready R: 220 cnri.reston.va.us SMTP service ready
S: EHLO ymir.claremont.edu S: EHLO ymir.claremont.edu
R: 250-cnri.reston.va.us says hello R: 250-cnri.reston.va.us says hello
R: 250 CHUNKING R: 250 CHUNKING
S: MAIL FROM:<Sam@Random.com> S: MAIL FROM:<Sam@Random.com>
R: 250 <Sam@Random.com> Sender ok R: 250 <Sam@Random.com> Sender ok
skipping to change at page 10, line 42 skipping to change at page 10, line 42
Inc., Network Management Associates, Inc., The Branch Office, November Inc., Network Management Associates, Inc., The Branch Office, November
1995. 1995.
[8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud, [8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M., Stefferud,
E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport" E., and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport"
RFC 1652, United Nations University, Innosoft International, Inc., RFC 1652, United Nations University, Innosoft International, Inc.,
Dover Beach Consulting, Inc., Network Management Associates, Inc., The Dover Beach Consulting, Inc., Network Management Associates, Inc., The
Branch Office, July 1994. Branch Office, July 1994.
[PIPE] Freed, N., "SMTP Service Extensions for Command Pipelining", [PIPE] Freed, N., "SMTP Service Extensions for Command Pipelining",
RFC 2197, Innosoft International, September 1997. RFC 2920, Innosoft, September 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard, March 1997.
7. Copyright Notice 7. Copyright Notice
"Copyright (C) The Internet Society (2000). All Rights Reserved. "Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind, distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
 End of changes. 25 change blocks. 
74 lines changed or deleted 97 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/