Zusammenfassung

  • Jeder Netnews-Agent stellte seine Path-Identität voran. Der jüngste Verarbeitungsschritt stand links, die Spur wuchs entgegen der Leserichtung.
  • Vor dem Transfer konnte ein Relay einen bereits genannten Nachbarn auslassen. Die lokale Message-ID-Historie blieb eine eigene Schutzschicht gegen tatsächlich eintreffende Duplikate.
  • !! behauptete eine Prüfung der benachbarten Identität, ein einzelnes ! nicht. POSTED, MISMATCH, SEEN und der Tail not-for-mail hatten jeweils engere Bedeutungen.

Ein verworfenes Duplikat hatte die Leitung bereits benutzt

A liefert einen Artikel an B. Im Flood-Fill-Verfahren bietet B akzeptierte Artikel mehreren interessierten Nachbarn an. Sendet B den Artikel gleich an A zurück, findet A dessen Message-ID in der eigenen Historie und verwirft die Kopie. Die Schleife endet, aber über die Verbindung lief eine Übertragung mit vorab feststehendem Ergebnis.

Netnews brauchte deshalb zwei Arten von Gedächtnis. Die Historie des Servers beantwortete, ob dieser logische Artikel schon bekannt war. Path beantwortete vor dem Senden, ob der vorgesehene Empfänger bereits in der Reise auftauchte. Das eine sicherte Konvergenz, das andere vermied vorhersehbare Arbeit an einer Kante.

RFC 1036 trennt beide Funktionen. Eine Message-ID-Historie reicht aus, um Schleifen zu beenden. Path ist die zusätzliche Optimierung, die insbesondere verhindert, dass B den gerade von A empfangenen Artikel sofort an A zurückgibt. Damit bleibt die Grenze zum bestehenden Message-ID-Beitrag klar: Hier geht es um die Nachbarentscheidung vor dem Duplikatentransfer, nicht um die globale Benennung des Artikels.

Der neueste Schritt kam nach links

Empfängt B A!X!Y!Z, setzt es den eigenen Namen davor: B!A!X!Y!Z. Gegenwart steht links, ältere Stationen liegen weiter rechts. Das Feld darf sich bei der Weitergabe ändern, ohne dass daraus ein neuer Artikel wird.

RFC 850 beschrieb 1983 bereits dieses Voranstellen. Mehrere Trennzeichen waren erlaubt, und die Folge erinnerte an manuell geroutete UUCP-Mailadressen. Gerade deshalb zog der Text eine scharfe Grenze: Path war nicht für Antworten bestimmt und sollte nicht als Mailadresse verstanden werden.

Ein Newsweg musste kein Mailweg sein. Ein zwischen zwei Relays vereinbarter Kurzname konnte einem Mailprogramm unbekannt bleiben. Dass alte Software eine solche Folge manchmal als Rückweg nutzen konnte, machte aus der Ähnlichkeit keine Protokollzusage.

RFC 1849 bewahrt die Zwischenphase. Das Dokument wurde 2010 als historische Fassung eines in den frühen 1990ern weit verbreiteten Entwurfs veröffentlicht und ist keine aktuelle Implementierungsnorm. Es zeigt jedoch die gelebte Regel: Relay-Namen, getrennt durch !, ein lokaler Teil am Ende, Voranstellen des eigenen Namens und kein Versand an einen bereits genannten Nachbarn.

Seine Begründung ist betriebswirtschaftlich. Die Message-ID-Historie würde zurückkehrende Kopien zwar ablehnen. Ohne übereinstimmende Relay-Namen könnte aber jeder Artikel über eine Feed-Verbindung hin- und zurücklaufen. Das Ergebnis bliebe logisch korrekt, während Kapazität systematisch verschwendet würde.

Der Tail war keine besuchte Station

Der äußerste rechte Bestandteil konnte historisch einen lokalen Teil des Absenders enthalten. Er gehörte nicht zur Liste der besuchten Relays. Wer alle mit ! getrennten Wörter als Server behandelt, kann deshalb ein legitimes Ziel sperren, das zufällig denselben Namen verwendet.

RFC 5536 unterscheidet formal zwischen path-list und tail-entry. Der Tail darf not-for-mail lauten. Das ist weder Fehler noch Hostname, sondern eine offene Absage an die alte Vorstellung, die adressähnliche Stelle sei ein Postfach.

Für die Auswertung zählt also die Rolle im Syntaxbaum. Eine Identität in der Path-Liste kann einen Versand ausschließen. Eine Quelle nach POSTED oder der abschließende Tail darf trotz gleicher Zeichenfolge nicht dieselbe Entscheidung auslösen.

