Canceln

Das Verb canceln (engl. cancel „annullieren“) bezeichnet im Usenet das bewusste, vorzeitige Löschen eines Artikels. Der Begriff ist mehrdeutig.

Newsreader, also die Programme, mit denen man am Usenet teilnimmt, haben im Allgemeinen eine Funktion (Menüpunkt, Schaltfläche etc.) namens „Nachricht abbrechen“, „Cancel Usenet Message“ etc., um eine Cancel-Message zu erzeugen und abzuschicken.

Newsserver verstehen unter der Funktion Cancel dagegen den reinen Löschvorgang, also die Entfernung eines Artikels aus dem Artikelspeicher des Newsservers. Die automatische Auswertung eintreffender Cancel-Messages ist eine darauf aufsetzende Funktionalität. Alternativen zu Cancel-Messages sind NoCeM und Supersede.

Cancel-Message

Eine Cancel-Message ist eine durch Software automatisch auswertbare Bitte, einen bestimmten Artikel lokal bei sich zu löschen. Sie gehört zur Gruppe der Control-Messages und unterscheidet sich von gewöhnlichen Postings durch eine Zeile im Header (wo auch Absender, Betreff, Newsgroups, Datum usw. stehen) mit folgender Syntax:

Control: cancel <899qh19zehlhsdfa@example.com>

Diese Nachricht erscheint nicht lesbar in der betreffenden Newsgroup, sondern bittet darum, den Artikel mit der Message-ID <899qh19zehlhsdfa@example.com> zu löschen. Viele Newsserver sortieren Cancel-Messages in der Pseudo-Newsgroup control oder control.cancel ein.

Es ist üblich, aber nicht notwendig, die Betreffzeile einer Cancel-Message wie folgt zu gestalten:

Subject: cmsg cancel <899qh19zehlhsdfa@example.com>

Fremdcancel

Fremdcancel ist die Übersetzung von third-party cancel.

Laut RFC 1036 darf ein Artikel nur vom Autor oder dem Administrator des Servers, auf dem der Artikel ins Usenet eingespeist wurde, gecancelt werden. Seit dem Erscheinen von RFC 1036 im Dezember 1987 hat sich die Praxis aber leicht geändert. Fremdcancel werden heute zur Entfernung von Spam toleriert. Die umfangreichen Richtlinien dafür wurden allerdings nicht in den Status eines RFC erhoben. Formvorschriften und Voraussetzungen (z. B. Breidbart-Index) werden individuell von den Hierarchien festgelegt.[1][2]

Laut dem aktuell gültigen RFC 5537 müssen die Headerfelder From und Sender nicht mehr mit dem Zielartikel übereinstimmen (Nr. 5.3). Es soll für alle Control-Messages vom Server eine Authentifizierung durchgeführt werden (Nr. 5.1). Siehe hierzu den Abschnitt „Cancel-Lock und Cancel-Key“.

Es gibt aber auch Stimmen, die jeden Fremdcancel als unzulässigen Eingriff in die Meinungsäußerung anderer Teilnehmer betrachten. So sind etwa in der Hierarchie free.* alle Cancel-Messages verboten.[3]

Gängige Newsserver erlauben, sehr flexibel nach einer ganzen Reihe verschiedener Kriterien einzustellen, welchen dieser Empfehlungen gefolgt werden soll und welchen nicht. Es gibt jedoch auch Newsserver, die zur Vermeidung von Missbrauch keinerlei Cancels erlauben.[4][5]

Cancel-Watch

Cancel-Watch[6] ist ein einfaches Verfahren, um beim Eintreffen einer Cancel-Message eine Benachrichtigung (E-Mail) an den Autor des betroffenen Postings zu schicken.

Voraussetzung ist eine Message-ID mit eindeutigem, d. h. von keinem anderen Benutzer verwendeten, Fully Qualified Domain Name. Dadurch entfällt die Notwendigkeit, eine Datenbank verwendeter Message-IDs zu führen.

Cancel-Lock und Cancel-Key

Cancel-Lock ist ein Mechanismus zur Verhinderung unbefugter Cancel und Supersedes. Es wird in draft-ietf-usefor-cancel-lock-01[7] (datiert vom November 1998) und inzwischen im RFC 8315 (Februar 2018) beschrieben und ist kaum verbreitet.[5]

Das Verfahren beruht auf der Unumkehrbarkeit einer Hash-Funktion. Im Draft wird nur Secure Hash Algorithm (SHA-1) erwähnt. Das Format von Cancel-Lock selbst ist aber nicht auf eine bestimmte Hash-Funktion beschränkt. RFC 8315 (Nrn. 6 und 8.3) sieht SHA-256 und SHA-512 vor.

Cancel-Lock lässt sich leichter implementieren als die bei anderen Control-Nachrichten (newgroup, rmgroup, checkgroups) verwendete Signatur mit PGP. Vor allem ist keine Datenbank öffentlicher Schlüssel erforderlich.[8]

