Zusammenfassung

  • Approved nennt Personen oder Stellen, die einen Netnews-Artikel zur Veröffentlichung freigegeben haben. Es ersetzt nicht den Autor und beweist nicht, dass der Inhaber der genannten Mailbox das Feld gesetzt hat.
  • Sobald ein Proto-Artikel eine moderierte Gruppe ohne Approved nennt, muss der Injecting Agent das ganze Objekt an den Moderator der ersten moderierten Gruppe weiterleiten oder ablehnen. Der offene Teil wird nicht vorab veröffentlicht.
  • Bei mehreren moderierten Gruppen kann die Zustimmung durch mehrere Hände gehen. Der letzte Moderator fügt das Feld hinzu und verantwortet alle erforderlichen Freigaben; die Echtheit seines Rückkanals prüft der Injecting Agent außerhalb des Artikels.

Auch die offene Gruppe musste warten

Ein Autor adressiert denselben Proto-Artikel an eine offene Technikgruppe und zwei moderierte Gruppen. Approved fehlt. Obwohl ein Ziel Direktbeiträge zulässt, erzeugt das System dort keine vorgezogene öffentliche Kopie.

Der Injecting Agent hält den Artikel als Ganzes zurück und sendet ihn an den Moderator der am weitesten links stehenden moderierten Gruppe in Newsgroups. Ist das nicht möglich, lehnt er ab. Noch hat keine der drei Gruppen einen injizierten Artikel erhalten.

Der erste Moderator kann zustimmen und dasselbe Objekt an den zweiten weitergeben. Sobald alle Freigaben vorliegen, ergänzt der letzte Verantwortliche Approved und gibt den Artikel zur Injektion zurück. Erst dann erreicht eine Veröffentlichung alle Ziele.

Die gemeinsame Verzögerung verhindert, dass ein Inhalt bereits öffentlich wird, obwohl ein Teil der adressierten Gemeinschaften ihm noch nicht zugestimmt hat.

Die Moderator-Adresse löschte den Autor nicht

RFC 1036 verlangte Approved für jede Nachricht in einer moderierten Newsgroup. Der Moderator sollte die eigene Mailadresse eintragen. Auch bestimmte Control Messages benötigten das Feld.

Der ursprüngliche From blieb erhalten. Die zusätzliche Adresse ordnete eine andere Entscheidung zu: nicht die Urheberschaft am Text, sondern die Erlaubnis für einen redaktionell verwalteten Veröffentlichungsraum.

Ein glaubwürdiger Autor erhielt dadurch noch kein Direktpublikationsrecht. Ein Moderator, der zustimmte, wurde nicht zum Autor. Zwei Verantwortlichkeiten blieben nebeneinander sichtbar.

m beschrieb den normalen Serverweg

RFC 3977 definiert LIST ACTIVE. Im lokalen Status bedeutet y gewöhnlich, dass Posting erlaubt ist, n, dass es nicht erlaubt ist, und m, dass Beiträge an den Moderator weitergeleitet werden.

Der Wert ist nicht zwingend auf den aktuellen Client zugeschnitten. y hebt ein individuelles Verbot nicht auf; ein besonders privilegierter Client kann selbst bei n anders behandelt werden.

m zeigt daher den üblichen institutionellen Ablauf, kein persönliches Recht. Es nennt weder Moderator noch Authentifizierung und entscheidet keinen konkreten Beitrag.

Approved transportierte deklarierte Zuständigkeiten

RFC 5536 definiert den Inhalt als mailbox-list. Die Adressen und möglicherweise vollständigen Namen geben Personen oder Stellen an, die die Veröffentlichung genehmigt haben. Hauptanwendungen sind moderierte Artikel und Group Control Messages.

Mehrere Mailboxen können mehrere redaktionelle Zuständigkeiten eines Crossposts abbilden. Die Grammatik beantwortet dennoch nur, wen der Artikel als genehmigende Instanz behauptet. Sie beweist nicht Existenz oder Besitz der Mailbox, tatsächliche Prüfung, heutige Moderatorrolle oder Vertrauen eines Servers.

