SMTP Service Extensions for Transmission of Large and Binary MIME Messages
RFC 1830
Document | Type |
RFC - Experimental
(August 1995; No errata)
Obsoleted by RFC 3030
|
|
---|---|---|---|
Author | Gregory Vaudreuil | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1830 (Experimental) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group G. Vaudreuil Request for Comments: 1830 Octel Network Services Category: Experimental August 1995 SMTP Service Extensions for Transmission of Large and Binary MIME Messages Status of this Memo This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. 1. 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. 2. 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 [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 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. 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. Vaudreuil Experimental [Page 1] RFC 1830 Binary and Large Message Transport August 1995 This memo uses the mechanism defined in [ESMTP] 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. 3. 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 [RFC821]. 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. Any BDAT command sent after the BDAT LAST is illegal and must be replied to with a 503 "Bad Vaudreuil Experimental [Page 2] RFC 1830 Binary and Large Message Transport August 1995 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 should be sent to each BDAT data block. If a 5XX codeShow full document text