RFC 3030 / START HERE
SMTP CHUNKING and BINARYMIME, before the details
SMTP means Simple Mail Transfer Protocol; MIME means Multipurpose Internet Mail Extensions. CHUNKING and BINARYMIME are the two service extensions defined here.
A sender can split a MIME message into BDAT chunks, each declaring exactly how many octets follow. An octet is eight bits. LAST marks the final chunk. Separately negotiated BINARYMIME lets capable mail systems preserve arbitrary binary body bytes.
The idea in one picture
Count canonical bytes
Send BDAT chunks
LAST and reply
A simplified picture of the idea; the chapters explain the actual mechanisms.
Why it exists
Ordinary SMTP DATA uses a dot-based ending and requires suitable content encoding. These extensions avoid scanning for that ending and can avoid binary encoding overhead on capable hops. RFC 3030 obsoletes the experimental RFC 1830; it extends SMTP rather than replacing it.
A familiar example
A mail relay counts canonical transmitted bytes, sends chunks, and waits for their replies. A failed chunk requires draining and resetting; an incapable next hop needs a valid conversion or a delivery failure. Chunk acknowledgements do not prove the recipient read the message, and binary transport is not encryption.
Helpful background
You can start here without reading another RFC. If these ideas are unfamiliar, these short introductions may help.
What you’ll learn next
Begin with chapter one, or choose a topic.
- Negotiate chunking before sending chunksSMTP means Simple Mail Transfer Protocol; MIME means Multipurpose Internet Mail Extensions. CHUNKING advertises an exact-length alternative to SMTP’s DATA transfer. BINARYMIME is a separate capability.→
- Count transmitted octets, not local file charactersAn octet is eight bits. BDAT counts only the following data segment: the command line and its CRLF are outside the declared count. A chunk can split a message at any octet boundary.→
- Finish a transaction with LAST and respect its boundariesEach successful chunk receives a 250 reply. LAST identifies the final chunk; it is a BDAT parameter, not a separate command or a count of the whole message.→
- Drain failed chunks before resettingLength framing still matters after an error. The receiver consumes and discards the failed chunk’s declared data before replying, so those bytes are not mistaken for commands.→
- Request binary transport and preserve every bitBINARYMIME transports MIME data containing arbitrary octets without converting it into Base64 or quoted-printable for this hop. It still requires a well-formed MIME message.→
- Handle an incapable next hop and a missing BODY declarationCapability checks apply again when relaying. If the next receiver lacks BINARYMIME, raw binary cannot simply be sent onward. MIME headers and the envelope BODY declaration also have to agree.→
This introduction explains RFC 3030 (2000). Read the original RFC ↗