Canceln (Usenet)

Das Verb canceln (englisch 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 Request for Comments erhoben. Formvorschriften und Voraussetzungen (z. B. Breidbart-Index) werden individuell von den Hierarchien festgelegt.

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.

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.

Cancel-Watch

Cancel-Watch 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 (datiert vom November 1998) und inzwischen im RFC 8315 (Februar 2018) beschrieben und ist kaum verbreitet.

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.

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:

• Gnus
• slrn
• tin
• flnews

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.

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.

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

NoCeM-Nachrichten werden üblicherweise durch externe Programme ausgewertet. 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.

Weblinks

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

• M. Horton, R. Adams: RFC: 1036 – Standard for Interchange of USENET Messages. Dezember 1987 (löst RFC 850 ab, englisch).
• R. Allbery, C. Lindsey: RFC: 5537 – Netnews Architecture and Protocols. November 2009 (löst RFC 1036 ab, englisch).
• M. Baeuerle: RFC: 8315 – Cancel-Locks in Netnews Articles. Februar 2018 (ergänzt RFC 5537, englisch).