SMTP Service Extensions for Transmission of Large and Binary MIME Messages
draft-ietf-mailext-smtp-binary-06
The information below is for an old version of the document that is already published as an RFC.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 1830.
|
|
---|---|---|---|
Author | Gregory Vaudreuil | ||
Last updated | 2013-03-02 (Latest revision 1995-03-23) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | WG state | (None) | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 1830 (Experimental) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-mailext-smtp-binary-06
Network Working Group Greg Vaudreuil
Internet Draft Octel Network Services
Expires: 2/20/95 March 22, 1995
SMTP Service Extensions
for Transmission of Large
and Binary MIME Messages
<draft-mailext-smtp-binary-06.txt>
Changes from Previous Draft
1) Numerous typo's corrected.
1.Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet Drafts as reference material
or to cite them other than as a "work in progress".
2.Abstract
This memo defines two extensions to the SMTP service. The first
service. enables a SMTP client and server to negotiate the use of
an alternate DATA command "BDAT" for efficiently sending large
MIME messages. The second extension takes advantage of the BDAT
command to permit the negotiated sending of unencoded binary
data.
3.Introduction
The MIME extensions to the Internet message protocol provides for
the transmission of many kinds of data which were previously
unsupported in Internet mail. Anticipating the need to more
efficiently transport the new media made possible with MIME, the
SMTP protocol has been extended to provide transport for new
message types. RFC 1426 defines one such extension for the
transmission of unencoded 8 bit MIME messages. 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 need 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.
Internet Draft Binary and Large March 22, 1995
Message Transport
Independent of the need to send large messages, Internet mail is
increasingly multi-media 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 which support
binary message processing.
This memo uses the mechanism defined in [4] to define two
extensions to the SMTP service whereby a client ("sender-SMTP")
may declare support for the message chunking transmission mode
using the BDAT command and support for the sending of Binary
messages.
4.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 is defined "BDAT" as an alternative to
the "DATA" command of [1]. The BDAT verb takes two
arguments. The first argument indicates the length of the
binary data packet. The second optional argument indicates
that the data packet is the last.
bdat-cmd ::= "BDAT" SP chunk-size
[ SP end-marker ] CR LF
chunk-size ::= 1*DIGIT
end-marker ::= "LAST"
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 client SMTP wishes to submit (using the MAIL command) a
large message using the CHUNKING extension, it first issues the
EHLO command to the server SMTP. If the server SMTP responds
with code 250 to the EHLO command, and the response includes the
EHLO keyword value CHUNKING, then the server SMTP is indicating
that it supports the BDAT command and will accept the sending of
messages in chunks.
After all MAIL FROM and RCPT TO responses are collected and
processed, the message is sent using a series of BDAT commands.
The BDAT command takes one argument, the exact length of the data
segment in octets. The message data is sent immediately after
the BDAT command. Once the receiver-SMTP receives the specified
number of octets, it will return a 250 reply code.
The LAST parameter on the BDAT command indicates that this is the
last chunk of message data to be sent.
Vaudreuil Expires 6/1/95 [Page 2]
Internet Draft Binary and Large March 22, 1995
Message Transport
A 250 response should be sent to each BDAT data block. If a 5XX
code is sent in response to a BDAT chunk the message should be
considered failed and, the sender SMTP must not send any
additional BDAT segments. If streaming, the sender SMTP must
complete the sending of the current segment and not send any more
BDATs. When streaming, the receiver SMTP must accept and discard
additional BDAT chunks after the failed BDAT. After receiving a
5XX error in response to a BDAT command, the resulting state is
indeterminate. A RSET command must be issued to clear the
transaction before additional commands may be sent.
Note that an error on the receiver SMTP such as disk full or
imminent shutdown can only be reported after the BDAT
segment has been sent. It is therefore important to choose
a reasonable chunk size given the expected end to end
bandwidth.
The RSET command when issued during afer 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 ``
The state resulting from this error is indeterminate. A RSET
command must be sent to 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 that correct byte counting is essential. If too many bytes are
indicated by the sender SMTP, the receiver SMTP will continue to wait
for the remainder of the data or 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 too few bytes are indicated by the sender SMTP, 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 lexigraphical parsers
must be prepared to receive, process, and reject lines of
arbitrary octets.
Vaudreuil Expires 6/1/95 [Page 3]
Internet Draft Binary and Large March 22, 1995
Message Transport
5.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) One additional parameter to the BODY keyword defined [5]
for the MAIL FROM command is defined, "BINARYMIME". The
value "BINARYMIME" associated with this parameter indicates
that this message is a Binary MIME message (in strict
compliance with [3]) with arbitrary octet content being
sent. The revised syntax of the value is as follows, using
the ABNF notation of [2]:
body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"
6) No new verbs are defined for the BINARYMIME extension.
A sender SMTP may request that a binary MIME message be sent
without transport encoding by sending a BINARYMIME parameter with
the MAIL FROM command. When the receiver SMTP accepts a MAIL
FROM command with the BINARYMIME body type requested, it agrees
to preserve all bits in each octet passed using the BDAT command.
BINARYMIME cannot be used with the DATA command. If a DATA
command is issued after a MAIL FROM command containing the body-
value of BINARYMIME
resulting state from this error condition is indeterminate and
the transaction should be reset with the RSET command.
It is important to note that when using BINARYMIME, it is
especially important 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. The usual line-
oriented shortcuts will break if used with BINARYMIME.
The syntax of the extended MAIL command is identical to the MAIL
command in [1], except that a BODY parameter must appear after
the address. The complete syntax of this extended command is
defined in [4]. The ESMTP-keyword is BODY and the syntax for
ESMTP-value is given by the syntax for body-value in [4].
Vaudreuil Expires 6/1/95 [Page 4]
Internet Draft Binary and Large March 22, 1995
Message Transport
If a receiver SMTP does not support the BINARYMIME message format
(either by not responding with code 250 to the EHLO command, or
by rejecting the BINARYMIME parameter to the MAIL FROM command,
then the client SMTP must not, under any circumstances, send
binary data using the DATA or BDAT commands.
If the receiver-SMTP does not support BINARYMIME and the message
content is a MIME object with a binary encoding, a client SMTP
has two options in this case: first, it may implement a gateway
transformation to convert the message into valid 7bit encoded
MIME, or second, it may treat this as a permanent error and
handle it in the usual manner for delivery failures. The
specifics of the transformation from Binary MIME to 7bit MIME are
not described by this RFC; the conversion is nevertheless
constrained in the following ways:
The conversion must cause no loss of information; MIME
transport encodings must be employed as needed to insure this
is the case.
The resulting message must be valid 7bit MIME.
As of present there are no mechanisms for converting a binary
MIME object into a 8 bit-MIME object. Such a transformation will
require the specification of a new MIME content-transfer-
encoding, the standardization of which is discouraged by [3].
6.Examples
6.1. Simple Chunking
The following simple dialogue illustrates the use of the large
message extension to send a short psudo-RFC822 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 69 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, 69 octets received
S: QUIT
R: 221 Goodbye
Vaudreuil Expires 6/1/95 [Page 5]
Internet Draft Binary and Large March 22, 1995
Message Transport
6.2. Streaming Binarymime
The following dialogue illustrates the use of the large message
extension to send a BINARYMIME object to two recipients using the
CHUNKING and STREAMING extensions:
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-STREAMING
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)
S: BDAT 324 LAST
S: (Remaining 324 octets of canonical MIME message data)
R: 250 100000 bytes received
R: 250 Message OK, 100324 octets received
S: QUIT
R: 221 Goodbye
Vaudreuil Expires 6/1/95 [Page 6]
Internet Draft Binary and Large March 22, 1995
Message Transport
7.Security Considerations
This RFC does not discuss security issues and is not believed to
raise any security issues not already endemic in electronic mail
and present in fully conforming implementations of [1], or
otherwise made possible by [3].
8.Acknowledgments
This document is the result of numerous discussions in the IETF
SMTP Extensions Working Group and in particular due to the
continued advocacy of "chunking" by Neil Katin.
9.References
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[2] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
Extensions", RFC 1341, Bellcore, Innosoft, June 1992.
[4] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
Stefferud, E., and D. Crocker, "SMTP Service Extensions" RFC
1425,
[5] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
Stefferud, E., and D. Crocker, "SMTP Service Extension for
8bit-MIMEtransport" RFC 1426, United Nations University,
Innosoft International, Inc., Dover Beach Consulting, Inc.,
Network Management Associates, Inc., The Branch Office,
February 1993.
10. Author's Address
Gregory M. Vaudreuil
Octel Network Services
17060 Dallas Parkway
Suite 214
Dallas, TX 75248-1905
Greg.Vaudreuil@ons.octel.com
Vaudreuil Expires 6/1/95 [Page 7]