TIN/Usenet die Zwote

Nachdem ich im letzten Artikel eine Einfuehrung gegeben habe, geht's jetzt an's Eingemachte. Allerdings soll es nicht nur um technische Dinge und tin-Details gehen, sondern auch rund um's Usenet.

Gewalt im CyberSpace: Kill-files

Wer sich seit dem letzten Artikel bereits etwas durch die verschiedenen Usenet-Gruppen gewuehlt hat, ist sicherlich auch schon auf weniger erfreuliche Zeitgenossen gestossen. Sei es, weil sie den eigenen Lieblingscomputer nicht moegen, weil sie taeglich eine unueberschaubare Menge von nutzlosen Artikeln verbreiten, oder weil man sie aus sonst einem Grund nicht mag. Dagegen gibt es eine einfache Abhilfe: Das sogenannte Kill-File. In ihm stehen Patterns und Adressen, die tin dazu veranlassen, Artikel, die im Titel diese Pattern enthalten oder von diesen Adressen abgeschickt wurden, erst gar nicht mehr anzuzeigen. Man macht von dieser Moeglichkeit Gebrauch, indem man beim Lesen eines Artikels '^k' (control-k) eingibt. Im dann erscheinenden Menu kann man verschiedene Dinge genauer festlegen. Mit dem "Kill type" gibt man an, ob man die gematchten Artikel killen (oder humaner: ignorieren) oder gerade das Gegenteil (Artikel automatisch mit einem '*' versehen) moechte. Die zweite Moeglichkeit erlaubt es einem, besonders wichtige Artikel leichter zu finden (vorausgesetzt, man kennt den Absender oder einen Teil des Titels, wie zum Beispiel "ANNOUNCEMENT"). Der Rest des Menus sollte fuer fortgeschrittene tin-Benutzer eigentlich gut verstaendlich sein.

Im File ~/.tin/tinrc laesst sich mit dem Parameter "kill_level" zusaetzlich festlegen, ob einem tin gekillte Artikel ganz vorenthalten soll, oder ob er sie nur als bereits gelesen markiert.

Gegen ganz besonders aufdringliche Missbraucher des Usenet wird mittlerweile bereits systematisch vorgegangen, sodass man sich kaum mehr um sie zu kuemmern braucht. Doch dazu spaeter mehr.

Kommando zurueck: Cancel

Manchmal passiert es einem, dass man einen Fehler in einem selbstgeschriebenen Artikel erst nach dem Abschicken bemerkt (es ist wie mit der Software: Die schlimmsten Bugs werden erst nachdem der Verkauf bereits begonnen hat entdeckt). Kein Grund zur Panik, dies laesst sich auch noch nachtraeglich rueckgaengig machen. Doch auch hier gilt: Je schneller, desto besser. Das Loeschen geschieht naemlich in Form eines speziellen Control-Artikels, der jedem Newsserver, den er passiert, andeutet, dass der gecancelte Artikel nicht weiterverbreitet und insbesondere auch lokal geloescht werden soll. Dies geht natuerlich am besten, wenn der Artikel den lokalen Newsserver noch gar nicht verlassen hat. Aber auch wenn er bereits um die ganze Welt gegangen ist, laesst er sich auf diese Art wieder diskret zum verschwinden bringen. In tin macht man dies durch die Eingabe eines 'D' beim Lesen des fehlerhaften (selbstgeschriebenen!) Artikels.

News mit Mass: Moderierte Gruppen

Es gibt einige Gruppen, in denen nur bestimmte Dinge geschrieben werden sollen. In vielen comp.sys.*-Hierarchien zum Beispiel existieren *.announce-Gruppen, in denen nur wichtige Ankuendigungen erscheinen sollen, oder es gibt Witz-Gruppen, die keine schmutzigen Witze erwuenscht sind (natuerlich gibt es auch das Gegenteil...). Um dies sicherzustellen, sind diese Gruppen moderiert. Dies geht so vor sich, dass abzuschickende Artikel nicht an den Newsserver gehen, sondern direkt an den oder die Moderator(en) gemailt werden und nach einer Kontrolle des Inhalts durch diese in's Netz abgeschickt werden. Ist eine Gruppe moderiert, weist einem tin vor dem schreiben eines Artikels darauf hin und fragt, ob man trotzdem weitermachen moechte. In moderierten Gruppen werden vom Moderator meist alle ein bis zwei Wochen die gueltigen Regeln der Gruppe verschickt.

Spams

