Folgende FAQ wird regelmäßig, i.e. derzeit um den 21. jeden Monats herum in die Newsgroups at.usenet.missbrauch, de.answers und news.answers gepostet.

Summary: This text concerns Usenet Spam - and the cancelling thereof - in the Usenet hierarchy at.*. Don't worry if you don't speak German, but note that in that case you probably should refrain from posting to at.* anyway.

Archive-name: usenet/spam-cancel-in-at
URL: http://www.pfeifer.com/gerald/spam/

Spam Cancel in at.* (FAQ)

Version: 1.16
Autor: Gerald Pfeifer <gerald@pfeifer.com>

EMP und ECP: Spam

Wird eine -- im Wesentlichen unveränderte -- Nachricht mehrmals jeweils als eigenes Posting abgesetzt (egal ob in unterschiedliche Gruppen oder auch nur in eine einzige), so wird die Summe all dieser Postings als EMP (excessive multiple posting, meist einfach Spam) bezeichnet. multiple posting, meist einfach Spam) bezeichnet.

Gelangt hingegen ein Nachricht durch Crossposten in eine "große" Anzahl von Gruppen, so spricht man von ECP (excessive cross-posting, Velveeta).

Allgemein hat es sich eingebürgert, sowohl EMP als auch ECP, als auch eine Kombination dieser beiden einfach als SPAM zu bezeichnen. (Man beachte, daß Spam also ein rein technisches und kein inhaltliches Kriterium darstellt.)

Problematik

Bei Spam geht es nur z.T. um Ressourcen im Sinne von Bandbreite und Plattenplatz. Es geht vor allem um die Erhaltung des Usenets als Platz, gezielt Informationen auszutauschen.
Otmar Lendl <lendl@cosy.sbg.ac.at>

das eine ist, überhaupt einen newsserver betreiben zu können angesichts der volums-explosion. das andere ist, die news auch _verwenden_ zu können -- und bei der beschränkten zeit, die ich zum lesen habe, will ich mir nicht auch noch die laune von [SPAM] verderben lassen..."
Christian Mock <cm@kukuruz.ping.at>

Undifferenziertes Posten einer Nachricht in viele Newsgroups widerspricht den Konventionen des Usenets, da es 1. Ressourcen vergeudet 2. die Leser durch Wiederholungen irritiert 3. die Einteilung in Gruppen nach Themen ignoriert. Damit das Usenet nicht in Spam (und Antworten darauf) ertrinkt, werden diese Nachrichten zum Canceln freigegeben."
Otmar Lendl <lendl@cosy.sbg.ac.at>

Canceln

Es herrscht ein weitgehender Konsens darüber, daß Spams einen Mißbrauch des Mediums Usenet darstellen und als solcher mit geeigneten Mitteln gegen sie vorgegangen werden soll. Eines dieser Mittel ist nun das Canceln, sprich Löschen, von ebensolchen Postings.

Jeder Autor bzw. sein Systemadministrator hat natürlich das Recht dies jederzeit selbst durchzuführen. Das Canceln von dritter Seite, meist Fremdcanceln genannt, ist erfahrungsgemäß umstritten. Daher wurden für die Newshierarchie at.* in der zuständigen Gruppe at.usenet eigene Richtlinien diskutiert und festgelegt.

Wann?

Um zu objektiven Kriterien zu gelangen, erweist es sich als erforderlich, die Festlegung "groß" in den obigen Definitionen mathematisch zu präzisieren:

In der at.* Hierarchie wird eine Menge von -- im wesentlichen unveränderten -- Postings in diesem Kontext qualifizierter Spam genannt, wenn der Cancel-Index dieser Menge in sämtlichen Gruppen innerhalb eines 45-Tage-Fensters die Schranke 11 überschreitet.

Für die Sub-Hierarchie at.anzeigen.* wurde in einer Abstimmung im Oktober 1999 eine strengere Regelung beschlossen; hier liegt die Schranke für den Cancel-Index bei 4 innerhalb eines 14-Tage Fensters.

(Dieses Limit ist bereits mit dem Posten eines Artikels in eine at.anzeigen.* Gruppe erreicht. Daher ist es frühestens nach Ablauf von 14 Tagen möglich, einen Artikel erneut zu posten.)

Der Cancel-Index eines einzelnen Postings berechnet sich als 3 plus Anzahl der Gruppen, an die dieses Posting geschickt wurde. Der Index mehrerer Postings ist die Summe der Indices der einzelnen Postings.

Anmerkungen 1: "im wesentlichen unverändert" stellt natürlich keine Definition im logischen Sinn dar. Eine solche zu formulieren ist aber -- unter anderem der Meinung des Autors nach, der für die Widerlegung den Preis eines Abendessens aussetzt -- unmöglich. Für weitere Hinweise dazu sei auf [Lewi] verwiesen.

Anmerkung 2: Das längere Fenster hat sich eingebürgert, um auch "schleichenden" Spam, der sich über Wochen verteilt, erfassen zu können. Beim Posten von regelmäßigen Nachrichten wie FAQs und Preislisten sollte jedenfalls "Supersedes:" verwendet werden, wodurch das neue Posting das alte ersetzt.

Wie?

Sämtliche Teile eines qualifizierten Spams sind in der Newshierarchie at.* zum Canceln freigegeben, sofern auch

  1. die entsprechenden Konventionen ($alz convention, "X-Cancelled-By:" Header und Pseudo-Site cyberspam!usenet im "Path:") eingehalten werden;
  2. eine Liste der Message-IDs aller gecancelter Postings sowie eine Kopie sämtlicher Header zumindest eines dieser Postings mit einer kurzen Erklärung nach at.usenet.cancel-reports gepostet wird -- Das Subject dieses Postings sollte den Präfix "Spam cancelled" tragen;
  3. der Urheber des Spams, sofern aus den "From:" oder "Sender:" Headern erkennbar, darüber informiert wird.

Achtung: Freigegeben sind nur Postings, in deren "Newsgroup:" Header zumindest eine at.* Gruppe aufscheint. Bei ECP nehmen wir dabei in Kauf, daß damit fallweise auch in nicht at.* Gruppen gecancelt wird.

Bei Crosspostings in moderierte Gruppen werden derlei Cancels üblicher- weise nur durch die Moderatoren oder in Absprache mit ihnen durchgeführt.

Zusätzlich zu den at.*-spezifischen Regelungen dieser FAQ behalten auch die allgemeinen Usenet Regelungen (siehe [Lewi]) ihre Gültigkeit.

Weiterführende Literatur

[Heng]
"FAQ: The Newsgroup Care Cancel Cookbook", Rosalind Hengeveld
http://rosalind.home.xs4all.nl/faq-care.html
[Kirc]
"Warum soll ich mich an die Regeln halten?", Uwe Tetzlaff
http://www.kirchwitz.de/~amk/dni/warum-regeln
[Lewi]
"FAQ: Current Usenet spam thresholds and guidelines", Chris Lewis and Tim Skirvin
http://wiki.killfile.org/projects/usenet/faqs/spam/
[Skir]
"Cancel Messages: Frequently Asked Questions", Tim Skirvin
http://wiki.killfile.org/projects/usenet/faqs/cancel/
[SoFa]
"Net Abuse FAQ", Scott Southwick
http://www.faqs.org/faqs/net-abuse-faq/part1/

Gerald Pfeifer (gerald@pfeifer.com)
Last modified Thu Oct 9 18:45:18 2014.