Summary

  • NNTP separated the globally unique Message-ID from a server-local key made of newsgroup plus article number. One crossposted article could therefore have several local numbers without becoming several articles.
  • Xref gathered those local group positions into one server-scoped filing receipt so reading software could avoid processing the same crosspost more than once.
  • A serving server normally removed the incoming Xref and wrote its own. That rewrite was not damage to the article; it was evidence that location belonged to the server, while identity remained elsewhere.

The second sighting

A reader opens one newsgroup and reads an article. Later, in another subscribed group, the same article appears again. Its title and body match, but its article number does not. Is it a duplicate, a copy or a second publication?

In Netnews, none of those conclusions is necessary. The author may have crossposted one article to both groups. The local server stores one article but indexes it under a separate position in each group. A client that remembers only the first number can mistake the second coordinate for a second article.

This was the problem Xref helped reading software solve. The field did not give the article another identity. It exposed the filing map of the server that last processed it: one server name, followed by the groups and locators under which that server made the article available.

The distinction sounds small until a distributed system is built on the wrong side of it. Identity answers which article survived propagation. Location answers where one particular server currently lets a reader retrieve it. Usenet needed both, and needed them not to collapse into each other.

Three keys, three scopes

RFC 3977, the 2006 specification for NNTP, describes three kinds of key used to store and retrieve news articles. The first is the Message-ID, globally unique for the article. The second combines a newsgroup name with an article number inside that group. The third is an arrival timestamp maintained by the server.

The group-and-number key has strong local rules. Within one group on one server, a number points to only one article, and one article cannot hold two numbers in that same group. But a crossposted article can hold one key in each group, and the numbers may differ. The same group-and-number pair can also point to different articles on different servers.

That is the decisive boundary. An article number is not a small global identifier. It is a coordinate inside a server's group view. Numbers are allocated in local arrival order. The GROUP command returns low and high water marks plus an estimated count, not a promise that every number between them exists. Articles can be removed, and a previously stored article can be reinstated under its earlier number within the protocol rules.

The coordinate therefore carries history and policy that belong to the server: arrival, retention, expiry, moderation and repair. A gap does not prove that the network deleted an article. A high number does not prove global recency. A familiar number on a new server does not prove identity.

One article, several shelves

RFC 5536 defines crossposting as posting one article to more than one newsgroup, distinct from posting the same text as separate articles. Servers typically store only one copy. The article has one Message-ID, while its group indexes can fan out around it.

Xref is a compact expression of that fan-out. Its value begins with the identity of the news server that generated it, followed by one or more locations. Each location couples a newsgroup name to an article locator. The traditional NNTP locator is a decimal article number, but the field allows an implementation-specific locator.

The server name is not decoration. It tells software which coordinate system the following locators belong to. Remove that scope and the same apparent group position may refer to another article elsewhere. Keep it, and a reader can recognize that several positions in one server's view lead back to one article.

RFC 5536 says user agents often use this information to avoid processing crossposted articles more than once. A client can mark the connected positions as seen after presenting the article in one group. That is not only a convenience. It preserves the semantics of crossposting: one contribution can address several audiences without being counted or handled as several independent articles.

Declared groups and filed groups are not the same claim

The Newsgroups field says where the article was posted. Xref says where the last server filed it. RFC 5536 explicitly permits the locations in Xref to differ from the groups declared in Newsgroups.

This difference is operationally honest. A server may not carry every group. Local policy may reject or redirect a filing. The serving view can change through retention or moderation. Copying the author's declaration into the filing receipt would conceal those local decisions.

The two fields therefore answer different questions. Newsgroups travels with the article's declared distribution. Xref materializes a local storage view. Neither should be used to counterfeit the other's authority.

The receipt was meant to be replaced

The field's history makes its locality unusually clear. RFC 1036, published in 1987, described Xref as a host name plus group/message-number pairs drawn from that host's spool directory. It said the information was useful only to the local system and should not be transmitted. Its example placed one article at two different numbers in two groups on the same host.

The later architecture admitted a more controlled life across components without turning the receipt into permanent identity. RFC 5537 allows a relaying agent to delete an existing Xref and add one for its own use. A serving agent normally must remove the incoming field, except under a special configuration that preserves the sending site's locators, and may—usually will—write a new one before storage.

That replacement is not an accidental loophole. The same RFC says relaying and serving agents must not alter, delete or rearrange the article except for Path and Xref, and must not modify its body. Location metadata changes while the article remains the article.

This is the design's most important sentence even when read as architecture rather than prose: the local receipt can be rewritten at custody boundaries because it records the server's filing decision, not the author's durable article.

A server name is scope, not a seal

It is tempting to read the named server as evidence of origin. The specifications do not grant that power. The name tells software how to interpret the locations; it is not a cryptographic signature, an author verification or proof of the first server in the article's journey.

The fact that relays and serving agents can remove and regenerate the field is itself a warning against treating it as immutable provenance. This non-authentication boundary is an inference from the rewrite rules and the absence of an authentication contract. Xref is valuable evidence of a serving view, but only within the trust and observation context of that server.

The current IANA Message Headers Registry lists Xref as a standard Netnews field and points to RFC 5536. It also registers Message-ID and Newsgroups separately. Registration preserves a common vocabulary. It does not merge article identity, declared distribution and local location into one authority.

The number meant somewhere

The achievement of Xref was not to invent a stronger identifier. It was to let a distributed reading system admit that one article can have several coordinates, and that those coordinates can change at the next server without changing the article.

That model prevents two symmetrical errors. Treating location as identity creates duplicates whenever one article occupies several groups or moves between server views. Treating identity as location assumes that a globally named article must have one universal address, which NNTP never promised.

The official evidence does not show how common Xref is in present clients or how individual providers implement read state. It cannot explain why a particular local article disappeared. What it does establish is the scope of the mechanism: Message-ID answers “which article”; Xref answers “where this server filed it.” The restraint is the feature.