SMTP Service Extensions for Transmission of Large and Binary MIME Messages
This memo defines two extensions to the SMTP (Simple Mail Transfer Protocol) service. [STANDARDS-TRACK]
What it is
CHUNKING and BDAT: transferring a message as sized chunks instead of as dot-terminated text.
What it solves
The dot-stuffing convention means scanning and rewriting every line of every message, which is pure overhead on large messages.
What it means to operate
Faster for large messages and worth enabling where both ends support it. Be aware that some filtering appliances handle BDAT badly, so it is a reasonable thing to suspect when large messages fail and small ones do not.
Bounce classifier turns an SMTP response into the action it calls for. Open bounce classifier
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from.
2 Framework for the Large Message Extensions
- MUST5) Servers that offer the BDAT extension MUST continue to support the regular SMTP DATA command.
- MAYThe last BDAT command MAY have a byte-count of zero indicating there is no additional data to be sent.
- MUSTAny BDAT command sent after the BDAT LAST is illegal and MUST be replied to with a 503 "Bad sequence of commands" reply code.
- MUSTA RSET command MUST be sent to clear the transaction before continuing.
- MUSTA 250 response MUST be sent to each successful BDAT data block within a mail transaction.
- MUSTIf a failure occurs after a BDAT command is received, the receiver-SMTP MUST accept and discard the associated message data before sending the appropriate 5XX or 4XX code.
- MUST NOTIf a 5XX or 4XX code is received by the sender-SMTP in response to a BDAT chunk, the transaction should be considered failed and the sender- SMTP MUST NOT send any additional BDAT segments.
- MUSTIf the receiver- SMTP has declared support for command pipelining [PIPE], the receiver SMTP MUST be prepared to accept and discard additional BDAT chunks already in the pipeline after the failed BDAT.
- MUSTA RSET command MUST be issued to clear the transaction before additional commands may be sent.
- MUSTIf a DATA statement is issued after a BDAT for the current transaction, a 503 "Bad sequence of commands" MUST be issued.
- MUSTA RSET command MUST be sent to
- MUSTIn particular, text messages sent with the BDAT command MUST be sent in the canonical MIME format with lines delimited with a <CR><LF>.
- MUSTNote that the remainder of the message data may be binary and as such lexicographical parsers MUST be prepared to receive, process, and reject lines of arbitrary octets.
3 Framework for the Binary Service Extension
- MUSTOnce a receiver-SMTP supporting the BINARYMIME service extension accepts a message containing binary material, the receiver-SMTP MUST deliver or relay the message in such a way as to preserve all bits in each octet.
- MUSTIf a DATA command is issued after a MAIL command containing the body-value of "BINARYMIME", a 503 "Bad sequence of commands" response MUST be sent.
- MUSTThe resulting state from this error condition is indeterminate and the transaction MUST be reset with the RSET command.
- MUSTAny transformation of text into non- canonical MIME to observe local storage conventions MUST be reversed before sending as BINARYMIME.
- MUSTA sender-SMTP MUST use the canonical encoding for a given MIME content-type.
- MUSTIn particular, text/* MUST be sent with <CR><LF> terminated lines.
- MUSTThe syntax of the extended MAIL command is identical to the MAIL command in [RFC821], except that a BODY=BINARYMIME parameter and value MUST be added.
- MUST NOTIf a receiver-SMTP does not indicate support the BINARYMIME message format then the sender-SMTP MUST NOT, under any circumstances, send binary data.
- MUSTThe conversion MUST cause no loss of information; MIME transport encodings MUST be employed as needed to insure this is the case.
- MUSTThe resulting message MUST be valid 7bit or 8bit MIME.
- MUST NOTIn particular, the transformation MUST NOT result in nested Base- 64 or Quoted-Printable content-transfer-encodings.
- MUSTIf the MIME message contains a "Binary" content-transfer-encoding and the BODY parameter does not indicate BINARYMIME, the message MUST be accepted.
- SHOULDThe message SHOULD be returned to the sender with an appropriate DSN.
- MAYThe message contents MAY be returned to the sender if the offending content can be mangled into a legal DSN structure.