Visual RFC.
ALL RFCs / RFC 6152
Read the RFC ↗
RFC 6152 / SMTP 8-BIT MIME TRANSPORT

Separate body support from other capabilities

05

8BITMIME is a body-transport extension. It does not by itself authorize internationalized envelope addresses, raw UTF-8 headers or unrestricted binary bodies.

RFC 6152 · § 5EXAMPLE
4 / 4
Separate body support from other capabilitiesFour separate scope comparisons assume only8BITMIME support. ASCII MAIL and headers can surround a chosen UTF8 MIME body. Raw UTF8 Subject text requires separate internationalized-header and SMTPUTF8 support. Internationalized envelope address café at example com and BODY BINARY are independent unsupported requests stopped at the sender;8BITMIME does not grant either. Finally preserving a body is distinct from authentication, encryption or malware safety;7bit MIME can carry the same information.Only 8BITMIME is advertised in these examplesPreserved and readable bodyinfer trusted / encrypted / safeNo sender authentication or encryption addedMIME encodings do not make content safe7-bit MIME can carry the same information
04
Check security separately.

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 ↗

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

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

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 ↗

All chapters in RFC 6152

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 ↗