Relay through a server without 8BITMIME
04A relay that accepted an 8-bit body still has to preserve its information on the next hop. A different server may not advertise the same capability.
If the client does not perform a valid lossless conversion, it may treat the 8-bit barrier as a permanent delivery error. No specific SMTP error code for this choice is invented.
Source for this drawing: RFC 6152 · 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.
Convert without information loss or handle a permanent delivery failure.
- If EHLO fails or the successful reply omits 8BITMIME, the client must not transfer content octets outside 00–7F on that connection.
- The client may perform a gateway transformation into valid 7-bit MIME with no information loss, using MIME transport encodings as needed, or treat the barrier as a permanent delivery error.
- RFC 6152 does not specify the conversion algorithm. Clearing high bits is not a valid downgrade. An unextended connection uses ordinary MAIL without this extension’s BODY parameter.
One tiny single-part UTF-8 message is converted to Base 64 with its MIME Content-Transfer-Encoding changed accordingly. That is one illustrative lossless gateway choice; arbitrary multipart/header/security transformations are not implemented by this guide.
Read the RFC section ↗