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