🚀 go-pugleaf

                             FREMDCANCELN
                             ~~~~~~~~~~~~


Vorbemerkung
~~~~~~~~~~~~

Fremdcancel sind, es sei denn, sie erfolgen durch den lokalen
News-Administrator, nach derzeitigem Stand der Dinge nicht RFC-konform;
gegen diese Regel wird schon seit geraumer Zeit im Falle von `Spam'
sowie durch Gateways erzeugten Duplikaten von Artikeln mit weitgehendem
Einverständnis der Netzgemeinschaft verstoßen.  

In der jüngeren Vergangenheit haben einige Netzbewohner innerhalb der
`de.all'-Hierarchie auch aus inhaltlichen Gründen zum Instrument des
Fremdcancels gegriffen; daher möchte ich versuchen, in diesem `FAQ'
Bedingungen aufzuzählen, unter denen Fremdcancel von der
Netzgemeinschaft normalerweise getragen werden - und klarzustellen, wann
man auch im eigenen Interesse auf keinen Fall fremdcanceln sollte.


Wann ist ein Fremdcancel angebracht?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Die zum Thema `Cancel' derzeitig gültige Regel ist im RFC 1036 zu
finden, in dem es heißt:

    Only the author of the message or the local news administrator is
    allowed to send this message.  The verified sender of a message is the
    "Sender" line, or if no "Sender" line is present, the "From" line.
    The verified sender of the cancel message must be the same as either
    the "Sender" or "From" field of the original message.  A verified
    sender in the cancel message is allowed to match an unverified "From"
    in the original message.

Streng nach den Buchstaben RFC sind Fremdcancel also nicht erlaubt.  Es
gibt jedoch einige Fälle, in denen es einen Konsens der Netzgemeinschaft
zu geben scheint, was Fremdcancel angeht.

1. Spam/Velveeta - Wird ein Artikel gleichlautend in übermäßig viele
   Newsgroups gepostet oder gecrosspostet, so ist dies kein Beitrag zur
   Diskussion im Netz, sondern eine Belästigung der Teilnehmer.  Als
   Kriterium ist der sogenannte Breidbart-Index (BI) gebräuchlich.
   Dieser ist definiert als die Summe der Quadratwurzeln der Anzahl an
   Newsgruppen, in die die Inkarnation des Artikels gepostet wurde, kurz
   (in Pseudo-TeX):

   BI = sum_{Inkarnationen} sqrt{Anzahl an Newsgroups}.

   Liegt der Breidbart-Index für die Inkarnationen in der de-Hierarchie
   bei ungefähr 10, so kann man davon ausgehen, daß die Toleranzschwelle
   überschritten ist.  Ein Fremdcancel erscheint in diesem Fall tragbar,
   wenn nicht notwendig.  Das gleiche gilt natürlich, wenn der
   entsprechende Artikel bereits in den großen internationalen
   Hierarchien (comp, misc, rec, talk, news, sci, humanities, soc) die
   dortige Toleranzschwelle überschritten hat.  Die magische Zahl für
   den Breidbart-Index scheint dort irgendwo in der Nähe von 20 zu
   liegen (vgl. das news.admin.net-abuse.announce-FAQ).

2. Duplikate von Gateways - Wird ein Artikel durch nicht funktionierende
   Gateways zu Usenet-fremden `Netzen' oder defekte Usenet-Software in
   mehreren Inkarnationen ins Netz gepostet, ist dies ebenfalls eine
   Belästigung der Netzteilnehmer; ein Fremdcancel wird von der
   Netzgemeinschaft mitgetragen werden.  Der Administrator der
   verursachenden Site sollte per Mail über die Tatsache der
   Duplikatentstehung und die dagegen getroffenen Maßnahmen informiert
   werden, damit weiterer Schaden abgewendet werden kann.

3. Fälschungen - Eine Fälschung darf auch nach RFC 1036 von dem
   vorgeblichen Autor des Artikels oder seinem News-Administrator
   gecancelt werden, da es sich formal ja nicht um einen Fremdcancel
   handelt.  Ist die Fälschung offensichtlich und ein Schaden für den
   vorgeblichen Autor zu befürchten, so wird auch ein Cancel durch
   Dritte im Normalfall toleriert werden.

Kein Konsens besteht im Falle von Artikeln, in denen der Autor
absichtlich unkenntlich gemacht wurde und die nicht per EMail
beantwortbar sind.  Diese sind selbst regelwidrig.  Da keine Möglichkeit
besteht, den Autor des Artikels zu einer Rücknahme dieser
Regelwidrigkeit zu bewegen, wird ein Fremdcancel unter Umständen
hingenommen, man sollte jedoch mit größter Vorsicht vorgehen.  NB:
Artikel, die über anonyme Remailer gepostet werden, erfüllen die oben
genannten Bedingungen nicht, da eine Antwort per Mail möglich ist.

Ausnehmend empfindlich reagiert die Netzgemeinschaft auf das Canceln von
Artikeln anderer aus inhaltlichen Gründen.  Im Falle von Falschaussagen
oder Beleidigungen ist eine Erwiderung durch den Betroffenen in einem
Follow-Up vermutlich die richtige Reaktion - ein Cancel wirkt hier
kontraproduktiv und rückt das ursprüngliche `Opfer' in eine
`Täter'-Rolle.  Man sollte sich in solchen Fällen immer überlegen, ob es
nicht am besten ist, den betreffenden Artikel schlicht zu ignorieren und
seinen Autor ins Kill-File aufzunehmen.


Wer cancelt wie?
~~~~~~~~~~~~~~~~

Wie bereits gesagt, sind Fremdcancel im Prinzip niemandem erlaubt.  In
den oben genannten Fällen, in denen ein solcher `Regelverstoß' im
de-Usenet üblicherweise toleriert wird, sollte er durch erfahrene
News-Administratoren erfolgen, da diese wohl am ehesten über die
technische Versiertheit und hoffentlich auch die soziale Kompetenz
verfügen dürften, die nötig sind, wenn größere Reibungsverluste
vermieden werden sollen.  