Auf genau diese Art wird uebrigens auch gegen sogenannte spams vorgegangen. Spams sind Artikel, die wiederholt in Newsgroups verschickt werden, wo sie nicht hingehoeren. Das Standardbeispiel eines Spams sind die "MAKE MONEY FAST"-Kettenbriefe, die zum Teil in allen erreichbaren Usenet-Gruppen verschickt wurden und entsprechende Proteste ausgeloest haben. Mittlerweile gibt es Leute und auch bereits Programme (Cancelbots), die solche missbraeuchlichen Artikel suchen (die Programme erkennen sie zum Teil automatisch) und canceln, sodass wir sie haeufig erst gar nicht mehr zu Gesicht bekommen.

Die aeusserst negativen Folgen eines massiven Spams hat uebrigens ein amerikanisches Anwaltsbuero erfahren. Die vermeintlich klugen Anwaelte hatten eine Werbung fuer sich selbst in allen erreichbaren Gruppen einzeln (!) verschickt, insgesamt ueber 5000 Mal. Zusaetzlich hatten sie die Header ihrer Artikel noch verfaelscht, sodass nicht so erfahrene Netzbenuetzer auf einen anderen Absender haetten schliessen koennen und ihre Artikel selbst in moderierten Gruppen erschienen, was den Spam noch zusaetlich verschlimmerte. Kurz darauf war der Anschluss ihres Netzwerkanbieters total ueberlastet, weil weltweit tausende Benutzer Protestbriefe und Mailbombs (auch nicht gerade die feine englische Art) verschickten. Ebenso lahmgelegt waren Telefon- und Fax-Anschluesse des Bueros. Zwei Tage spaeter hatten die Netzanbieter definitiv die Nase voll und zogen den Netzstecker. Das interessante an der Geschichte ist aber, das ebendieses Anwaltsbuero fast das selbe schoneinmal mit aehnlichem Erfolg versucht hatte (der "GREEN CARD"-Spam) und daraufhin ein Buch ueber erfolgreiches Werben im Internet veroeffentlicht hat. Manche lernen's eben nie...

Wer mehr ueber das Thema wissen moechte, schaue sich die Gruppen news.admin.net-abuse.announce und news.admin.net-abuse.misc einmal genauer an.

Groessere Artenvielfalt: Mehrere Newsserver

Einigen von Euch ist es vielleicht schon stoeren aufgefallen, die anderen haben es noch gar nicht bemerkt und wieder anderen ist es schlicht egal: Auf dem fuer die rifrafs gueltigen Newsserver (neptune) sind nicht alle Gruppen erhaeltlich (insbesondere die von gewissen Boulevard-Medien so aufgeilend dargestellten Erotik-Gruppen). Dies soll nun aber kein Aufruf sein, sich das Zeug anderswo per News holen zu gehen, denn fuer unbeschraenkte Bildermengen eignen sich CDs bei weitem besser. Fehlt einem trotzdem ausgerechnet die wichtigste Gruppe, so kann man dies umgehen, in dem man einen Newsserver in der Naehe aussucht, der eine groessere Auswahl anbietet. Um den neuen Newsserver zu verwenden, muss man vor dem Starten von tin die environment-Variable NNTPSERVER neu definieren (siehe ersten tin-Artikel). Aber Achtung! Wenn man jetzt tin ganz normal startet, verwendet er standardmaessig das File ~/.newsrc um die fuer den Benutzer interessanten Gruppen zu finden und um zu erkennen, welche Artikel bereits gelesen wurden. Da man nun aber einen anderen Newsserver benutzt und die Nummerierung der Artikel von Server zu Server unterschiedlich ist, fuehrt das unweigerlich zu einem Chaos. Abhilfe schafft hier ein neues newsrc-File, welches man speziell fuer diesen Server verwendet. Neu muss man tin wie folgt starten: 
rtin -f newsfile
also zum Beispiel 
rtin -f ~/.newsrc2
Fuer Visinfo-Leser duerfte noch interessant sein, dass auf auf dem Newsserver vis-next.iiic.ethz.ch alle Visinfo-Gruppen zum Lesen bereit liegen. In's Visinfo schreiben kann man auf diese Art natuerlich nicht, aber immerhin kann man die dortigen Texte so bequemer und ohne EzInfo weiter zu belasten lesen.

Um sich das ganze einfacher zu machen, legt man sich am besten fuer jeden Newsserver ein kleines shell-script an. Fuer's Visinfo saehe das dann etwa so aus: 

#!/bin/csh
setenv NNTPSERVER vis-next.ethz.ch
tin -f ~/.vnewsrc

Dinosaurier im Usenet: Binaries

