SMTP Service Extensions for Transmission of Large and Binary MIME Messages
obsoletes
- rfc-1830 — SMTP Service Extensions for Transmission of Large and Binary MIME Messages
Extracted elements (27)
BINARYMIME was designed to avoid the overhead of base64 and quoted-printable encoding of binary objects sent over SMTP between hosts that support binary message processing, enabling more efficient transmission of multimedia content.
CHUNKING provides a mechanism to convert messages to canonical form, accurately count bytes, and send the message one chunk at a time, addressing the mismatch between local storage conventions and the canonical on-wire MIME format.
CHUNKING was designed to eliminate the requirement that the message be scanned for 'CR LF . CR LF' sequences on both send and receive for end-of-message detection, improving performance for large messages.
RFC 1830 was classified experimental due to questions about the robustness of Binary Content-Transfer-Encoding in MIME implementations. As MIME matured and binary encoding deployments increased, those concerns were resolved, enabling promotion to standards track in RFC 3030.
The BDAT chunk-size argument is required to be exact because the receiver does not acknowledge the BDAT command before data is sent. An incorrect byte count causes the receiver to either wait for more data (count too large) or misparse subsequent commands as message data (count too small).
BINARYMIME can only be used with the CHUNKING extension; it cannot be used standalone. Both CHUNKING and BINARYMIME must be advertised in the EHLO response before BINARYMIME transmission can be attempted.
DATA and BDAT may be used in the same session across different transactions, but must never be mixed within a single transaction. There is no prohibition on alternating between DATA and BDAT transactions in one session.
Sending BDAT to a non-CHUNKING system is illegal and dangerous: the server will parse the binary message data as ESMTP command lines, potentially causing undefined behavior. BDAT must only be sent to servers that have advertised CHUNKING in their EHLO response.
When the receiver does not support BINARYMIME, a sender has three options: (1) transcode to 8bit-MIME if the receiver supports 8BITMIME, (2) transcode to 7bit-MIME, or (3) treat it as a permanent delivery failure. Transcoding must not lose information.
A 250 response MUST be sent to each successful BDAT data block. If a failure occurs, the receiver-SMTP MUST accept and discard the associated message data before sending the 5XX or 4XX error code.
After a failed BDAT command, a RSET command MUST be issued to clear the transaction before additional commands may be sent. The RSET clears all segments sent during that transaction and resets the session.
Any BDAT command sent after BDAT LAST is illegal and MUST be replied to with a 503 'Bad sequence of commands' reply code. The resulting state is indeterminate and a RSET MUST be sent to clear the transaction.
BINARYMIME cannot be used with the DATA command. If a DATA command is issued after a MAIL command with BODY=BINARYMIME, a 503 'Bad sequence of commands' response MUST be sent and the transaction MUST be reset.
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 'Bad sequence of commands' MUST be issued.
If a 5XX or 4XX code is received in response to a BDAT chunk, the sender-SMTP MUST NOT send any additional BDAT segments. With pipelining, the receiver MUST be prepared to accept and discard additional BDAT chunks already in the pipeline.
If a MIME message contains a 'Binary' content-transfer-encoding and the BODY parameter does not indicate BINARYMIME, the message MUST be accepted and SHOULD be returned to the sender with an appropriate DSN.
If a receiver-SMTP does not indicate support for BINARYMIME, the sender-SMTP MUST NOT under any circumstances send binary data. A sender-SMTP MUST use canonical encoding for a given MIME content-type; text/* MUST be sent with <CR><LF> terminated lines.
Servers that offer the BDAT extension MUST continue to support the regular SMTP DATA command. Clients may use DATA to transfer appropriately encoded messages to CHUNKING-capable servers.
Text messages sent with BDAT MUST be sent in canonical MIME format with lines delimited with <CR><LF>. Any transformation of text into non-canonical MIME to observe local storage conventions MUST be reversed before sending as BINARYMIME.
When a receiver-SMTP accepts a MAIL command with BODY=BINARYMIME, it MUST deliver or relay the message in such a way as to preserve all bits in each octet passed using the BDAT command.
When converting binary MIME to 7-bit or 8-bit MIME for a non-BINARYMIME receiver, the conversion MUST cause no loss of information and the resulting message MUST be valid 7-bit or 8-bit MIME. The transformation MUST NOT result in nested Base-64 or Quoted-Printable content-transfer-encodings.
The BINARYMIME service extension is defined with EHLO keyword 'BINARYMIME'. It can only be used in conjunction with the CHUNKING extension and adds a BODY=BINARYMIME parameter value for the MAIL command.
The CHUNKING service extension is defined with EHLO keyword 'CHUNKING'. It enables the BDAT command as an alternative to DATA for sending messages in chunks, usable for 7-bit, 8BITMIME, or BINARYMIME messages.
The CHUNKING and BINARYMIME extensions are not known to present any additional security issues beyond those already endemic to electronic mail in fully conforming implementations of RFC 821 or made possible by MIME.
After any BDAT failure, the transaction state becomes indeterminate. The required recovery transition is: indeterminate state → RSET command → clean session state. The RSET clears all chunks sent in the current transaction. Only after RSET can new MAIL/RCPT/BDAT sequences begin.
The BDAT command takes a required chunk-size (octet count) and an optional LAST marker. Syntax: `bdat-cmd ::= "BDAT" SP chunk-size [ SP end-marker ] CR LF` where `chunk-size ::= 1*DIGIT` and `end-marker ::= "LAST"`.
The BODY parameter for the MAIL command is extended with a new value. Revised ABNF: `body-value ::= "7BIT" / "8BITMIME" / "BINARYMIME"`. The BINARYMIME keyword and value add up to 16 characters to the MAIL FROM command line.