Summary

  • Distribution added a propagation condition beside Newsgroups: an ordinary relay path was expected to match both the topic and, when present, at least one requested scope.
  • The reserved value local meant the local site as defined by local configuration. Optional server hints could help a client choose a name, but no portable token contained a universal border.
  • RFC 5537 made the limit explicit: restricted dissemination depended on every receiving site's cooperation, and flood-fill could find any gateway that carried the article outward. Scope was useful policy, not confidentiality.

The same word, two different edges

Imagine two neighbouring news sites receiving an article whose Distribution field says local. The bytes are identical. The intention seems plain. Yet one site's local realm may be a single machine, another's an institutional cluster, and a third relay may not recognize the name at all.

Nothing inside the token draws those edges. Each site has to decide which peers belong to its local exchange and which distributions those peers send or receive. The header can travel farther than the authority needed to interpret it.

This is the small paradox at the centre of Netnews distribution control. A replicated network needed a portable way to express a narrower audience without turning every posting client into a routing administrator. The result was not an access-control list. It was a request that autonomous relays could test against their own configuration.

A second condition beside the newsgroup

The early mechanism appears in RFC 850. Its example is deliberately mundane: a car-for-sale notice placed in broadly named groups but intended only for New Jersey. Distribution was supposed to restrict the existing newsgroup reach, not enlarge it.

RFC 1036 made the two axes easier to see. User subscriptions remained governed by Newsgroups. Relay selection normally required a receiving site to accept at least one named group and, when the extra field existed, at least one named distribution. Topic and propagation scope were separate tests.

That separation prevented a common category mistake. Newsgroups did not necessarily say how far an article should travel, and Distribution did not say which conversations a reader had joined. A broadly replicated group could carry a geographically narrow notice. A local group might already be confined because distant sites did not carry its name. The two mechanisms could reinforce each other without becoming interchangeable.

The border was deliberately absent

RFC 5536 later defined Distribution as geographic or organizational limits on propagation. The grammar carried a list of distribution names, not a topology, membership list or route.

Two reserved names expose the design. world means unlimited distribution and should normally be omitted because no field already implies that default. local means distribution to the local site—but the local site is defined by local software configuration.

The second definition is more important than it looks. It prevents a sender from declaring the size of someone else's local realm. A client may write local; only the site's operating configuration can say whether that means one host, one campus or some other bounded exchange.

Other names are case-insensitive. All is forbidden, and names should usually be at least three characters except for two-letter country codes. Those syntax rules reduce ambiguity, but they do not create a worldwide registry of every organizational boundary. Recognizable spelling is not universal authority.

Servers could suggest, not legislate

Posting software needed help choosing a useful value. RFC 3977 therefore describes the optional LIST DISTRIB.PATS facility. A server can publish weighted rules that map newsgroup patterns to proposed Distribution content. A more specific, higher-weight rule can win over a generic one.

The example structure is revealing. It is a list maintained by some servers, and a client may use it. The server nearest the posting event can explain its own naming practice without pretending that the suggestion is a global truth.

This also keeps execution separate from user-interface convenience. A menu can recommend an appropriate scope. That recommendation does not configure the next relay, establish a peering agreement or guarantee that every downstream site recognizes the same name. Advice helps the poster form a request; it does not become the network boundary.

Every hop still made its own decision

RFC 5537 places the operative test on relaying agents. An article should not be relayed unless the sending and receiving agents are configured for at least one matching newsgroup and, if Distribution is present, at least one matching distribution.

The rule is bilateral. The article supplies a name, but the sending peer must be configured to supply it and the receiving peer to receive it. Neither syntax nor the poster can manufacture that relationship.

This was a practical fit for a network assembled from independent sites. A university, company or regional exchange could build a smaller propagation realm through explicit peer policy. Sites outside it did not need a central service to adjudicate every label. The cost was that correctness lived in many configurations, and the same article could meet different decisions at different edges.

A scope could become part of a conversation

The earliest specification already said a followup should default to the precursor's distribution. RFC 5537 preserves that principle: a posting agent should inherit Distribution when constructing a followup.

Inheritance matters because a reply can disclose the original conversation even if it does not quote every word. Keeping the prior scope by default reduces accidental widening. It also preserves an operator's ability to explain why an article entered one relay realm rather than another.

But inheritance is a default, not an immutable seal. A poster can override it. RFC 850 explicitly contemplated narrowing a reply or escalating a previously restricted discussion when wider distribution was appropriate. The next author therefore owns a new publication decision. A scope label belongs to an article; it does not permanently govern all descendants.

Flood-fill found the difference between request and perimeter

The security boundary is stated without euphemism. RFC 5537 says articles intended for restricted distribution depend on the goodwill of every receiving site. Distribution and Archive can request restrictions on dissemination or retention, but the protocol cannot enforce them.

That limitation is architectural, not a parser defect. A receiving site can copy content, misconfigure a peer, deliberately ignore a request or allow a different mechanism to reintroduce the article. Netnews flood-fill is particularly good at finding any path out of a supposedly restrictive subnet.

The recommended response is topology and administration: organizations that need leakage control should use a small number of gateways for external news exchange. The real perimeter therefore appears where traffic can cross, who operates those crossings and what they enforce. The header remains useful evidence of intended handling, but it cannot replace those controls.

Registration stabilized a name, not a promise

The current IANA Message Headers Registry lists Distribution as a standard Netnews field with RFC 5536 as its reference. Implementations can agree on the field name and syntax.

Registration does not certify the meaning of a site-specific token, prove that a relay honored it or make a leaked copy invalid. Nor do the standards establish present-day deployment, any provider's table of recognized names or the effectiveness of a particular gateway design.

The historical achievement was more restrained. Usenet made desired reach explicit without creating a central cartographer of every community. It let sites coordinate ordinary propagation while preserving their operational autonomy. The field worked when everyone remembered where its authority ended: it could state the requested scope, but the border had to live elsewhere.