Daten im Usenet duerfen sich nur aus ASCII-Zeichen (7 Bit) zusammensetzen. Damit man trotzdem Programme (die normalerweise alle 8 Bit ausnutzen) verschicken kann, werden sie speziel kodiert. Dies geschieht mit dem UNIX-Komando "uuencode". Ein weiteres Problem sind Newsserver oder Newsreader, die nur Artikel unter einer bestimmten Maximalgroesse druchlassen. Deshalb muessen die kodierten Daten zusaetzlich noch in kleinere Teile zerstueckelt werden (meist in der Groessenordnung von etwa 50-60 Kilobytes). Alles von Hand wieder zusammenzusetzen waere natuerlich recht muehsam, deshalb unterstuetzt einem tin in dieser Taetigkeit recht angenehm. Will man ein codiertes File aus einer Gruppe zurueckgewinnen, so geht man wie folgt vor:
  1. Man markiert die zusammengehoerenden Artikel (sie sind meistens nummeriert) in der richtigen Reihenfolge mit 'T' oder 't', je nach tin-Version.
  2. Dann speichert man sie mit 's' und gibt mit 'T' noch an, dass die markierten Artikel gespeichert werden sollen (anstatt beispielsweise der aktuelle Thread oder die weiter oben besprochenen automatisch markierten Artikel). Der anzugebende Filename ist egal, er wird sowieso nur temporaer benutzt.
  3. Zum Schluss laesst man die Artikel mit 'u' gleich durch "uudecode" dekodieren.
Wenn tin fertig ist, fragt er einen noch, ob man die gespeicherten Artikel, aus denen das kodierte File zusammengesetzt wurde, loeschen will. Dies sollte man auch tun, da ansonsten nur nicht mehr benoetigter Datenmuell anfaellt. Die dekodierten und wiedervereinigten Binaerdaten befinden sich nun im Verzeichnis ~/News.

Demokratie in der Anarchie: Einrichten neuer Gruppen

Eigentlich gibt es im Usenet kein Gesetz, allerdings existieren einige Regeln, an die man sich mehr oder weniger halten muss. Eine Ausnahme bildet das Prozedere, mit dem neue Gruppen geschaffen werden: Es muss aeusserst genau eingehalten werden. Als erstes ruft jemand, der eine neue Gruppe einrichten moechte, mit einem "RFD" (Request For Discussion) zur Diskussion ueber ihre Notwendigkeit und ihren Namen auf. Der Aufruf selbst wird in news.announce.newgroups (und eventuell einigen anderen mit der neuen Gruppe verwandten Gruppen) verschickt, die Diskussion findet aber in news.groups statt. In einem RFD sollte so genau wie moeglich drin stehen, worum es in der neuen Gruppe gehen soll, wie ihr Name und die Beschreibung ist, ob sie moderiert sein soll und wer der allfaellige Moderator waere. Falls es keine nennenswerten Gruende gegen die Einrichtung der Gruppe gibt, dauert die Diskussion 21 bis 30 Tage, ansonsten wird der RFD angepasst und eine neue Diskussion gestartet. Danach kommt die Abstimmung, die durch einen CFV ("Call For Votes") eingeleitet wird (es gibt zwei CVF pro Abstimmung) und genau drei Wochen dauert. Teilnehmen kann jeder, allerdings nur mit genau einer Stimme (man kann sie nachtraeglich noch aendern, aber man darf nicht von mehreren Accounts aus mailen). Abgestimmt wird per e-mail, wobei die Namen nachtraeglich veroeffentlicht werden. Auf diese Art sollte es moeglich sein, einen Betrug aufdecken zu koennen. Wer Abstimmungsbetrug begeht, wird virtuell an den Pranger gestellt. Damit die neue Gruppe eingerichtet werden kann, muss die Abstimmung mit 2/3 Ja und mindestens 100 mehr Ja als Nein gewonnen werden. Werden diese Bedingungen nicht erfuellt, darf fuer 6 Monate nicht mehr ueber das selbe Thema abgestimmt werden. Gleich verfahren wird uebrigens bei Aenderung von bestehenden Gruppen oder Gruppen-Hierarchien.

Anders ist es bei den alt.*-Gruppen: Hier kann jeder der will eine neue Gruppe einfuehren. Theoretisch sollte man zwar zuerst abklaeren, ob das Beduerftnis wirklich da ist, dies wird aber nicht immer gemacht. Wie sonst koennten Gruppen wie "alt.duck.quack.quack.quack" entstehen? Andererseits hat dieses Vorgehen auch Vorteile, da schnell und ohne Umstaende Gruppen mit einem sehr aktuellen Thema (wie "alt.current-events.kobe-quake") erstellt werden koennen.

So, das waere meine zweiteilige kurze Einfuehrung in's Usenet und den Newsreader tin. Fuer Fragen und Kommentare (habe ich etwas wichtiges vergessen?) stehe ich gerne zur Verfuegung.

Zum Abschluss eine zum Thema passende Weisheit:

   "The Wittenberg church door was Usenet for Luther's community."
                              -- Nick Arnett

Felix Rauch (IIIC/6)
frauch@iiic.ethz.ch