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

Keep DATA dots and line limits

03

8BITMIME retains SMTP line structure and dot transparency. It is not unrestricted binary transport.

DIAGRAMRead RFC section 3 ↗
RFC 6152 · § 3EXAMPLE
4 / 4
Keep DATA dots and line limitsA body-only counting fragment café CRLF dot CRLF has10 octets. DATA transparency makes the content dot line two dots; a separate dot-only line ends the transfer, giving14 wire octets. Recovery retains all10 original octets including the final content CRLF. A separate line-boundary drawing shows998 content octets plus2 CRLF octets equal1000; MIME8bit excludes NUL and bare CR or LF. Rejected erratum5646 does not reverse the stuffing rule. This extension is not binary transport.Eight-bit DATA still has lines and a terminatorMIME 8bit line: at most 998 content octets998 content2+ CRLF = 1000 octetsA transparency dot is not in that limitNo NUL · no unpaired CR or LFLine-oriented MIME ≠ arbitrary binary
04
Respect line and binary boundaries.

998 content octets plus CRLF fit the ordinary 1000-octet line boundary.8bit MIME is still line-oriented: NUL and unpaired CR/LF are not permitted; arbitrary binary needs another transport mechanism.

Source for this drawing: RFC 6152 · 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

RFC 5321 SMTP RFC 2045 MIME message bodies RFC 3629 UTF-8

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.

What changed
RFC 6152 § 3RFC 5321 § 4.5.2

The 8-bit extension retains ordinary SMTP transparency: quote a leading content dot, remove that extra dot on receipt, and end DATA with a dot-only line.

Read the updated RFC section ↗
KEY POINT

High-bit support does not change DATA framing.

  • RFC 2045 8bit data uses at most 998 octets between CRLF pairs, with no NUL octets; CR and LF occur only as paired line separators.
  • SMTP transparency doubles a line-leading dot. The receiver removes the added dot; a dot-only wire line terminates DATA. The content’s CRLF immediately before that terminator is retained.
  • RFC 6152 does not remove server line restrictions: a server can allow as few as 1000 octets including CRLF. RFC 5321 excludes an added transparency dot from that limit.
DETAILS

The displayed body fragment café[CRLF].[CRLF] has 10 content octets. One added quoting dot and a three-octet terminating dot line make 14 wire octets. Bracketed labels denote bytes, not literal bracket characters. Rejected erratum 5646 does not reverse the dot-stuffing rule.

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 ↗