Summary

  • SMTP's DATA phase ended on a line containing one period, so an identical line in the user's message needed a reversible transparency rule.
  • The sender duplicated every line-leading period; the receiver recognized the single-period terminator and removed one period from all other affected lines.
  • CHUNKING later framed message data by exact octet counts and an explicit final chunk, removing the forbidden sequence while making byte accounting authoritative.

One channel had to change roles

RFC 821's SMTP dialogue is deliberately lock-step. The sender issues commands, the receiver replies, and DATA temporarily turns the same ordered stream into mail content. The protocol then needs an unmistakable point at which content ends and commands may resume.

The chosen marker was simple: a line containing only a period. Simplicity made sessions readable and implementations small. It also placed protocol meaning inside the namespace of user text. A perfectly ordinary line could look exactly like control.

Transparency was a bilateral promise

SMTP did not forbid that text. Before transmission, the sender checks each line. If the first character is a period, it inserts another. At reception, a lone period ends DATA; any other line beginning with a period loses its first period.

The operation later became known as dot stuffing. Its important property is reversibility. The transport form differs from the user's message, but compliant endpoints restore the message before delivery. RFC 821 warned that transformations applied during relaying must remain reversible.

The rule allocates responsibility evenly. The sender protects ambiguous content; the receiver alone interprets the marker and undoes protection. If either side skips its half, a message may end early or acquire an extra character.

A small exception became part of every line scanner

RFC 5321 retains the same transparency procedure decades later. It even specifies that the extra duplicated period does not count against the 1000-octet maximum text-line length.

That exception shows how framing reaches beyond parsing. Buffer limits, relays, logging and test cases must know whether they are observing the stored message, canonical SMTP text or the wire form after transparency. “One extra dot” is small in bytes and large in state.

Byte counts removed the forbidden line

RFC 3030's CHUNKING extension introduced BDAT as an alternative to DATA. A BDAT command states the exact number of octets that follow; an optional LAST marks the final chunk. The receiver no longer scans content for a terminator, so a period-only line has no special force inside that chunk.

This is not a universal replacement. A server advertises CHUNKING through EHLO, a client chooses it only after that declaration, and supporting servers must continue to accept DATA. Capability negotiation preserves older peers instead of redefining their input.

Freedom from sentinels made counting sovereign

Length framing changes the failure mode. The sender must calculate the canonical octet count exactly. If the announced size and transmitted bytes differ, the receiver's boundary moves: material can be swallowed into a chunk or exposed to the command parser.

BINARYMIME therefore depends on CHUNKING. Arbitrary octets cannot safely use DATA's line-oriented sentinel. After accepting BINARYMIME, a receiver promises to preserve every bit passed through BDAT; the sender in turn must respect the precise framing and canonical MIME requirements.

The new method did not eliminate trust. It moved trust from content transformation to arithmetic and prior capability agreement.

Sources and limits

The history is documented in RFC 821, RFC 5321 and RFC 3030. They establish requirements, not adoption rates or incident prevalence. DATA remains mandatory for CHUNKING-capable servers, and dot transparency is framing—not encryption, authentication or message-integrity protection.