Skip to content

INN: Cancel-Lock und Cancel-Key

Im Rahmen der notwendigen Umbaumaßnahmen und der Neueinrichtung von news.szaf.org habe ich endlich auch die Unterstützung von Cancel-Lock und Cancel-Key umgesetzt.

Cancel sind Steuernachrichten zur Löschung anderer Nachrichten im Usenet, vorgesehen zur Löschung eigener Beiträge (oder ggf. noch zur Löschung von Beiträgen durch den Newsadministrator des einspeisenden Servers). Das Protokoll sieht aber keine Verifizierung dieser Nachrichten vor; grundsätzlich kann also jeder Teilnehmer Nachrichten von jedem anderen Teilnehmer löschen, was zwar unzulässig ist und auf breite Ablehnung stößt, aber dennoch in der Vergangenheit gerne vieltausendfach genutzt wurde, nicht nur für von der Netzgemeinschaft akzeptierte Spamcancel, sondern auch für Attacken gegen bestimmte Newsgroups ("leercanceln") oder Netzteilnehmer. Die als Reaktion oft erfolgte Abschaltung der Cancel-Funktionalität war aber auch nicht der Weisheit letzter Schluß.

Daher wurden bereits Ende der Neunziger Vorschläge gemacht, wie das Canceln von Beiträgen nur für Befugte ermöglicht werden kann, nämlich durch das Hinzufügen eines kryptographischen Cancel-Locks in jedem Beitrag, zu dem eine Cancelnachricht den passenden Cancel-Key enthalten muß, wenn sie ausgeführt werden soll. Cancel-Lock und -Key sind dabei zusammengesetzt aus einem geheimen Schlüssel und der Message-ID des jeweiligen (bzw. zu cancelnden) Postings. Nachdem diese Vorschläge jedenfalls auf Client-Seite nie breite Umsetzung - außerhalb einiger unixoider Newsreader - fanden (und sich das Prinzio vermutlich deshalb auch auf Serverseite nicht durchsetzte), bekamen Cancel-Lock und -Key Ende Juni 2007 durch deren verpflichtende Einführung bei dem bedeutenden deutschen Newsserver news.individual.de neuen Auftrieb. Dort hat man nämlich nicht nur die Überprüfung von Cancel-Locks aktiviert, sondern zugleich hinsichtlich der fehlenden Unterstützung im Client zumindest für die eigenen Nutzer insoweit Abhilfe geschaffen als Cancel-Locks durch den Server (!) automatisch allen Beiträgen hinzugefügt werden (und bei berechtigten Canceln wird in gleicher Weise automatisch der passende Cancel-Key eingetragen).

Bereits kurz danach wurden in de.comm.software.newsserver - namentlich durch Alexander Bartolich - erste Implementationen sowohl zum Einfügen als auch zum Prüfen von Cancel-Lock und -Key für den INN veröffentlicht:

Grundsätzlich sind für die Überprüfung von Cancel-Lock und -Key zwei Varianten denkbar: Entweder läßt man die Cancelverarbeitung in Betrieb und filtert unerwünschte Cancel (und Supersedes!) im filter_innd aus, oder man deaktiviert die Cancel-Verarbeitung komplett und führt nur erwünschte Cancel aus filter_innd heraus aus. Letzteres ermöglicht die weitere Unterscheidung, ob man Cancel ablehnen oder zwar annehmen und weiterverbreiten, aber nicht ausführen oder annehmen und ausführen möchte. Weiterhin muß man sich entscheiden, wie man mit Postings ohne Cancel-Lock umgehen will. Für diese Postings kann man weiterhin alle Cancel akzeptieren - oder keinen. (Und man muß sich eine Lösung für Spamcancel überlegen; entweder akzeptiert man signierte Cancel aus vertrauenswürdiger Quelle, oder man implementiert zugleich NoCeM als Ergänzung.)

"INN: Cancel-Lock und Cancel-Key" vollständig lesen

Umbaumaßnahmen

Bereits gestern abend hatte ich bis heute in der Früh ;-) störungsbedingt die ersten Dienste (einen semi-öffentlichen bitlbee-Server, die Mailinglisten, den secondary MX für einige Domains) auf die neue Maschine umgezogen; heute war dann der Newsserver dran, der inzwischen auch provisorisch seinen Dienst aufgenommen hat. "Provisorisch" insofern, als er bislang seinen Feed von der alten Maschine bekommt und auch primär nach dort feedet, aber die ersten Peers haben erfreulich schnell auf meine Bitte per E-Mail reagiert und ihren Feed geschwenkt.

Diesmal bemühe ich mich überdies, die Konfiguration des INN direkt von Anfang an "sauber" aufzusetzen und zugleich die ersten Punkte auf (m)einer Liste der geplanten Änderungen und Verbesserungen umzusetzen. Auf dieser Liste finden sich Dinge wie

  • die reproduzierbar funktionsfähige Verifikation von Steuernachrichten,
  • ein aktueller Cleanfeed,
  • das automatische Setzen und das Auswerten von Cancel-Lock/Cancel-Key,
  • die Auswertung (ggf. auch Generierung) von NoCeMs,
  • das Überarbeiten des Gruppenangebots,
  • das Zuweisen von jeweils eigenen Hostnamen pro Feed, um diese ggf. gezielt schwenken zu können
  • usw. usf.

Inbesondere letzteres dürfte sich bei künftigen IP-Änderungen bewähren, weil man dann erst einmal einige Feeds auf die neue Maschine schwenken und sie dabei beobachten kann (laufen Hardware und Software stabil? ist alles richtig konfiguriert? …), und bei Bedarf auch Lastmanagement, also die Verteilung der Feeds auf verschiedenen Maschinen, ermöglichen.

Mit dem Umzug des Newsservers sollte dann die Migration von haystack, der alten Maschine, auf den Nachfolger pasture abgeschlossen sein.