Eine wohlgeformte Liste ist portable Zuordnung, keine kryptografische Beglaubigung.

Identität entstand vor öffentlicher Injektion

RFC 5537 baut die Weiterleitung in den Injektionsablauf ein. Fehlt Approved, ergänzt der Agent bei Bedarf Message-ID und Date, übergibt den Proto-Artikel aber vor den normalen Injektions- und Trace-Feldern.

Das Objekt besitzt damit genug Identität für seine Prüfungsreise, ohne schon wie injizierte News auszusehen. Es kann als application/news-transmission gekapselt, als Mail mit Netnews-Headern oder über einen Speicher übertragen werden, der den Proto-Artikel ohne Injektion bewahrt.

Die linke moderierte Gruppe liefert einen eindeutigen Startpunkt. Ihr Moderator wird dadurch nicht zum Vertreter aller übrigen.

Der letzte Moderator trug die Gesamtverantwortung

Bleiben moderierte Ziele ohne Freigabe, können Verantwortliche sich abstimmen oder den Proto-Artikel mit einem Zwischenhinweis weiterreichen. Wenn alle Zustimmungen vorhanden sind, fügt ein Moderator Approved hinzu, nennt sich selbst und nach Möglichkeit die weiteren Genehmigenden.

Wer diesen Schritt ausführt, übernimmt die Verantwortung dafür, dass alle moderierten Gruppen im Artikel zugestimmt haben. Das Feld ist die verdichtete Schlussfolgerung der Kette, nicht ihr vollständiges Protokoll.

Es zeigt weder Kriterien noch Gespräche, Änderungen oder geprüfte Belege. Moderatoren dürfen Header und Text ändern, sollten Änderungen jedoch klein halten, weil Signaturen des Autors oder früherer Moderatoren ungültig werden können. Freigabemacht bleibt von Autorschaft getrennt.

Die Fälschung konnte formal fehlerfrei sein

RFC 5537 warnt ausdrücklich: Ein böswilliger Poster kann Approved selbst einfügen, um Moderation zu umgehen. Eine fremde Adresse lässt sich syntaktisch korrekt schreiben.

Der Injecting Agent sollte deshalb verifizieren, dass der freigegebene Artikel vom Moderator injiziert wird. Der Nachweis stammt aus der Authentifizierung des zugrunde liegenden Transports oder einer anderen vereinbarten Methode. Die RFC stellte fest, dass es keine standardisierte Methode zur Authentifizierung moderierter Freigaben gab.

Zwei Ebenen ergänzen sich. Im Artikel reist „diese Instanz wird als Genehmigende genannt“. An der lokalen Grenze gilt „dieses Objekt kam tatsächlich über ihren autorisierten Kanal zurück“. Ohne zweite Ebene ist die Zuordnung herstellbar; ohne erste geht sie für nachfolgende Relays verloren.

IANA registrierte das Feld, nicht die Vertrauensbeziehung

Die IANA Message Headers Registry führt Approved als Standard-Netnews-Feld mit Verweis auf RFC 5536. Implementierungen teilen Namen und Definition.

Das Register ernennt keine Moderatoren, prüft keine Mailbox und zwingt keinen Server zur Anerkennung. Die Quellen belegen auch keine heutige Providerpraxis. Die Aussage kann global reisen; Vertrauen bleibt lokal verwaltet.

Redaktionelle Befugnis reiste, ohne den Text zu besitzen

Approved löste die Frage, wie eine Moderationsentscheidung samt Zuordnung durch ein verteiltes Netz weitergegeben werden kann, ohne den Autor zu überschreiben. Eine Mailbox-Liste genügte für die portable Behauptung.

Für ihre Absicherung genügte sie nicht. Sicherheit lag in der Beziehung zwischen Injecting Agent und Moderator und im authentifizierten Rückkanal. Das Feld öffnete das Tor nur, weil die lokale Grenze bereits festgelegt hatte, wem sie glaubt.

Genehmigung ist keine Autorschaft, und lesbare Identität ist keine authentifizierte Identität. Der Autor schreibt, der Moderator erlaubt das Ziel, und der Injecting Agent bewertet die behauptete Autorität.