- Fremdcancel
-
Inhaltsverzeichnis
Das Verb canceln (aus dem Englischen to cancel = annullieren) bezeichnet im Usenet das bewusste, vorzeitige Löschen eines Artikels. Der Begriff ist leicht 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@foo.bar.com>
Diese Nachricht erscheint nicht lesbar in der betreffenden Newsgroup, sondern bittet darum, den Artikel mit der Message-ID
<899qh19zehlhsdfa@foo.bar.com>
zu löschen. Viele Newsserver sortieren Cancel-Messages in der Pseudo-Newsgroupcontrol
odercontrol.cancel
ein.Es ist üblich, aber nicht notwendig, die Betreffzeile einer Cancel-Message wie folgt zu gestalten:
Subject: cmsg cancel <899qh19zehlhsdfa@foo.bar.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]
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]Im deutschen Sprachraum wird diese Diskussion über Meinungsfreiheit noch durch die Eigenheit des Wortes Fremdcancel erschwert, da es eine Dualität mit Eigencancel nahelegt. Das in RFC-1036 vorgesehene Recht des Administrators zum Admincancel wird dabei dem Sprachgefühl folgend als Untermenge von Fremdcancel betrachtet. Tatsächlich spricht der Originalbegriff third-party cancel aber von der dritten Art des Cancelns.
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 anderem Benutzer verwendeten, Fully Qualified Domain Name. Dadurch entfällt die Notwendigkeit, eine Datenbank verwendeter Message-IDs zu führen.
Cancel-Lock & Cancel-Key
Cancel-Lock ist ein Mechanismus zur Verhinderung unbefugter Cancel und Supersedes. Es wird in draft-ietf-usefor-cancel-lock-01[7] (datiert November 1998) beschrieben und ist kaum verbreitet.[5]
Das Verfahren beruht auf der Unumkehrbarkeit einer Hash-Funktion. Im Draft wird nur Secure Hash Algorithm erwähnt. Das Format von Cancel-Lock selbst ist aber nicht auf eine bestimmte Hash-Funktion beschränkt.
Cancel-Lock lässt sich leichter implementieren als die bei anderen Control-Nachrichten (
newgroup
,rmgroup
,checkgroups
) verwendete Verschlüsselung 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 festgelegt.
lock = encode_base64(sha1(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.
Der Draft empfiehlt, statt dessen das Verfahren HMAC auf Message-ID und ein Geheimnis anzuwenden. Da die Message-ID sich per Definition unterscheidet, erhält man so für jedes Posting ein individuelles Schloss und muss sich trotzdem nur ein Geheimnis für alle Postings merken.
Das folgende Perl-Programm generiert ein Key/Lock-Paar analog der auf der Bibliothek canlock basierenden Implementierung von slrn. Die Variable
$secret
entspricht dabei dem Inhalt der durchcansecret_file
angegebenen Datei.#!/usr/bin/perl -w use MIME::Base64(); use Digest::SHA1(); use Digest::HMAC_SHA1(); my $secret = "geheimes passwort\n"; my $message_id = '<899qh19zehlhsdfa@foo.bar.com>'; my $digest = Digest::HMAC_SHA1::hmac_sha1($message_id, $secret); my $cancel_key = MIME::Base64::encode($digest, ''); my $cancel_lock = MIME::Base64::encode(Digest::SHA1::sha1($cancel_key, '')); printf "Cancel-Key: sha1:%s\n", $cancel_key; printf "Cancel-Lock: sha1:%s\n", $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.
Fußnoten
- ↑ Current Spam thresholds and guidelines
- ↑ Fremdcancel-FAQ
- ↑ free.* FAQ
- ↑ Google Groups ignoriert eintreffende Cancel-Messages und bietet auch keine Möglichkeit zum versenden eigener Cancel-Messages.
- ↑ a b Auf dem Newsserver mit dem größten Posting-Anteil in de.*, news.individual.net, werden nur Cancel-Messages und Supersedes mit korrektem Cancel-Key ausgeführt: FAQ-Eintrag
- ↑ Ralf Döblitz nennt seine Implementierung für INN schlicht cancelwatch
- ↑ http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01
- ↑ Cancel Lock vs. Public Key signed cancel
- ↑ The NoCeM FAQ
- ↑ The NoCeM Registry
- ↑ 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.
- ↑ Mit INN wird perl-nocem ausgeliefert
Wikimedia Foundation.