Allerdings ist nicht immer gewährleistet, dass eine Cancel-Message nach der zu löschenden Nachricht eintrifft. Wenn auf einem Server ein Cancel-Bot läuft, und dieser sofort nach Erhalt eines (Spam-)Artikels eine Cancel-Message generiert, wird nur noch diese weiter verbreitet. Die ursprüngliche Nachricht kann so über Umwege (langsame Server, schlechte Verbindung, Server, die gar keine Cancel ausführen) nach der Cancel-Message eintreffen.

Ablauf

Bei Absenden eines Artikels wird ein zusammenpassendes Paar von Cancel-Lock und Cancel-Key erzeugt. Der Cancel-Lock wird mit dem Artikel veröffentlicht. Der Cancel-Key bleibt vorerst geheim.

Bei einem später eventuell notwendigen Cancel oder Supersedes wird der zum Cancel-Lock des Zielpostings passende Cancel-Key mitgeschickt. Server, die das Verfahren implementieren, löschen durch Cancel-Lock geschützte Artikel nur, wenn im Cancel oder Supersedes ein korrekter Cancel-Key vorliegt.

Nur wenige Newsreader implementieren Cancel-Lock:

Allerdings lassen sich Cancel-Lock auch von der Newsserver-Software setzen. Da das Verfahren die Möglichkeit vorsieht, bereits vorhandene Schlösser mit weiteren zu ergänzen, können Artikel so mehr als einen Cancel-Lock (bzw. mehr als einen Cancel-Key) aufweisen. Da bei der Überprüfung nur einer der Schlüssel zu einem der Schlösser passen muss, halten sich Server-Betreiber durch das automatische Einfügen die Möglichkeit des Admin-Cancel offen.

Algorithmus

Der Zusammenhang zwischen Schlüssel und Schloss ist durch den Draft bzw. im RFC 8315 (Nr. 2.1) festgelegt.

 lock = encode_base64(hash(key))

Da der Schlüssel in Cancel-Messages bzw. Supersedes eventuell veröffentlicht wird, muss jedes Posting durch ein individuelles Schloss geschützt werden. Theoretisch könnte man den Schlüssel durch einen Zufallszahlengenerator erzeugen lassen, müsste dann aber Aufzeichnungen darüber führen, zu welchem Posting welcher Schlüssel passt.

RFC 8315 empfiehlt, stattdessen das Verfahren HMAC auf Message-ID und ein Geheimnis anzuwenden. Da die Message-ID sich per Definition von Artikel zu Artikel unterscheidet, erhält man so für jedes Posting ein individuelles Schloss und muss sich trotzdem nur ein Geheimnis für alle Postings merken.

Hier ein Beispiel dazu mit dem Tool canlock aus der Bibliothek libcanlock:

$ printf '%s' 'geheimes_passwort' | canlock -a sha256 -k '<plhgpp$v8d$3@mid.news.example>'
sha256:pZMkXN9Pbl7pnPSPdKGCuwjMAb2qPAcH+EBopnKZK3Q=

$ printf '%s' 'geheimes_passwort' | canlock -a sha256 -l '<plhgpp$v8d$3@mid.news.example>'
sha256:jNxDM6sGTRiAH2AEMgzi/xwsVDM6aIrahsMCVI+fxVg=

$ canlock -c 'sha256:pZMkXN9Pbl7pnPSPdKGCuwjMAb2qPAcH+EBopnKZK3Q=','sha256:jNxDM6sGTRiAH2AEMgzi/xwsVDM6aIrahsMCVI+fxVg='
Good

Dabei ist <plhgpp$v8d$3@mid.news.example> die Message-ID des Postings, und geheimes_passwort ist das gleichbleibende Geheimnis. Der erste Befehl (mit dem Schalter -k) erzeugt den Cancel-Key und der zweite Befehl (mit dem Schalter -l) den Cancel-Lock. Verwendet man canlock mit der Option -c (check), kann man prüfen, ob Cancel-Key und Cancel-Lock zueinander passen.

Weitere Beispiele (realisiert mit OpenSSL) finden sich im Kapitel 5 von RFC 8315.

Das folgende Perl-Script generiert ein Key/Lock-Paar:

#!/usr/bin/perl -w
use Digest::SHA qw( sha256_base64 hmac_sha256_base64 );

my $secret = "geheimes_passwort";
my $message_id = '<plhgpp$v8d$3@mid.news.example>';

my $cancel_key = Digest::SHA::hmac_sha256_base64($message_id, $secret);

while (length($cancel_key) % 4) {
        $cancel_key .= '=';
}

my $cancel_lock = Digest::SHA::sha256_base64($cancel_key);

while (length($cancel_lock) % 4) {
        $cancel_lock .= '=';
}

printf "cancel secret: \"%s\"\n", $secret;
printf "Message-ID: %s\n", $message_id;

