Summary

  • From RFC 733 onward, the system that created a message identifier had to make it unique. A revision received a new ID; transport-added trace fields did not necessarily change the original identity.
  • In-Reply-To and References turned identifiers into a conversation graph. Netnews went further: each server remembered seen IDs and discarded repeats, allowing a replicated distribution system to terminate loops locally.
  • The name was never a signature or content hash. Netnews deliberately treated equal IDs as one article even when bodies differed, so a predictable collision could suppress the intended article.

The bytes changed; the message did not

Imagine a message entering transport. The next relay prepends a Received field. The stored bytes are no longer identical to the submitted bytes, yet the relay has not authored a revision. The original Message-ID remains.

Now imagine the author changing the proposition the message conveys and issuing the revision as a new message. Much of the text may be identical, but the identity should change. This was the line drawn by RFC 733 in 1977: an identifier referred to exactly one version or instantiation, and later revisions should receive new identifiers. The generating host, not a central registry, guaranteed uniqueness.

RFC 822 carried that rule into the 1982 Internet message format. The field was intended for machines, not for human meaning. Its purpose was not to summarize a subject or identify a person. It supplied a stable handle for one declared message version.

That definition avoided both easy extremes. Identity was not whatever byte sequence happened to be stored at one hop. Nor was it an eternal identity for every revision of an idea. The composing side declared the instantiation; other systems preserved and referenced the name.

A global name assembled locally

The modern rule in RFC 5322 is explicit: a message identifier must be globally unique, and the generator must guarantee it. Yet the standard defines no office that allocates one ID at a time.

Instead, it recommends a divided namespace. A domain identifier belongs on the right side of @; on the left, the generator places a value it can keep unique within that scope, perhaps combining time with a sequence or process-specific value. A globally recognizable scope plus local bookkeeping creates a global name without a global transaction.

The resemblance to an address is useful but limited. The right side helps partition responsibility. It does not make the identifier a mailbox, require that it resolve today, authenticate the author or prove control of the domain. No recipient should infer hidden business meaning from the left side either.

The same RFC makes the semantic boundary unusually clear. Adding trace or resent fields can change syntax without making a new message. The sender’s intended meaning—whether this is the same message or a different one—governs whether the ID changes. Message-ID is therefore neither a checksum nor an SMTP delivery identifier.

A reply became an edge

A stable name becomes more valuable when another object can point to it. In-Reply-To carries the ID of the parent message. References carries the parent’s earlier ancestry followed by the parent’s own ID. Software can use that sequence to display a thread even when messages arrived through different routes or at different times.

This graph was not invented only for modern mail clients. RFC 850, the 1983 Usenet interchange standard, required a follow-up to extend the original article’s References. It stated the operational purpose: reader software could group articles into conversations, and a reader could ignore a conversation without leaving the whole newsgroup.

The graph also has limits. RFC 5322 notes that software often assumes a single parent when walking backwards. Multiple-parent construction is not fully defined. A References chain records declared ancestry; it does not prove that the reply understood, quoted or was authored by the parent’s author.

The identifier became memory at every server

Usenet made Message-ID part of distribution control. In a flood among peers, a server can receive the same article from more than one direction. If every arrival were forwarded again, a cycle could run indefinitely.

RFC 1036 describes the history mechanism: each host keeps track of articles it has seen by Message-ID. When that ID arrives again, the host discards the incoming copy immediately. The Path field can prevent needless transmission to a known prior hop, but local history is sufficient to stop the loop.

This is decentralized convergence. No master server marks an article globally complete. Each site compares one name with its own memory and decides that it has already admitted that logical article. The same field that supports a human conversation becomes a compact key for distributed duplicate suppression.

When equal names overruled unequal bodies

RFC 5536 makes the trade-off stark. Netnews treats articles with the same Message-ID as the same article regardless of differences in body or headers. It narrows syntax, caps length and preserves case so servers can compare IDs as octets quickly and consistently. It also says uniqueness spans protocols using these identifiers, especially email and Netnews.

That rule makes propagation tractable; it also turns a collision into authority. If an attacker can predict the ID of a future article and posts another article with that ID first, a server may reject the intended article as already seen. RFC 5536 therefore recommends unpredictability. The danger is not a broken content digest—there was no digest. It is a false claim entering the distributed name ledger first.

What the name never proved

Message-ID solves reference, not trust. It does not sign a body, authenticate a From field, identify an SMTP envelope transaction, prove that a reader saw the message or guarantee that two copies contain equal bytes. Equal IDs may hide a collision; unequal IDs may carry identical text.

That modesty is the reason the design endured. The origin owns naming. Transport may add custody evidence without renaming. Mail software owns reply edges. News servers own local history and collision handling. Cryptographic proof belongs to another layer.

Sources and limits

The historical chain is RFC 733, RFC 822, RFC 850, RFC 1036, RFC 2822, RFC 5322 and RFC 5536. These documents establish format and recognized failure modes. They do not measure current collision rates, provider algorithms, implementation share or retention periods.