Summary

  • Each Netnews agent prepended its own Path identity, creating a right-to-left trail of the relays that had already processed an article.
  • A sender could skip a neighbouring relay already named in that trail, avoiding a redundant return transmission before the neighbour's separate Message-ID history had to reject the duplicate.
  • Path was deliberately weaker than an authenticated route: a single bang made no verification claim, modern diagnostics recorded bounded observations, and the final not-for-mail entry was not a relay at all.

The waste happened before the duplicate

Consider three news servers connected in a triangle. One article enters at A, moves to B and then reaches C. Flooding asks each server to offer accepted articles to interested neighbours. Without any memory of the journey, B could send the article back to A. A would recognize the Message-ID and discard the repeat, so the network would eventually converge. It would also have paid to move bytes that were certain to be thrown away.

Usenet developed two answers because these were two different failures. The history database remembered logical articles by Message-ID and rejected a repeated identity after it returned. The Path field made the journey visible early enough to avoid a needless offer or transfer to a relay already named. History protected convergence; Path reduced avoidable work along the way.

This division is explicit in RFC 1036. Its propagation algorithm calls Message-ID history sufficient to stop loops, then describes Path as an additional optimisation. If A sends an article to B, A's name is already in the field, so B should not immediately send the article back. One mechanism decides “I have seen this article.” The other decides “this neighbour is already in its trail.”

The distinction prevents a misleading history of Usenet. Path was not invented because servers lacked article identity. Nor was Message-ID history enough to make traffic efficient. A distributed system can be correct in the limit and wasteful at every edge. Path attacked the waste before the final duplicate test.

The newest step appeared on the left

The field looked like a row of names separated by punctuation, most famously exclamation marks. Yet its time direction ran opposite to ordinary prose. Each receiving system added itself at the left. If an article arrived with A!X!Y!Z, server B turned the visible trail into B!A!X!Y!Z. The newest observer was first; the injection end receded to the right.

RFC 850, published in 1983, already described this left-prepending rule. It allowed several separators and preserved compatibility with the older “bang path” world. The value could look like a manually routed mail address, but the document gave an unusually direct warning: Path was not for replies and should not be treated as a mailing address.

That warning mattered because the resemblance was historical, not semantic. A news article and a mail reply could move through different systems. A relay name might be meaningful to news peers but unknown to a mail handler. Even when a visible sequence happened to work as a return route, the protocol did not grant it that authority.

The intermediary historical record, RFC 1849, later tightened the operational picture. The text came from a widely circulated early-1990s draft and was published in 2010 as historical background, not current implementation guidance. It reduced the practical grammar to relay names separated by !, followed by a trailing local part. Relays had to prepend their name and avoid passing an article to a named neighbour.

The same document explained why this was not a cosmetic optimisation. Message-ID history would normally reject a looping copy, but without Path the ordinary link from X to Y could carry every accepted article back in the wrong direction before rejection. Confused relay names could double traffic across a feed. Correctness survived; capacity did not.

A tail that was not part of the trail

The rightmost component created a subtle parsing trap. In the historical grammar it could be a local part associated with a sender. It was not necessarily another relay in the visited list. Treating it as one could suppress a legitimate feed to an unrelated news server that happened to use the same string.

The modern format makes the boundary visible. RFC 5536 defines a path-list followed by a tail-entry. The tail may be not-for-mail, a phrase inherited from the long retreat from Path-derived reply addresses. The phrase is not a routing instruction, an error or a server name. It says, in effect, that the old address-shaped slot should not be mistaken for a mailbox.

This is why scope belongs in the data model. A parser that stores every bang-separated token in one undifferentiated “servers visited” array changes the protocol's claim. The same characters occupy different roles depending on whether they are inside the path list, a diagnostic or the tail.

NNTP moved articles without owning their trace

Usenet news originally travelled over several mechanisms. RFC 977 standardized NNTP in 1986 so cooperating hosts could distribute, retrieve and post news over a reliable stream such as TCP. RFC 3977 replaced it in 2006 with a more complete protocol contract.

Neither transformation made Path a list of TCP connections. The current architecture in RFC 5537 is explicit that Netnews article handling is independent of a particular underlying transport. Path stays with the article as injecting, relaying and serving components process it. A TCP session can close while the article and its trace persist; a gateway can move an article through another medium; several logical components can share a system.

The field therefore records application-layer agent claims, not routers traversed by IP packets. It does not instruct the network where to send the next packet. The prospective sender combines the article's path identities with its own configured feed relationships. The operator's topology and peer policy remain outside the string.

One bang did not equal a verified handoff

RFC 5536 and RFC 5537 modernised the field by admitting different grades of knowledge. Every processing news-server component uses a path identity, preferably a fully qualified domain name or another name whose uniqueness the relevant administrators can guarantee. Peers need a shared understanding of that identity; otherwise a correct loop test cannot work.

When the agent on the left verifies, to its satisfaction, the path identity immediately to its right, the syntax can show two consecutive bangs. The !! diagnostic is local evidence of an adjacent check. A single ! makes no such claim. It is not a shorter spelling of the same assurance.

Other diagnostics preserve uncertainty instead of erasing it. POSTED marks injection and may record the source seen by the injector. MISMATCH says the expected identity of the source did not equal the leftmost identity presented in the article. SEEN says the receiving component recorded a source but was unwilling or unable to validate it as the claimed path identity.

The expectation comes from the receiving connection: for example, a peer authentication identity or an IP address. This makes each diagnostic a statement by one observer inside one trust relationship. A mismatch may result from a stale alias, a name migration, proxying, configuration error or deception. The syntax records the divergence; it does not conduct the investigation.

Even a chain of double bangs is not an end-to-end signature. Each mark concerns one adjacency and one agent's satisfaction. There is no cryptographic commitment covering every previous character, no proof of the poster's identity and no promise that the named systems stored or served the article. RFC 5537 separately advises relays to accept articles only from trusted agents because Path and Injection-Info can otherwise be forged.

The relay still made the decision

The modern relay rule remains narrow. An article should not be sent to a receiving agent if that receiver's path identity, or a known alias, already appears in the path list. The test excludes the tail and identities that occur only after a POSTED diagnostic. A string match without those scopes can reject the wrong feed.

Nor does the field force a send to every neighbour absent from the list. Group and Distribution configuration, local acceptance policy, peer trust, article validity, capacity and other controls still apply. Path supplies negative evidence for one decision: this prospective peer is already represented in the journey. Absence is not positive authorization.

The Message-ID history database remains a separate defence. It handles the same logical article arriving by another path, a peer ignoring the optimisation, and ordinary convergence in a flood. Gateways need further precautions because translation into another medium can discard trace and identity properties, then reinject the result. Path is useful because its jurisdiction is small, not because it closes every loop.

A mutable record could still be valuable

Path is one of the few article fields relays and serving agents are allowed to change. That mutability does not make it meaningless. It makes the field a custody-adjacent working record whose value depends on who added which component, under what connection evidence and for what next-hop decision.

The historical achievement was to keep that record subordinate to running operators. No central service calculated an authoritative route for every article. Each relay advertised an identity to peers, inspected the trace it received, applied its own configured relationships and added a bounded observation. A bad identity could waste or suppress traffic, but the field did not acquire power over authorship, storage or global truth.

The RFC evidence establishes this design and its stated failure modes. It does not show which present services use these diagnostics, how their aliases are configured, whether a particular Path is accurate or the downstream result after one server accepted an article. Those questions require live peer, session, transfer, history and storage evidence.