printf "Cancel-Key: sha256:%s\n", $cancel_key;
printf "Cancel-Lock: sha256:%s\n", $cancel_lock;

Ausgabe des Scripts:

$ ./erzeugen.pl 
cancel secret: "geheimes_passwort"
Message-ID: <plhgpp$v8d$3@mid.news.example>
Cancel-Key: sha256:pZMkXN9Pbl7pnPSPdKGCuwjMAb2qPAcH+EBopnKZK3Q=
Cancel-Lock: sha256:jNxDM6sGTRiAH2AEMgzi/xwsVDM6aIrahsMCVI+fxVg=

Dieses Script überprüft ein gegebenes Key/Lock-Paar:

#!/usr/bin/perl -w
use Digest::SHA qw( sha256_base64 );

my $cancel_key = 'sha256:pZMkXN9Pbl7pnPSPdKGCuwjMAb2qPAcH+EBopnKZK3Q=';
my $cancel_lock = 'sha256:jNxDM6sGTRiAH2AEMgzi/xwsVDM6aIrahsMCVI+fxVg=';

my $ck = (split (/:/, $cancel_key))[1];
my $cl = (split (/:/, $cancel_lock))[1];

my $verify = sha256_base64($ck);

while (length($verify) % 4) {
        $verify .= '=';
}

printf "Cancel-Key: %s\n", $cancel_key;
printf "Cancel-Lock: %s\n", $cancel_lock;

if ($cl eq $verify)
  { print "Cancel-Key matches Cancel-Lock.\n"; }
else
  { print "Cancel-Key does not match Cancel-Lock.\n"; }

Ausgabe:

$ ./pruefen.pl 
Cancel-Key: sha256:pZMkXN9Pbl7pnPSPdKGCuwjMAb2qPAcH+EBopnKZK3Q=
Cancel-Lock: sha256:jNxDM6sGTRiAH2AEMgzi/xwsVDM6aIrahsMCVI+fxVg=
Cancel-Key matches Cancel-Lock.

NoCeM

NoCeM ist eine kaum verbreitete Alternative zum Fremdcancel. Das Kunstwort ist der englischen Wortkombination No See 'Em nachempfunden und wird als [,nou'si:əm] ausgesprochen.[9]

NoCeM-Nachrichten sind mit asymmetrischer Verschlüsselung im Format PGP/INLINE signiert und enthalten eine Typangabe wie SPAM oder MMF. Dies erlaubt es Serverbetreibern, selektiv bestimmte Nachrichten von vertrauenswürdigen Absendern automatisch auswerten zu lassen.[10]

Im Gegensatz zu einer Cancel-Message kann eine NoCeM-Nachricht beliebig viele Zielnachrichten betreffen.[11]

NoCeM-Nachrichten werden üblicherweise durch externe Programme ausgewertet.[12] Im Gegensatz zu Cancel-Messages ist die nachträgliche oder wiederholte Auswertung daher problemlos.

Die für Fremdcancel festgelegten Konventionen wie Breidbart-Index haben für NoCeM keine Relevanz. Allerdings sorgen die Voraussetzungen (Installation der Software, Import des PGP-Schlüssels und Konfiguration der Typangabe) dafür, dass nur eine kleine Minderheit der Server NoCeM berücksichtigt.

Siehe auch

Wiktionary: canceln – Bedeutungserklärungen, Wortherkunft, Synonyme, Übersetzungen

Weblinks

  • RFC 5537 – Netnews Architecture and Protocols
  • RFC 8315 – Cancel-Locks in Netnews Articles
  • RFC 1036 – Standard for Interchange of USENET Messages (inzwischen überholt)

Fußnoten

  1. ↑ Current Spam thresholds and guidelines
  2. ↑ Fremdcancel-FAQ (Memento vom 25. Juni 2007 im Internet Archive)
  3. ↑ free.* FAQ
  4. ↑ Google Groups ignoriert eintreffende Cancel-Messages und bietet auch keine Möglichkeit zum Versenden eigener Cancel-Messages.
  5. ↑ a b Auf dem Newsserver mit dem größten Posting-Anteil in de.*, news.individual.de, werden nur Cancel-Messages und Supersedes mit korrektem Cancel-Key ausgeführt: FAQ-Eintrag
  6. ↑ Ralf Döblitz nennt seine Implementierung für INN schlicht cancelwatch
  7. ↑ http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01
  8. ↑ Cancel Lock vs. Public Key signed cancel
  9. ↑ The NoCeM FAQ (Memento des Originals vom 17. Juni 2007 im Internet Archive)  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.cm.org
  10. ↑ The NoCeM Registry
  11. ↑ In einem nicht angenommenen Entwurf aus dem Jahre 1994 (als "son of 1036" bekannt) wird die Erweiterung von Control: und Supersedes: auf beliebig viele Message-IDs vorgeschlagen.
  12. ↑ Mit INN wird perl-nocem ausgeliefert