Zusammenfassung

  • RFC 1036 verlangte eine Approved:-Zeile für Beiträge an moderierte Newsgroups und empfahl, dass der Moderator seine E-Mail-Adresse einträgt.
  • Die Zeile war ein Annahme- und Weiterleitungssignal, kein kryptografischer Nachweis: Ein späterer historischer Text hielt ausdrücklich fest, dass sich die erklärte Freigabe nicht authentifizieren ließ.

Die Entscheidung musste mit dem Beitrag reisen

Usenet war kein zentraler Server, der jeden Text annahm und eine endgültige Fassung für das gesamte Netz genehmigte. Beiträge wanderten zwischen Standorten, die ausgewählte Newsgroups austauschten und eigene Kopien speicherten. Damit eine Moderationsregel auf diesem Weg wirkte, musste der Beitrag einen softwarelesbaren Hinweis mitführen: durfte er in die normale Verteilung gehen oder musste er noch geprüft werden?

RFC 1036, im Dezember 1987 als Standard für den Austausch von Usenet-Nachrichten veröffentlicht, gab dem Hinweis einen kurzen Namen: Approved. In der allgemeinen Liste waren solche Header meist optional; für Beiträge in einer moderierten Gruppe war das Feld jedoch erforderlich. Der Moderator sollte es hinzufügen und seine Mailadresse eintragen. Die Adresse bot einen praktischen Kontakt und einen für Software erkennbaren Status. Die Spezifikation definierte aber weder eine digitale Signatur noch einen Schlüssel oder ein vertrauenswürdiges Verzeichnis, mit dem der empfangende Standort den Moderator hätte verifizieren können.

Dadurch konnten zwei verschiedene Dinge wie eines wirken. Die Regel setzte eine menschliche Entscheidung voraus; der Header ließ die Software erkennen, dass der Beitrag eine solche Entscheidung behauptete. Er zeigte nicht die Prüfung, ihre Kriterien oder die Person, die sie vorgenommen hatte. Approved benannte einen Zustand, die Adresse einen Kontakt. Beides war kein authentifizierter Beleg der Freigabe.

Dasselbe Feld stand auch bei Gruppenbefehlen

Das Beispiel in RFC 1036 macht die Form konkret. Ein Bericht über die Leserschaft vom 1. Oktober 1986 erscheint in news.lists und news.groups und enthält ein Approved-Feld mit der Adresse des Moderators. Das Xref vermerkt außerdem lokale Artikelnummern auf dem Host seismo. Das Beispiel zeigt, wie eine adressförmige Freigabemarke mit einem gewöhnlichen Nachrichtenartikel reiste. Es belegt weder die Nutzungshäufigkeit noch die Prüfverfahren einzelner Standorte.

Der Header spielte auch bei folgenreicheren Vorgängen eine Rolle. RFC 1036 beschreibt die Kontrollnachricht newgroup, mit der eine Gruppe angelegt und als moderiert gekennzeichnet werden konnte. Standorte sollten eine solche Nachricht ohne Approved ignorieren. Für rmgroup, das die Entfernung einer Gruppe von allen Hosts verlangte, galt dieselbe Bedingung. Das Dokument mahnte zur Vorsicht, weil die Änderung das ganze Netz betraf. Das Feld half der Software, einen gewöhnlichen Befehl von einer Nachricht mit Freigabeanspruch zu unterscheiden; es authentifizierte jedoch nicht die angerufene Autorität.

Diese doppelte Verwendung macht eine Spannung verteilter Protokolle sichtbar: Eine Entscheidung lässt sich überall lesbar machen, ohne ihren Ursprung automatisch prüfbar zu machen. Jeder Standort konnte die Anwesenheit des Feldes prüfen. Sie bewies aber nicht, dass das Postfach dem anerkannten Moderator oder Gruppenadministrator gehörte. Der Standard schuf einen gemeinsamen Prüfpunkt; das Vertrauen dahinter blieb lokalen Vereinbarungen überlassen.

Der spätere Entwurf benannte die Vertrauenslücke

Die Chronologie von „Son of 1036“ muss genau bleiben. RFC 1849 erschien im März 2010 als historisches Dokument, um einen Entwurf zu bewahren, der laut Autor Anfang der 1990er Jahre weit verbreitet war und Implementierern von News-Software als faktische Referenz diente. Das Dokument bezeichnet sich als historischen Hintergrund, nicht als heutige Implementierungsanleitung.

Es trennte die Softwareaufgaben deutlicher. Ein Posting-Agent bearbeitete die Einsendung eines lokalen Nutzers: Er konnte sie vorbereiten, die Regelkonformität prüfen und sie zur Verteilung weitergeben. Ein Relayer nahm bereits vorbereitete Artikel anderer Relayer an und leitete Kopien weiter. Bei einer moderierten Gruppe bedeutete ein fehlendes Approved für den Posting-Agent, dass ein Leserbeitrag zur Freigabe an den Moderator gehen sollte. Ein Relayer sollte einen nicht genehmigten Artikel verwerfen, statt ihn in eine E-Mail-Anfrage umzuwandeln. Ein Programm konnte beide Rollen erfüllen, doch ihre Zuständigkeiten blieben verschieden.

Der historische Entwurf benennt die Grenze direkt: Es gab keine Möglichkeit, einen Approved-Header zu authentifizieren und sicherzustellen, dass die behauptete Freigabe tatsächlich erteilt worden war. Ebenso fehlte ein gepflegtes Verzeichnis legitimer Freigebender. Kryptografische Authentifizierung wurde als sinnvolle Erweiterung genannt; zugleich wies der Text darauf hin, dass viele News-Systeme keinen Echtzeitzugriff auf Schlüsselserver hatten. Das dokumentiert eine Designgrenze, aber keinen konkreten Fälschungsfall und keine allgemeine Annahme gefälschter Felder.

RFC 5537 formalisierte später den Einspeisepfad: Ein Injecting Agent leitet einen nicht genehmigten Beitrag an den Moderator der ersten moderierten Gruppe in der Newsgroups-Liste weiter, üblicherweise per E-Mail. Freigabe und Einspeisung bleiben von der normalen Weiterleitung getrennt. Der spätere Standard macht die Arbeitsteilung deutlich; er beschreibt nicht automatisch jede Installation der 1980er Jahre.

Was die Zeile leistete und offenließ

Approved: war nicht nutzlos, nur weil ein kryptografischer Nachweis fehlte. Das Feld gab räumlich getrennten News-Programmen eine gemeinsame Verarbeitungsbedingung und eine praktische Moderationsadresse. Eine redaktionelle Entscheidung konnte so mit einem verteilten Veröffentlichungssystem reisen. Diese Übertragbarkeit endete jedoch an der Vertrauensgrenze rund um den Header.

Das Netz konnte eine Freigabeerklärung transportieren; der Text allein bewies nicht die Autorität dahinter. Menschliche Prüfung, Adressverwaltung, lokale Richtlinien und Softwareverarbeitung blieben unterschiedliche Teile des Ablaufs. Der Standard reservierte einen sichtbaren Platz für die Entscheidung, aber keinen universellen Weg, ihre Urheberschaft zu beweisen.

Quellen