Separate body support from other capabilities
058BITMIME is a body-transport extension. It does not by itself authorize internationalized envelope addresses, raw UTF-8 headers or unrestricted binary bodies.
A readable body preserved through transport is not authenticated, encrypted or proven safe. 7-bit MIME encodings can carry the same information, so the high-bit option is not a malware-safety gate.
Source for this drawing: RFC 6152 · Read RFC section 5 ↗
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.
A negotiated representation is not an identity or safety check.
- RFC 5321 does not let 8BITMIME authorize non-ASCII envelope commands or unrestricted 8-bit material; high-bit content still needs appropriate MIME formatting and transfer encoding.
- SMTPUTF8 under RFC 6531 and UTF-8 header syntax under RFC 6532 are separate related mechanisms. SMTPUTF8 servers must advertise 8BITMIME, but 8BITMIME alone does not imply SMTPUTF8.
- RFC 6152 adds no message confidentiality or sender-authentication mechanism. MIME transport encodings do not make content safe or prevent malware.
The stopped examples assume only 8BITMIME is advertised. Raw UTF-8 headers and addresses would need separate SMTPUTF8 support; encoded ASCII header text is a different technique. BINARYMIME/CHUNKING under RFC 3030 are also distinct mechanisms, outside this guide.
Read the RFC section ↗