As per Relevance of the word transport, we have this rfc below:
Network Working Group G.
Request for Comments: 1830 Octel Network
Category: Experimental August 1995
SMTP Service
for Transmission of
and Binary MIME
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
1.
This memo defines two extensions to the SMTP service. The
service enables a SMTP client and server to negotiate the use of
alternate DATA command "BDAT" for efficiently sending large
messages. The second extension takes advantage of the BDAT
to permit the negotiated sending of unencoded binary data
2.
The MIME extensions to the Internet message protocol provides for
transmission of many kinds of data which were previously
in Internet mail. Anticipating the need to more
transport the new media made possible with MIME, the SMTP
has been extended to provide transport for new message types.
1426 defines one such extension for the transmission of unencoded 8
bit MIME messages [8BIT]. This service extension permits
receiver SMTP to declare support for 8 bit body parts and the
to request 8 bit transmission of a 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 need to eliminate the requirement that
message be scanned for "CR LF . CR LF" sequences upon sending
receiving to detect the end of message
Independent of the need to send large messages, Internet mail
increasingly multi-media 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 which support
message processing
Vaudreuil Experimental [Page 1]
RFC 1830 Binary and Large Message Transport August 1995
This memo uses the mechanism defined in [ESMTP] to define
extensions to the SMTP service whereby a client ("sender-SMTP")
declare support for the message chunking transmission mode using
BDAT command and support for the sending of Binary messages
3. Framework for the Large Message
The following service extension is hereby defined
1) The name of the data chunking service extension
"CHUNKING".
2) The EHLO keyword value associated with this extension
"CHUNKING".
3) A new SMTP verb is defined "BDAT" as an alternative
the "DATA" command of [RFC821]. The BDAT verb takes
arguments. The first argument indicates the length of
binary data packet. The second optional argument
that the data packet is the last
bdat-cmd ::= "BDAT" SP chunk-
[ SP end-marker ] CR
chunk-size ::= 1*
end-marker ::= "LAST
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 client SMTP wishes to submit (using the MAIL command) a
message using the CHUNKING extension, it first issues the
command to the server SMTP. If the server SMTP responds with
250 to the EHLO command, and the response includes the EHLO
value CHUNKING, then the server SMTP is indicating that it
the BDAT command and will accept the sending of messages in chunks
After all MAIL FROM and RCPT TO responses are collected
processed, the message is sent using a series of BDAT commands.
BDAT command takes one argument, the exact length of the data
in octets. The message data is sent immediately after the
command. Once the receiver-SMTP receives the specified number
octets, it will return a 250 reply code
The LAST parameter on the BDAT command indicates that this is
last chunk of message data to be sent. Any BDAT command sent
the BDAT LAST is illegal and must be replied to with a 503 "
Vaudreuil Experimental [Page 2]
RFC 1830 Binary and Large Message Transport August 1995
sequence of commands" reply code. The state resulting from this
is indeterminate. A RSET command must be sent to clear
transaction before continuing
A 250 response should be sent to each BDAT data block. If a 5XX
is sent in response to a BDAT chunk the message should be
failed and, the sender SMTP must not send any additional
segments. If using the ESMTP pipelining extensions [PIPE],
sender SMTP must complete the sending of the current segment and
send any more BDATs. When streaming, the receiver SMTP must
and discard additional BDAT chunks after the failed BDAT.
receiving a 5XX error in response to a BDAT command, the
state is indeterminate. A RSET command must be issued to clear
transaction before additional commands may be sent
Note that an error on the receiver SMTP such as disk full
imminent shutdown can only be reported after the BDAT segment
been sent. It is therefore important to choose a reasonable
size given the expected end to end bandwidth
The RSET command when issued during after the first BDAT and
the BDAT LAST clears all segments sent during that transaction
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
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 that correct byte counting is essential. If too many
are indicated by the sender SMTP, the receiver SMTP will
to wait for the remainder of the data or will read the
command as additional message data. In the case where a
of the previous command was read as data, the parser will return
syntax error when the incomplete command is read
Vaudreuil Experimental [Page 3]
RFC 1830 Binary and Large Message Transport August 1995
If too few bytes are indicated by the sender SMTP, the
SMTP will interpret the remainder of the message data as
commands. Note that the remainder of the message data may
binary and as such lexigraphical parsers must be prepared
receive, process, and reject lines of arbitrary octets
4. 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
the "CHUNKING" service extension
4) No parameter is used with the BINARYMIME keyword
5) One additional parameter to the BODY keyword
[8BIT] for the MAIL FROM command is defined, "BINARYMIME".
The value "BINARYMIME" associated with this
indicates that this message is a Binary MIME message (
strict compliance with [MIME]) with arbitrary octet
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
A sender SMTP may request that a binary MIME message be sent
transport encoding by sending a BINARYMIME parameter with the
FROM command. When the receiver SMTP accepts a MAIL FROM
with the BINARYMIME body type requested, it agrees to preserve
bits in each octet passed using the BDAT command
BINARYMIME cannot be used with the DATA command. If a DATA
is issued after a MAIL FROM command containing the body-value
"BINARYMIME", a 501 response should be sent. The resulting
from this error condition is indeterminate and the transaction
be reset with the RSET command
It is important to note that when using BINARYMIME, it
especially important to ensure that the MIME message itself
properly formed. In particular, it is essential that text
canonically encoded with each line properly terminated with
Vaudreuil Experimental [Page 4]
RFC 1830 Binary and Large Message Transport August 1995
. Any transformation of text into non-canonical MIME
observe local storage conventions must be reversed before
as BINARYMIME. The usual line-oriented shortcuts will break
used with BINARYMIME
The syntax of the extended MAIL command is identical to the
command in [RFC821], except that a BODY parameter must appear
the address. The complete syntax of this extended command is
in [ESMTP]. The ESMTP-keyword is BODY and the syntax for ESMTP-
is given by the syntax for body-value in [ESMTP].
If a receiver SMTP does not support the BINARYMIME message
(either by not responding with code 250 to the EHLO command, or
rejecting the BINARYMIME parameter to the MAIL FROM command, then
client SMTP must not, under any circumstances, send binary data
the DATA or BDAT commands
If the receiver-SMTP does not support BINARYMIME and the
content is a MIME object with a binary encoding, a client SMTP
two options in this case: first, it may implement a
transformation to convert the message into valid 7bit encoded MIME
or second, it may treat this as a permanent error and handle it
the usual manner for delivery failures. The specifics of
transformation from Binary MIME to 7bit MIME are not described
this RFC; the conversion is nevertheless constrained in the
ways
o The conversion must cause no loss of information;
transport encodings must be employed as needed to insure
is the case
o The resulting message must be valid 7bit MIME
As of present there are no mechanisms for converting a binary
object into a 8 bit-MIME object. Such a transformation will
the specification of a new MIME content-transfer-encoding,
standardization of which is discouraged by [MIME].
Vaudreuil Experimental [Page 5]
RFC 1830 Binary and Large Message Transport August 1995
5.
5.1 Simple
The following simple dialogue illustrates the use of the
message extension to send a short psudo-RFC822 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 69
S: To: Susan@random.com
S: From: Sam@random.com
S: Subject: This is a bodyless test message
R: 250 Message OK, 69 octets
S:
R: 221
5.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 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-
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
Vaudreuil Experimental [Page 6]
RFC 1830 Binary and Large Message Transport August 1995
S: (First 10000 octets of canonical MIME message data
S: BDAT 324
S: (Remaining 324 octets of canonical MIME message data
R: 250 100000 bytes
R: 250 Message OK, 100324 octets
S:
R: 221
6. Security
This RFC does not discuss security issues and is not believed
raise any security issues not already endemic in electronic mail
present in fully conforming implementations of [RFC821], or
made possible by [MIME].
7.
This document is the result of numerous discussions in the IETF
Extensions Working Group and in particular due to the
advocacy of "chunking" by Neil Katin
8.
[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
821, USC/Information Sciences Institute, August 1982.
[RFC822] Crocker, D., "Standard for the Format of ARPA
Text Messages", STD 11, RFC 822, UDEL, August 1982.
[MIME] Borenstein, N., and N. Freed, "Multipurpose Internet
Extensions", RFC 1521, Bellcore, Innosoft, June 1992.
[ESMTP] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
Stefferud, E., and D. Crocker, "SMTP Service Extensions"
1425, United Nations University, Innosoft International
Inc., Dover Beach Consulting, Inc., Network
Associates, Inc., The Branch Office, February 1993.
[8BIT] Klensin, J., WG Chair, Freed, N., Editor, Rose, M.,
Stefferud, E., and D. Crocker, "SMTP Service Extension
8bit-MIMEtransport" RFC 1426, United Nations University
Innosoft International, Inc., Dover Beach Consulting, Inc.,
Network Management Associates, Inc., The Branch Office
February 1993.
[PIPE] Freed, N., "SMTP Service Extensions for
Pipelining", Innosoft International, Work in Progress
Vaudreuil Experimental [Page 7]
RFC 1830 Binary and Large Message Transport August 1995
9. Author's
Gregory M.
Octel Network
17060 Dallas
Suite 214
Dallas, TX 75248-1905
Voice/Fax: 214-733-2722
EMail: Greg.Vaudreuil@Octel.
Vaudreuil Experimental [Page 8]
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
