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]
Normative requirements
Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 24 must, 1 should, 2 may.
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.