NNTP transportierte den Artikel, nicht die Bedeutung seiner Spur

RFC 977 standardisierte 1986 Verteilung, Abruf und Posting von News über einen zuverlässigen Stream wie TCP. RFC 3977 ersetzte dieses NNTP-Protokoll 2006. Beide legen Befehle und Antworten fest; sie machen Path nicht zu einer Liste von TCP-Verbindungen.

Die Architektur in RFC 5537 ist ausdrücklich vom darunterliegenden Transport unabhängig. Ein Artikel überlebt geschlossene Sessions, kann verschiedene Komponenten eines Servers durchlaufen und über Gateways in ein anderes Medium wechseln. Path nennt News-Agenten auf Anwendungsebene, keine IP-Router.

Auch den nächsten Weg schreibt das Feld nicht vor. Betreiber haben bereits Feed-Beziehungen, Gruppen, Distribution-Regeln und Annahmerichtlinien. Eine vorhandene Identität liefert einen begrenzten negativen Grund, eine bestehende Verbindung nicht zu nutzen. Ein fehlender Name schafft weder Beziehung noch Freigabe.

Die Zeichen hielten unterschiedliche Gewissheit fest

Die Standards von 2009 verlangen, dass verarbeitende Komponenten eine path identity voranstellen. Bevorzugt wird ein vollqualifizierter Domainname; möglich ist auch ein anderer Name, dessen Eindeutigkeit im relevanten Peer-Kreis gewährleistet wird. Entscheidend ist die Abstimmung zwischen Nachbarn einschließlich bekannter Aliasnamen.

!! bedeutet, dass der Agent links die unmittelbar rechts stehende Identität nach eigenem Maßstab geprüft hat. Ein einzelnes ! enthält diese Behauptung nicht. Eine Normalisierung, die beide Formen zusammenwirft, erfindet Beweiskraft.

POSTED markiert die Einspeisung. MISMATCH hält fest, dass die aus der Verbindung erwartete Quellenidentität nicht mit der führenden Angabe übereinstimmt. SEEN bewahrt eine beobachtete Quelle, wenn der Empfänger sie nicht als behauptete Path-Identität prüfen kann oder will. Die Erwartung kann aus Peer-Authentisierung oder der Quell-IP stammen.

Jede Markierung ist damit die Aussage eines Beobachters über eine Nachbarschaft. Ein MISMATCH kann auf Täuschung hinweisen, aber ebenso auf einen alten Alias, eine Migration, einen Proxy oder uneinheitliche Großschreibung. Auch viele !! ergeben keine Ende-zu-Ende-Signatur: Jede Prüfung ist lokal und bindet nicht kryptografisch die gesamte Vorgeschichte.

RFC 5537 empfiehlt zusätzlich, Artikel nur von vertrauenswürdigen Agenten anzunehmen, um gefälschte Path- und Injection-Info-Angaben zu begrenzen. Das Vertrauen liegt in der Betriebsbeziehung, nicht im bloßen Feldinhalt.

Abwesenheit war keine Weiterleitungserlaubnis

Ein Artikel soll nicht an einen Empfänger gehen, dessen Identität oder bekannter Alias bereits in der gültigen Path-Liste steht. Tail und bestimmte diagnostische Positionen sind ausgenommen. Daraus folgt jedoch keine Pflicht, an jeden nicht genannten Nachbarn zu senden.

Newsgroups und Distribution, Artikelgültigkeit, Peer-Vertrauen, Kapazität und lokale Richtlinien bleiben eigenständig. Die Message-ID-Historie wird weiterhin für Kopien aus anderer Richtung benötigt. Gateways brauchen zusätzliche Schleifenkontrollen, weil eine Medienumwandlung Identitäts- und Spureigenschaften verlieren und Inhalte neu einspeisen kann.

Path war dauerhaft nützlich, weil es wenig beanspruchte. Es trug gerade genug gemeinsame Geschichte, um eine offensichtliche Rückfahrt zu vermeiden. Es bewies weder Urheberschaft noch Speicherung, Lektüre, Paketroute oder globale Obhut.

Die RFCs belegen diese Semantik und ihre Grenzen, nicht die heutige Nutzung. Ob ein bestimmter Dienst Diagnosen setzt, ein Name korrekt ist oder ein Artikel Leser erreichte, lässt sich nur aus Verbindungs-, Transfer-, Historien- und Speicherdaten ableiten.