Visual RFC.
ALL RFCs / RFC 3030
Read the RFC ↗
RFC 3030 / SMTP CHUNKS AND BINARY MIME

Request binary transport and preserve every bit

05

BINARYMIME 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.

RFC 3030 · § 3EXAMPLE
4 / 4
Request binary transport and preserve every bitSeparate DATA-after-binary-MAIL case gets 503 and requires RSET.BINARYMIME: preserve body bits; keep valid MIMESenderReceiverMAIL BODY=BINARYMIME already acceptedDATA503 bad sequenceMUST reset transaction with RSETBinary transport is not encryption, authentication or relaxed header syntax
04
Reject DATA for a binary transaction

Separate error comparison after accepted MAIL BODY=BINARYMIME: DATA receives 503. The sender must reset with RSET; dot framing is not a substitute for binary BDAT transport.

Source for this drawing: RFC 3030 · Read RFC section 3 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

The peer must advertise BINARYMIME and CHUNKING. To request binary transmission, MAIL FROM MUST include BODY=BINARYMIME; it adds a body-value to the MAIL parameter, not a new transfer command.

  • The peer must advertise BINARYMIME and CHUNKING. To request binary transmission, MAIL FROM MUST include BODY=BINARYMIME; it adds a body-value to the MAIL parameter, not a new transfer command.
  • Once binary content is accepted, the receiver MUST deliver or relay it while preserving all bits in every octet. The pictured 00 0A FF bytes are only an arbitrary binary body excerpt, not message headers.
  • Canonical rules for each MIME content type still apply: text/* MUST use CRLF line endings, and local-storage transformations MUST be reversed before binary transmission. BINARYMIME does not permit malformed MIME or arbitrary non-ASCII SMTP headers.
  • BINARYMIME cannot use DATA. After MAIL BODY=BINARYMIME, DATA MUST receive 503 and the transaction MUST be reset with RSET. BDAT is required for binary transport; neither extension supplies encryption or peer authentication.
DETAILS

Fictional example.com mail peers. Counts and byte excerpts are illustrative, not a full MIME message or a deployment configuration. Separate comparisons reset state. This companion is not an SMTP parser or implementation.

Read the RFC section ↗

All chapters in RFC 3030

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