Zusammenfassung

  • RFC 1036 knüpfte cancel an einen lokal vorhandenen Artikel mit der angegebenen Message-ID; konnte der Host ihn nicht stornieren, sollte er die Anfrage nicht an Nachbarsysteme weiterleiten.
  • Die Control-Nachricht lief über dieselbe Newsgroup-Verteilung wie gewöhnliche Beiträge, durfte aber nur vom Autor oder lokalen News-Administrator gesendet werden und unterlag einem Header-Abgleich.
  • Das ist eine hostbezogene Spezifikationsregel, kein Beleg dafür, dass ein Beitrag aus allen Systemen, Archiven oder Leserkopien verschwand.

Eine verteilte Nachricht war noch kein globaler Löschbefehl

Usenet-Beiträge lagen nicht nur an einem Ort. Sie wurden zwischen Hosts ausgetauscht, die von unterschiedlichen Betreibern geführt wurden und jeweils ihren eigenen Bestand verwalteten. Deshalb beginnt die Cancel-Regel in RFC 1036 mit einer lokalen Frage: Ist der Beitrag mit dieser Message-ID hier vorhanden?

RFC 1036 erschien im Dezember 1987 und beschreibt cancel als Control-Nachricht für die News-Software. Findet das lokale System den Artikel, kann es ihn dort stornieren. Kann es den angeforderten Schritt nicht ausführen, soll es die Stornierungsanfrage nicht an benachbarte Systeme weitergeben. Der Haltepunkt liegt also genau dort, wo die lokale Handlung nicht möglich ist.

Das trennt Verteilung von Befugnis. Eine Anfrage kann weit reisen, ohne überall dieselbe Wirkung zu haben. Ein Host kann den Zustand eines Beitrags, den er nicht besitzt, nicht selbst feststellen und schon gar nicht auf einem fremden System löschen. RFC 1036 beschreibt keine zentrale Stelle, die alle Kopien verwaltet oder den Abschluss netzweit bestätigt.

Die Control-Nachricht nutzte den normalen News-Weg

Ein Artikel mit einem Control-Feld galt als Nachricht für die Usenet-Hosts und nicht als Text für gewöhnliche Leser. RFC 1036 sagt, dass Control-Nachrichten über denselben Newsgroup-Mechanismus verbreitet werden wie normale Beiträge. Implementierer und Administratoren konnten sie automatisch bearbeiten oder in eine Warteschlange legen; manuell bearbeitete Nachrichten sollten zeitnah behandelt werden. Fehlgeschlagene Control-Nachrichten sollten an das lokale usenet-Konto gehen, nicht an den Absender.

Transport und Ausführung waren damit getrennte Schritte. Der Host konnte die Nachricht erhalten, musste anschließend die Message-ID im lokalen Bestand suchen und die Absenderregel prüfen. Aus der Zustellung folgte noch keine Aktion. Ebenso wenig gab es eine gemeinsame Löschliste, in der jeder Server seinen Status eintrug.

Die Absenderprüfung blieb eine begrenzte Header-Regel

Senden durften cancel nach RFC 1036 nur der Autor des Artikels oder der lokale News-Administrator. Als verifizierten Absender verwendete das System Sender, falls vorhanden, sonst From. Dieser Wert musste mit Sender oder From des ursprünglichen Artikels übereinstimmen. Die RFC erlaubte ausdrücklich auch den Abgleich eines verifizierten Cancel-Absenders mit einem nicht verifizierten ursprünglichen From.

RFC 822 erklärt die Rolle von Sender, wenn die einreichende Person oder der Agent nicht mit dem Autor identisch ist. RFC 1036 nutzt die Felder für die Cancel-Prüfung. Das ist ein Vergleich von Kopfzeilen, keine digitale Signatur und kein moderner Nachweis einer Kontoidentität. Die Spezifikation nennt die zu vergleichenden Felder; sie belegt nicht, dass sie fälschungssicher waren oder jeder Host die Prüfung tatsächlich ausführte.

Der Unterschied zur RFC 850

RFC 1036 aktualisierte und ersetzte RFC 850 für Version B2.11 des News-Programms. Die Fassung von 1983 erlaubte bereits, einen lokal vorhandenen Beitrag auf Anfrage seines Autors oder eines lokalen Superusers zu stornieren. Die Fassung von 1987 sprach vom lokalen News-Administrator und ergänzte ausdrücklich die Stop-Regel bei fehlender lokaler Handlungsmöglichkeit.

Das ist eine Änderung in den veröffentlichten Texten, keine Chronik der Installation auf allen Usenet-Rechnern. RFC 1036 erklärt selbst, dass es keinen Internet-Standard spezifiziert. Es ließ den Hosts Spielraum bei Übertragungshardware, Software und Bündelung. Die RFC belegt die formulierte Regel, nicht eine universelle Umsetzung.

Der lokale Zustand sagt nichts über alle Kopien

Ein Server kann einen passenden Artikel finden und die Anfrage bearbeiten; ein anderer findet ihn vielleicht nicht und stoppt. Ein separates Archiv, ein Zitat oder ein weiterer Host kann trotzdem noch eine Kopie haben. Die Regel betrifft die lokale Handlung. Sie verspricht weder das Verschwinden aller Beiträge noch geänderte Suchindizes oder das Vergessen bereits gelesener Inhalte.

Man kann das Weiterleitungsverbot als Schutz davor verstehen, eine lokal nicht ausführbare Anweisung blind auszubreiten. Das ist eine redaktionelle Schlussfolgerung, keine im RFC erklärte Absicht. Diese Unterscheidung bewahrt den begrenzten Mechanismus davor, als Geschichte einer globalen Zensur oder Löschung missverstanden zu werden.

Quellen und Grenzen

Primärquellen sind RFC 1036, besonders die Abschnitte Control und Cancel, der Vorgänger RFC 850 und RFC 822 zum Sender-Feld. Sie belegen Spezifikationstext, nicht Verbreitung, Verhalten einzelner Hosts, reale Laufzeiten, kryptografische Authentisierung oder netzweite Löschung.