Zusammenfassung

  • y, n und m in LIST ACTIVE bezeichneten den normalen Umgang eines Servers mit Beiträgen, nicht das individuelle Recht des verbundenen Clients.
  • Ein gesperrter Client blieb in einer y-Gruppe gesperrt; ein Client mit Sonderrechten konnte unter Umständen in einer n-Gruppe posten.
  • Katalog, Authentisierung, lokale Autorisierung, Artikelannahme und spätere Sichtbarkeit waren getrennte Beweisflächen.

Ein richtiges Signal wurde zur falschen Zusage

Ein Newsreader lädt die aktive Gruppenliste. Neben einer Gruppe steht y, also öffnet die Oberfläche den Editor. Erst nach dem Schreiben sendet sie POST. Der Server antwortet 440, bevor er den Text anfordert.

Der Server muss dabei keinen veralteten Katalog geliefert haben. y beantwortete die Frage, wie Beiträge zu dieser Gruppe normalerweise behandelt werden. 440 beantwortete, ob dieser Client in dieser Verbindung jetzt handeln durfte. Die Oberfläche hatte nur den Geltungsbereich vertauscht.

Die Gegenprobe ist ebenso wichtig. RFC 3977 erwähnt ausdrücklich, dass ein Client mit besonderen, von der Spezifikation nicht definierten Rechten in einer mit n markierten Gruppe posten könnte. n bleibt eine gültige Grundregel, ohne jede lokale Ausnahme zu bestreiten.

Die Unabhängigkeit stand schon in RFC 977

RFC 977 legte 1986 für LIST vier Felder fest: Gruppenname, letzte und erste bekannte Artikelnummer sowie y oder n. Das kompakte Format konnte viele Gruppen mit einer Antwort beschreiben.

Direkt danach warnte der Text, dass einem Client das Posten trotz eines erlaubenden Gruppenflags untersagt sein könne. Das Flag unterschied unter anderem normale, moderierte und Digest-Gruppen. Es war ausdrücklich unabhängig von der Schreibberechtigung, die der NNTP-Server einem Client gewährte.

Die individuelle Entscheidung traf POST. Mit 340 forderte der Server den Artikel an; mit 440 verweigerte er die Übermittlung aus einem installationsabhängigen Grund. Welche Clients und Hosts schreiben durften, blieb lokale Politik. Standardisiert wurde der beobachtbare Entscheidungspunkt.

Diese Arbeitsteilung erlaubte stabile Gruppendaten bei wechselnden Konten und Rechten. Eine allgemeine Tabelle musste kein vollständiges Identitätssystem werden.

ACTIVE war eine Serveransicht

RFC 3977 bezeichnete die Variante als LIST ACTIVE. Ohne Filter enthält sie alle Gruppen, die der Client mit GROUP auswählen darf. Schon deshalb ist sie kein weltweites Usenet-Verzeichnis, sondern die lokale Sicht eines Servers für eine Verbindung.

Auf Name und Wasserstände folgt der aktuelle Gruppenstatus. Typische Werte sind y für erlaubtes Posten, n für nicht erlaubtes Posten und m für Weiterleitung an den Moderator. Einen unbekannten Wert soll der Client als fehlende Information behandeln.

Entscheidend ist die anschließende Begrenzung: Der Status sagt nur, wie Beiträge normalerweise verarbeitet werden, und ist nicht zwingend auf den konkreten Client zugeschnitten. Ein Verbot gilt auch in y; ein Sonderrecht kann eine Ausnahme in n eröffnen.

Das Wort „normalerweise“ ist keine Ausrede, sondern ein Datentyp. Es macht die Zeile zu einer Beschreibung der Grundroute, ohne Konten, Quellnetze, Transportschutz und administrative Ausnahmen in denselben Buchstaben zu pressen.

Die eigentliche Einreichung hatte zwei Ergebnisse

Nach RFC 3977 liefert POST vor dem Artikeltext 340 oder 440. Nach vollständiger Übertragung folgen 240 oder 441. Eine frühe Ablehnung verhindert, dass ein Entwurf überhaupt zum Server gelangt; eine späte Ablehnung geschieht nach Offenlegung des Inhalts.

Auch 240 beweist nicht, dass Leser den Artikel sofort abrufen können. Moderation, weitere Verarbeitung oder Übertragung können ausstehen. Sichtbarkeit braucht einen eigenen Nachweis.

Eine einzelne Anzeige „Posten möglich“ vermischt damit Gruppenregel, Sitzungsrecht, Annahme und Leserzugriff. Für Betrieb, Datenschutz und Ursachenanalyse müssen diese Entscheidungen einzeln aufgezeichnet werden.

Ein anerkannter Name war kein Generalschlüssel

RFC 4643 verwendet 480, wenn ein Client für einen Befehl oder eine Ressource authentisiert und/oder autorisiert werden muss. Nach erfolgreichem AUTHINFO können sich die angebotenen Fähigkeiten ändern, weil die Sitzung nun einen bekannten Principal darstellt.

Trotzdem darf der Server einige oder alle Ressourcen mit 502 verweigern. Authentisierung stellt eine Identität fest; lokale Autorisierung verteilt deren Rechte.

Darum ersetzen sich LIST ACTIVE, AUTHINFO-Ergebnis und Befehlsantwort nicht gegenseitig. Ein Berechtigungs-Cache aus Gruppenname und y/n/m übersieht Benutzerwechsel, TLS-Zustand, Zielserver und Richtlinienversion. Nach jeder Sicherheits- oder Identitätsänderung muss ein Client Fähigkeiten neu lesen und eine frische Entscheidung anfordern.

m nannte einen Weg, keine legitimierte Person

m bedeutet, dass Beiträge an den Moderator weitergeleitet werden. Es authentisiert weder den Moderator noch garantiert es Zustimmung. RFC 5537 trennt Posting-, Injection-, Relay-, Serving- und Reading-Agenten sowie Moderatoren, weil jede Station andere Verantwortung trägt.

Der bereits veröffentlichte Beitrag zu Approved behandelt die Moderatorautorität. Hier zeigt m nur, dass die Liste einen Normalweg beschreibt. Einreichungsrecht beweist keine Autorschaft; Annahme beweist keine Weiterleitung; Weiterleitung beweist keine Sichtbarkeit.

Getrennte Namen hielten Zuständigkeiten auseinander

Die IANA-Registrierung der NNTP-Parameter führt LIST, POST, AUTHINFO und READER als getrennte Fähigkeiten. Sie misst keine heutige Verbreitung, schafft aber verschiedene interoperable Namen für Suche, Einreichung, Identität und Lesen.

Ein Katalog ist nützlich, weil er viel zusammenfasst. Er wird gefährlich, wenn die Zusammenfassung zur persönlichen Erlaubnis hochgestuft wird. Das grüne Licht war echt. Es beschrieb die Gruppe – nicht das Recht des Menschen davor.

Quellen