Jedes technische Gerät sollte vor seinem dauerhaften Einsatz einem Test unterzogen werden. Dies ist bei der Konfiguration von Software nicht anders. Ganz besonders gilt dies, wenn von dieser Konfiguration nicht nur der eigene, sondern auch andere Rechner und andere Benutzer betroffen sind. Und im Usenet sind eine ganze Menge anderer Computer und deren User betroffen.
Es ist daher von großem Interesse aller Teilnehmer am Usenet, daß jedes Programm -- und hier ist auch wirklich jedes gemeint --, das zur Teilnahme eingesetzt wird, auch wirklich richtig konfiguriert ist. Nicht selten können schon geringe Fehler in der eigenen Konfiguration zu kleinen und größeren Problemen auf anderen Rechnern führen.
Mit einer korrekten Konfiguration geht die Neugier des Usenetteilnehmers einher, der wissen will, ob die Artikel, die er in das Usenet abschickt, auch wirklich verteilt werden. Und natürlich interessiert ihn, ob ihm jemand antworten kann.
Das ist eine sehr gute Frage :-). So, wie eine Band ihren Soundcheck nicht vor versammeltem Publikum, sondern in anderen Räumen oder vor dem Auftritt macht, genauso prüft man seine Testpostings in besonderen »Räumen«: den *.test Gruppen. Und nur dort.
Denn vor allem in lokalen und regionalen Testgruppen lesen auch technisch Versierte mit, die auf kleine und große Konfigurationsfehler hinweisen können.
Wichtig ist, daß man klein anfängt: Zunächst sollte man versuchen, den eigenen Newsserver bzw. den des Providers dazu zu bringen, einen Artikel in einer Testnewsgroup des Providers (z.B. t-online.test, eunet.test, metronet.test) überhaupt anzunehmen. Wenn bereits hier Probleme auftreten, etwa wenn Dein Testposting nicht angenommen wird, sollte man sich gleich an den Anschlußgeber wenden.
Hat es geklappt, ist zu prüfen, ob der Artikel so aussieht, wie er aussehen soll. Kriterien sollen hier neben dem eigentlichen »Layout« auch die Absenderadresse (From:-Zeile) und die Message-Id im Kopf der Nachricht sein. Einige Hinweise, wie diese aussehen sollten, finden sich im Anhang dieses Textes.
Ist alles in Ordnung, macht man mit einer *.test-Gruppe weiter, die das lokale oder regionale Umfeld abdeckt, z.B. in bln.test, muenster.test, westf.test, kiel.test usw.
Das ist lobenswert. Jeder, der am Usenet teilnimmt, sollte mindestens einmal, bevor er einen Artikel postet, ein Testposting abgesetzt haben. Das hat einige Vorteile:
Erstens lernt man, mit seinem Newsreader umzugehen. Das sollte man besser nicht in einer laufenden Diskussion versuchen. Wenn etwas dann nicht funktioniert, ist man schnell frustriert. Klappt es, sorgt die fehlerhafte Bedienung aber für Zündstoff, bleibt von vielleicht guten Argumenten in der Diskussion manchmal nicht mehr viel übrig.
Zweitens sieht man, ob die eigenen Postings auch wirklich angenommen und verteilt werden. Und, wenn man einen solchen Testartikel in der dafür vorgesehenen Newsgroup absetzt, erhält man u. U. auch Mail von anderen Computern, die diesen Testartikel aufgefangen haben. Aus einer solchen Mail kann man dann erkennen, wohin überall der Artikel verteilt wurde, wie lange er dafür gebraucht hat und bei fast allen solchen Antworten auch, über welche Systeme der Artikel verteilt wurde. Wie man diese Informationen erkennt, wird im Kapitel über Reflektoren erklärt.
Man sollte zunächst einmal einen Artikel in eine Test- oder lokale (nur auf dem eigenen Rechner oder beim Provider verfügbare) Newsgroup setzen und anschließend nachsehen, wie er aussieht. Möglicherweise taucht der Artikel nicht sofort in der Newsgroup auf; welche Gründe das haben kann und wie man damit umgeht, steht im Abschnitt 3.1.
Als nächstes sollte man versuchen, auf seinen eigenen Artikel zu antworten, einmal als sogenannter »Followup« (öffentliche Antwort) und einmal als »Reply« (Antwort per E-Mail).
Zum guten Schluß sollte man noch ausprobieren, ein eigenes Posting zu widerrufen (zu »canceln«; bei manchen schlecht übersetzten Programmen heißt diese Funktion »abbrechen«). Jeder Newsreader bietet diese Möglichkeit, einem einmal veröffentlichten eigenen Artikel eine Nachricht hinterherzuschicken, die jeden Newsserver anweist, diesen wieder zu löschen und nicht weiter zu verteilen. (Wenn es auch vereinzelt Newsserver gibt, die diese Aufforderung ignorieren.)
Wie genau das geht, sollte der Anleitung bzw. der man-page des Newsreaders stehen. Eine Auflistung für diverse gebräuchliche Programme findet sich in »Fragen und Antworten: de.newusers.questions« von Christof Awater in der Newsgroup de.newusers.questions. Auch beim Canceln gilt wie bei normalen Posting, daß der Effekt u. U. nicht sofort sichtbar ist.
Hat das alles geklappt, ist man für das wichtigste gerüstet.
Reflektoren sind spezielle Programme, die die *.test-Newsgroups »überwachen«. Taucht in einer solchen Newsgroup ein neues Posting auf, schickt der Reflektor es ganz oder teilweise per E-Mail an den Absender zurück: Er reflektiert, spiegelt es. In den meisten Fallen erhält man so Informationen darüber, wohin das Posting verteilt wurde und wie lange es dorthin gebraucht hat. Manchmal gibt es auch noch Informationen über das System, auf dem der Reflektor installiert ist.
Manche Reflektoren, die den Artikel nicht zurückschicken konnten, weil der Absender nicht erreichbar war oder die Absenderadresse fehlerhaft ist, posten einen Artikel in die Testnewsgroup, in dem sie darauf hinweisen.
Möchte man keine Reflektorantworten, reicht es in den meisten Fallen, in die ersten Zeilen des Testpostings die Worte »no reply« oder »ignore« aufzunehmen.
Wegen zunehmenden Mißbrauchs gibt es nicht mehr in jeder Test-Newsgroup Reflektoren, daher schwankt die Anzahl der Reflektoren von Zeit zu Zeit. Die folgende Auflistung ist Ergebnis von Tests Ende April 1997:
de.test 3 Reflektoren
de.alt.test 1 Reflektor
at.test 3 Reflektoren
bln.test 1 Reflektor
rhein.test 2 Reflektoren
schule.test 4 Reflektoren
ufra.test 4 Reflektoren
Die Laufzeiten der Antworten betragen einige Minuten bis einige Tage. Für Hinweise auf weitere Newsgroups mit Reflektoren (bitte die Adresse der Reflektoren beifügen) bin ich dankbar.
Diese Information kann man aus den meisten Reflektor-E-Mails ablesen. Fast alle Reflektoren schicken den sogenannten Header eines Postings in ihrer E-Mail mit. In diesem gibt es eine Zeile, die mit Path: beginnt.
Alle dort eingetragenen und durch Ausrufezeichen getrennte Wörter stehen für ein System, über das der Artikel gelaufen ist und auf dem er gespeichert wurde. Die beiden letzten Eintrage der Path:-Zeile wurden vom eigenen System generiert. Dort sollten der Name des eigenen Rechners inklusive Domain und der Mailname bzw. die Zeichenkette »!not-for-mail« stehen.
Jedoch: Selbst wenn man alle Reflektor-E-Mails auswertet und die Path:-Zeilen untersucht, man bekommt nur einen sehr kleinen Teil der Systeme heraus, zu denen der Artikel verteilt wurde. Aber man kann zumindest den Weg, über den sie dorthin gelangt sind, in etwa nachvollziehen.
Auch diese Information kann man leicht aus einer Reflektor-E-Mail entnehmen. Wenn der Reflektor es nicht sowieso schon in seiner E-Mail mitgeteilt hat, vergleicht man einfach das Datum der Reflektor-E-Mail mit dem Datum, das das Testposting enthält.
Wer sein Programm soweit im Griff hat, daß ein erstes Testposting erfolgreich abgesetzt wurde, kann bei weiteren Tests das Gefühl bekommen, daß ein Teil der gesendeten Artikel scheinbar verschwindet oder gar nicht erst im Netz auftaucht.
Manche Newsreader zeigen das eigene Posting erst dann an, wenn man die Newsgroup verlassen hat und sie neu betritt oder wenn man das Programm auffordert, neue Postings vom Server abzuholen. Möglicherweise werden eingehende Artikel vom Newssystem aber auch nicht sofort veröffentlicht, sondern erst in einem Zwischenspeicher gesammelt. Dieser wird regelmäßig geleert, und erst dann erscheint Dein Posting im Netz. Wenn man seinen Artikel also nach dem Posten nicht gleich findet und auch das Verlassen und neue Aufrufen der Newsgroup nicht hilft, dann sollte man ein paar Minuten später nochmals nachsehen.
Gerade eben hat man den Artikel noch gelesen, dann hat man mal kurz den Newsreader verlassen, und nun ist der Artikel nicht mehr zu finden. Die Ursache dafür ist ganz einfach: der Newsreader merkt sich, welche Artikel bereits gelesen wurden, und er versteckt diese Postings beim nächsten Mal, damit man nicht alles doppelt lesen muß. Normalerweise gibt es ein Kommando des Newsreaders, mit dem die versteckten Artikel wieder eingeblendet werden können.
Liegt das Posting allerdings schon länger zurück, dann kann der Artikel auch dem »Expire« zum Opfer gefallen sein: da im Usenet laufend neue Artikel geschrieben werden, müssen alte Artikel automatisch gelöscht werden, um auf den Festplatten Platz für die neuen zu schaffen. Je nach Plattengröße liegen Expire-Intervalle zwischen wenigen Tagen und mehreren Monaten, Auskunft kann einzig der lokal verantwortliche Newsadministrator geben.
Wenn Du dieses Gefühl hast, solltest Du zunächst einmal sicherstellen, daß Deine Konfiguration wirklich in Ordnung ist. Werden Postings in der Newsgroup de.test bzw. de.alt.test oder einer lokalen Test-Gruppe reflektiert (d.h. bekommst Du automatische Antworten auf Dein Posting)? Wenn ja, ist es eher unwahrscheinlich, daß niemand Deine Artikel lesen kann. Denn die meisten Newssysteme geben nicht nur Artikel aus einzelnen Newsgruppen wie de.toller.diskurs, sondern meist die Postings einer kompletten Hierarchie wie de.alt.* oder de.* weiter.
Zur Sicherheit kannst Du ja mal den Betreiber Deines Feeds (das ist der Rechner, von dem Du Deine News bekommst) fragen, ob der bestimmte Artikel angekommen ist und ob die Newsgruppe de.toller.diskurs überhaupt dort weiterverteilt wird. Zur Erinnerung: Eine goldene Regel ist es, immer so lokal wie möglich den Fehler zu suchen. Also zuerst auf dem eigenen Rechner, dann beim Feed, in einer lokalen Newsgroup und erst ganz am Ende in einer Newsgroup, die weltweit verteilt wird.
Eine andere Methode ist es, auf einen Artikel zu antworten und am Ende höflich um Antwort per E-Mail zu bitten, ob man gelesen wird. Dies sollte man aber nur tun, wenn man sich sicher ist, daß alles andere vorher nicht geklappt hat; ein kleiner Hinweis darauf, daß man das Gefühl hat, nur in dieser einen Newsgroup nicht gelesen zu werden, ist sicher auch nicht verkehrt.
Die E-Mail-Adresse des Absenders muß nach den geltenden Regeln so aussehen: lokaler_name@komplette_domain_adresse (Vorname Nachname) oder Vorname Nachname <lokaler_name@komplette_domain_adresse>
Was hier mit lokaler_name bezeichnet ist, ist der Name, unter dem man in der Domain (dem Teil hinter dem @) per E-Mail erreichbar ist. Unter Mehrbenutzer-Betriebssystemen ist dieser Name meist identisch mit dem Login-Namen.
Mit komplette_domain_adresse ist der Name des (mailempfangenden) Rechners gemeint, und zwar mit kompletter Angabe der Domain. Der Name des Rechners allein reicht nicht aus. (Ausnahme: Der Rechner ist in der world-map eingetragen. Das ist ein Spezialfall, der hier nicht weiter behandelt werden soll.)
Beipiel: Der Benutzer Eugen Plümper auf dem Rechner kannix in der Domain empfang.de, dem als Benutzernamen plums zugewiesen wurde, sollte als Absender plums@kannix.empfang.de (Eugen Pluemper) oder Eugen Pluemper <plums@kannix.empfang.de> eintragen.
WICHTIG! Umlaute durfen hier nicht verwendet, sondern müssen mit »ae«, »oe«, »ue« und »ss« umschrieben werden. Wer das nicht möchte, kann auch eine andere Umschreibung verwenden, die zwar wilder aussieht, aber in Zukunft (eigentlich heute schon) dafür sorgen soll, daß Umlaute korrekt dargestellt werden: Eugen Plümper würde dann beispielsweise zu =?ISO-8859-1?Q?Eugen_Pl=FCmper?=. Leider verstehen diese Umschreibung (auch als MIME bekannt) bisher noch nicht alle News- und E-Mail-Programme, obwohl dies mittlerweile schon recht lange Standard ist.
Mir sind folgende Newsreader bekannt, die diesen MIME-Standard »verstehen« und mit denen man Umlaute ohne Probleme verwenden kann (in alphabetischer Reihenfolge, jeweils aktuelle Versionen, wahrscheinlich nicht vollständig):
Crosspoint, Forte Agent (nicht: Free Agent!), Gnus, Microsofts Internet-News, Netscape-Navigator, pine, slrn, tin (ab unoff 1.3), WinVN.
Mehr Informationen zu Umlauten in Computernetzen finden sich in der Umlaute-FAQ von Christof Awater in de.newusers.questions.
Eine Message-Id dient zum eindeutigen Identifizieren eines Artikels. Das nach den technischen Regeln einzig gültige Format sieht so aus:
Message-Id: <lokaler_Teil@rechner.doma.in>
Wichtig ist, daß »rechner.doma.in« wirklich sowohl den Rechnernamen als auch (und das ist besonders wichtig) die Domain enthalt; der Fachmann nennt das "fully qualified domain name (FQDN)". Das hängt damit zusammen, daß der lokale Teil einer Message-Id unter zufällig gleichen Umständen auf verschiedenen Rechnern identisch erzeugt werden kann; ohne den FQDN wäre keine Eindeutigkeit mehr gewährleistet.
Werden zwei Postings mit identischer Message-Id ins Usenet eingespeist, so werden diese nur soweit verteilt, bis sie aufeinandertreffen. Damit kursieren aber in verschiedenen Teilen der Welt unter derselben Message-Id verschiedene Artikel. Unter »günstigen Umständen« wird eins der Postings gar nicht mehr angenommen (nämlich dann, wenn der eigene Newsserver der Meinung ist, er habe es schon).
Deshalb sollte man nach Möglichkeit dem Newsserver das Erzeugen der Message-Id überlassen. Denn dieser wurde (hoffentlich :-) von einem Menschen konfiguriert, der sich damit auskennt und dafür sorgt, daß keine derartigen Probleme entstehen.
Ein häufiger Konfigurationsfehler bei mit diesem Programm erzeugten Postings sind (im technischen Sinne) fehlerhafte Message-Ids. Wie man dieses Programm richtig konfiguriert, kann man in Jürgen Schicks »MS Internet News Mini-FAQ« in der Newsgroup de.answers bzw. unter der URL <http://home.pages.de/~twisters_lodge/faq/> nachlesen.
Herzlicher Dank für Anregungen und Ergänzungen geht an:
Hans-Christoph Wirth <hansi@dianoia.mayn.de>
Christof Awater <christof@paefken.westfalen.de>
Heinz Rosenheimer <rosen@heimer.waiblingen.netsurf.de>
Martin Imlau <MImlau@gmx.de>
Dieser Text unterliegt dem Urheberrecht. Der Autor behält sich alle Rechte vor. Öffentliche Weiterverbreitung des Textes außer in vom Autor veranlaßten oder genehmigten Fällen ist hiermit ausdrücklich untersagt. Dies gilt insbesondere auch für Veröffentlichungen im World Wide Web, auf CD-ROM, in Print- oder Rundfunkmedien und in Form nicht autorisierter Postings im Usenet. Die Speicherung des vom Autor oder in dessen Auftrag im Usenet geposteten Textes in öffentlich zugänglichen Archiven ist zulässig, solange gewährleistet ist, daß die jeweils aktuelle Fassung als Ganzes (das schließt insbesondere auch die Datumsangabe, den Absender und die Message-Id ein) in unveränderter Form automatisiert archiviert wird.