Grundsätzlich soll jeder Fremdcancel eine kurze, eindeutige und
individuelle Begründung enthalten - nach Möglichkeit in englischer
Sprache; wenn nötig, kann eine umfangreichere Erläuterung nach
de.admin.news.misc gepostet werden.  Fremdcancel, die keine solche
Begründung enthalten, sind eine gute Möglichkeit, sich den Ärger der
Netzgemeinde zuzuziehen.  Eine relativ sichere Methode, sich Flames
einzuhandeln, sind auch Begründungen wie `RFC-Laesterung' beim Canceln
von Duplikaten.

Der gecancelte Artikel und die Cancel-Mitteilung sollten archiviert
werden (sofern dies sinnvoll und praktikabel ist - postet ein Anwender
zum Beispiel `versehentlich' ein komplettes X11, macht es sicherlich
keinen Sinn, jeden so zustandegekommenen Artikel abzuspeichern), damit
eine spätere Klärung des Vorgangs möglich ist.  Die Message-ID einer
Cancel-Message für einen Artikel <xyz@foo.bar.baz> sollte normalerweise
<cancel.xyz@foo.bar.baz> lauten; dadurch wird erreicht, daß im Falle
mehrerer Fremdcancel eines Artikels nur derjenige, welcher als erster
ankommt, von einer Usenet-Site angenommen wird.  Auf diesem Wege wird
die zusätzliche Netzlast, die durch Cancels entstehen kann, minimiert.
Der Fremdcancel sieht dann letztlich so aus wie ein einziger Artikel,
der sehr schnell und sehr weitgehend verbreitet wird.

In der letzten Zeit hat es allerdings mindestens einen Spam gegeben, bei
dem leere `Deckartikel' mit genau dieser Message-ID (und einigen
weiteren ähnlichen IDs wie cancel.cancel....) gepostet wurden, um ein
Canceln des Spams zu erschweren.  In diesem Fall ist die Konvention
leider hinfällig.  Es macht Sinn, in solchen Fällen ganz normale
Message-IDs des eigenen Systems zu verwenden.

Um es Sites, die dies wünschen, zu ermöglichen, keine Fremdcancel
auszuführen, soll der letzte Eintrag im Path eines Fremdcancels einer
Pseudo-Site `cyberspam' entsprechen.

Da in einem Fremdcancel technisch bedingt die Header `From' und/oder
`Sender' gefälscht werden müssen (auch wenn mindestens ein verbreitetes
News-System dies nicht überprüft), ist der Verantwortliche nicht klar
ersichtlich.  Daher sollte ein Fremdcancel in einem zusätzlichen
`X-Cancelled-By:'-Header den realen Absender angeben.

Beispiel für einen gecancelten `Dupe':

| Control: cancel <uzs198.134.0022b71f@uni-bonn.de>
| Newsgroups: de.soc.recht,de.admin.news.misc
| Path: ...!rhein!sobolev!cyberspam!usenet
| From: uzs198@uni-bonn.de (nik wiesel)
| Subject: cmsg cancel <uzs198.134.0022b71f@uni-bonn.de>
| X-Orig-Subject: Subject: re: wichtige information
| Sender: uzs198@uni-bonn.de (nik wiesel)
| X-Cancelled-By: roessler@sobolev.rhein.de
| Message-ID: <cancel.uzs198.134.0022b71f@uni-bonn.de>
| Date: Thu, 20 Jul 1995 09:27:09 GMT
| 
| Dupe from blues.kk.sub.org cancelled.  See <DC08CD.FIn@sobolev.rhein.de>
| in de.admin.news.misc.
| 
| Thomas Roessler <roessler@sobolev.rhein.de>



Kann man die Ausführung von Cancel-Messages kontrollieren?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Für die News-Systeme CNews und INN existieren Patches, die eine
Kontrolle über die Ausführung von Cancel-Messages erlauben.  Diese sind
für CNews bei Ullrich von Bassewitz <uz@ibb.schwaben.com> bzw. Thomas
Roessler <roessler@sobolev.rhein.de> zu erhalten; für INN hat Lutz
Donnerhacke <lutz@jena.thur.de> entsprechende Änderungen geschrieben,
die sich derzeit (Mitte Juli 1995) im Alpha-Test befinden.


Credits
~~~~~~~

Herzlicher Dank geht an all jene, die mit ihren Kommentaren dazu
beigetragen haben, daß dieser Text einigermaßen sinnvoll geraten ist:
Michael Albinus, Ullrich von Bassewitz, Lutz Donnerhacke, Peter G.
Bouillon, Vera Heinau, Andreas M. Kirchwitz, Ulf Möller, Boris Piwinger,
Heiko Schlichting, Frank Tegtmeyer und andere mehr.  

-- 
Thomas Roessler <roessler@sobolev.rhein.de>