Handle an incapable next hop and a missing BODY declaration
06Capability 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.
Separate mismatch case under RFC 3030 §3: MIME says Content-Transfer-Encoding: binary while MAIL omitted BODY=BINARYMIME. The RFC says MUST accept and SHOULD return an appropriate DSN, not silently fix and forward. This is not permission for a sender to transmit binary to an incapable peer.
Source for this drawing: RFC 3030 · Read RFC section 3 ↗
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.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
If the receiver does not advertise BINARYMIME, the sender MUST NOT send binary data under any circumstances. CHUNKING alone is not enough.
- If the receiver does not advertise BINARYMIME, the sender MUST NOT send binary data under any circumstances. CHUNKING alone is not enough.
- For a binary-encoded MIME object at an incapable hop, the sender can gateway-convert to valid 7bit MIME, use a valid information-preserving 8bit conversion if the peer supports it and the content is amenable, or treat inability to forward as a permanent error. The RFC notes no binary-to-8bit conversion mechanism at publication.
- A conversion MUST lose no information and yield valid 7bit or 8bit MIME; it MUST NOT produce nested Base64 or quoted-printable encodings. The diagram chooses one valid 7bit body conversion, not a universal MIME converter.
- Separate specified mismatch case: if the MIME message contains binary Content-Transfer-Encoding but MAIL BODY did not indicate BINARYMIME, the message MUST be accepted and SHOULD be returned to the sender with an appropriate DSN (Delivery Status Notification). Contents MAY be included only if made legal for the DSN; fixing and forwarding is outside this RFC. Normal SMTP DSN constraints, including no DSN in response to a null reverse-path, still apply.
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 ↗