FAQ: Das Ding mit der ID
- 2.1. Wie sieht eine Message-ID aus
- 2.2. Wozu dient diese Message-ID eigentlich?
- 3.1. Mein INN erstellt aber eigene IDs
- 3.1.1. Unvollständige Liste solcher Provider:
- 3.2. Mein Leafnode erstellt auch eigene Message-IDs
- 3.3. Was kann passieren?
1. Update
Und noch ein Update: Siehe den Abschnitt über den INN.
Ich habe mehrere Mails bekommen, in denen einige Sachen gefragt werden, die ich
gerne hier klarstellen möchte:
1.1. Linux-Magazin
Nein, ich bin kein LM-Hasser. Ich habe - im Gegenteil - höchsten Respekt vor dieser
Zeitschrift, finde aber den Stil, eine FAQ ohne Wissen des Autors abzudrucken, diese
zu kürzen und keine Bezugsquelle anzugeben - gelinde gesagt - schlechten Stil.
Um die wichtigste Frage vorwegzunehmen, auch wenn das LM in seinem Abdruck die
Stellen, die sich mit dem Überschreiben anderer Header beschäftigen, rausgekürzt
hat, sie sind ebenfalls nicht zu überschreiben.
Prinzipiell gilt, daß kein Header angefaßt werden sollte, es sei denn der
entfernte Server motzt explizit, daß er keine Postings mit diesem Header
haben möchte.
Herausfinden kann man das, wenn man die ersten 10 Postings nicht in irgendwelche
Gruppen schickt sondern sinnentlehrte Postings nach de.test oder eine andere
Testgruppe. Das macht man ja sowieso, bevor man seinen Server auf das Netz losläßt,
insofern sollte da nichts schiefgehen.
2. Warum soll ich keine Message-IDs löschen?
Immer wieder (zuletzt im Linuxmagazin 5/99) wird von "Experten" dazu
geraten, beim Einsatz eines eigenen Newsservers unter Linux/Unix die
Message-ID vor dem Versenden zu löschen. Warum das nicht sein darf,
welche Gefahren daraus entstehen können und wie man es richtig macht,
das wird hier erklärt.
2.1. Wie sieht eine Message-ID aus
Nach RFC-822 (das ist der, der festlegt, wie ein Mailheader auszusehen
hat - kann auf ftp.ripe.net/rfc/
gesaugt werden) hat eine Message-ID das Format
<einmalig@domain_name>
wobei "einmalig" ein beliebiger String (in dem kein <, > oder @
vorkommen darf) ist, dessen Einmaligkeit mindestens 2 Jahre garantiert
sein muß, und "domain_name" der Name des Systems ist, über den der
Artikel das Usenet betritt.
Bei dem Domainnamen muß es sich um einen sog. FQDN halten, einen
Fully Qualified Domain Name, also einen Domainnamen, der so in einem
Nameserver eingetragen ist. Um herauszubekommen, ob ein Hostpart, das Ding
nach dem @ in einer ID also, auch ein FQDN ist, kannst Du unter Linux das
Kommando "host" verwenden:
[nethammer]:~ :> host nethammer.qad.org
nethammer.qad.org A 195.211.170.89
wenn es sich bei dem Domainnamen nicht um einen FQDN handelt, sieht das
Ganze so aus:
[nethammer]:~ :> host diesen.host.gibt.es.nicht
diesen.host.gibt.es.nicht does not exist (Authoritative answer)
Tools für Windows findet man u.a. auf http://www.kiraly.com/software/utilities/,
ein HTML-Tool habe ich dafür auf dem Nethammer bereitgestellt.
2.2. Wozu dient diese Message-ID eigentlich?
Die Message-ID ist das einzig Eindeutige an einer Nachricht. Anders
als From: oder Betreffzeile klassifiziert sie ein Posting
vollständig, d.h. sie ist der Wert, nach dem die Newsserver dieser Welt
ein Posting verwalten.
Um z.B. festzustellen, ob ein Server bereits ein angebotenes Posting
in seinem Datenbestand hat (oder hatte und es bereits löschte),
vergleicht dieser die ID der angebotenen Nachricht mit seiner internen
Liste (der sog. History).
3. Wer vergibt die Message-ID?
Spätestens der Newsserver, auf dem die Nachricht eingeliefert wird und
damit an die große weite Welt (oder auch nicht) verteilt, generiert
diese ID. Aufgabe der ID ist es, mindestens zwei Jahre weltweit
eindeutig zu sein um zu verhindern, daß Nachrichten doppelt auf
demselben Server (sog. Dupes) erscheinen.
Das ist böse, macht Arbeit und trägt zu einem kleinen aber nicht
unerheblichen Teil zum Unlesbarwerden des Usenet bei.
3.1. Mein INN erstellt aber eigene IDs
Ja, denn Dein INN ist ein vollwertiger Newsserver der alles das tut,
was ein Newsserver tun sollte - also auch Message-IDs generiert für
Postings (Nachrichten), die noch keine haben. Da eine ID nun eindeutig
sein muß, ist es sinnlos - genauer gesagt grundfalsch - eine ID zu
generieren, die als Teil nach dem @ den Hostnamen Deines Providers
oder einen erfundenen Hostnamen hat - woher soll Dein INN denn
wissen, ob diese ID schon vergeben ist (und das in den letzten _2_
Jahren). Als Möglichkeit bleibt Dir also nur, einen FQDN (also einen
eigenen Domainnamen) zu bekommen oder zu verhindern, daß Dein INN eine
Message-ID erzeugt, wenn Du auf ihn postest.
Letzteres macht man mit einem Editor und dem Quellcode des INN, das
ist nicht trivial und kann noch mehr Probleme erzeugen als es löst,
deshalb werde ich auf diese Möglichkeit nicht eingehen.
An einen eigenen, für Dich reservierten, Hostnamen kommst Du auf
mehreren Wegen, der zweifellos Einfachste ist eine Nachfrage beim
eigenen Provider ob er Dir eine Subdomain zuweisen mag (diese Domain
muß keinesfalls Mails annehmen oder sonst irgend wie aktiv sein, es
muß nur sichergestellt sein, daß außer Dir niemand diese
verwendet).
+NEW+ Ich habe mehrere Mails bekommen, daß der INN immer noch keine richtige
ID erstellt, sondern den Pseudo-FQDN des eigenen Systems nimmt. Das ist
richtig, der INN erzeugt seine Message-ID aus einer Funktion namens "getFQDN",
die den eingestellten FQDN des Systems und keinen Fremden, frei eintragbaren,
verwendet. Wer dieses Problem hat kann von hier
einen Patch downloaden, bei dem man den FQDN für die MessageID mittels eines
Parameters in der inn.conf setzen kann.
3.1.1. Unvollständige Liste solcher Provider:
-> T-Online: <t-online-kennung>.dialin.t-online.de
-> SNAFU: <username>.berlin.snafu.de
-> Okay.Net: <username>.users.okay.net
-> POP: <username>.news.<standort>.pop.de
-> SGH-Net: <name>.users.sgh-net.de
-> easynews/easynet: <username>.easynews.de
-> news.cis.dfn.de: <username>.user.cis.dfn.de,
hier aber den Usernamen entsprechend wählen, da dieser nicht automagisch eindeutig ist.
-> FU Berlin: <username>.dialup.fu-berlin.de ist eindeutig.
-> nethammer: <username>.qad.org
-> Uni Bochum: <rechner>.<loginid>.dialup.ruhr-uni-bochum.de, wobei
<rechner> frei wählbar ist.
bei allen Weiteren hilft das Nachfragen beim Newsmaster sicherlich
weiter.
Alternativ gibt es das Projekt qad
bei dem es auch Subdomains gibt, sowie die Dienste von
- http://www.ddns.org
- http://www.eu.org
- http://www.subdomain.de
- http://www.dyndns.org
- http://www.dhis.org
- http://www.dhs.org
3.2. Mein Leafnode erstellt auch eigene Message-IDs
Auch Leafnode ist ein Newsserver und erstellt deswegen ebenfalls
eigene Message-IDs für Nachrichten, die noch keine haben.
Im Wesentlichen gilt das für den INN Gesagte.
Falls man sich einen Domainnamen besorgt hat und Leafnode diesen
beibringen möchte, genügt es, im Konfigurationsfile die Option
"hostname = " entsprechend zu setzen. Nähere
Erläuterungen findet man in der Dokumentation zu Leafnode.
3.3. Was kann passieren?
Stell Dir vor, ein Posting wird nicht mehr als "schon vorhanden"
erkannt. Dieses Posting würde auf allen Newsservern dieser Welt ein
zweites Mal auftauchen. Wenn Dein Provider auch noch das From:
umschreibt (T-Online tat das z.B.) dann wird aus dem:
From: jonas@ping.finger.mount.fsck.de (Jonas Luster)
Message-ID: <dont-delete-me.934ksdhf67.fsf@nethammer.qad.org>
ein
From: Mein Name <meine@mail.de>
Message-ID: <ich-tus-trotzdem@linux-magazin.de>
-> also tauchen Nachrichten von Menschen neu in den News auf, die Dein
From: tragen - unschöne Sache.
Passiert ist sowas schnell. Um zu verhindern, daß ein Newsserver
Artikel, die er von einem Host hat, an diesen zurückschickt, wird vor
dem Versenden der Path:-Header des Postings geprüft. Nur wenn in
diesem _nicht_ der Name des Servers, an den man senden will,
auftaucht, wird das Posting diesem angeboten. Da man ja nun
dummerweise die Message-ID gelöscht hat, nimmt dieser das Posting auch
an, gibt ihm eine neue ID und wift es in die Welt.
Nehmen wir an, Du hast in Deiner newsfeeds Folgendes stehen:
provider/news.provider.de\
[...]
und Dein Provider schickt Dir Postings mit:
Path: news.provider.de!news.ander-provider.de
dann werden diese Nachrichten nicht in den Ausgangskorb (out.going)
gelegt.
Wenn nun dein Provider seinen Pfadeintrag ändert (sowas kommt in den
besten Familien vor) und vergißt, Dich zu informieren (sowas soll
vorkommen), dann matchen Postings, die vom Provider geholt werden,
nicht mehr auf den Teil nach dem / oben und gehen in den Ausgangskorb
- batsch, Dupe-Schwemme.
Zigtausende von Newsservern routen diesen Artikel ein zweites Mal,
eine unzählbar höhere Anzahl von Clients bekommt ihn ein zweites Mal
und die Newsadminsitration vieler beteiligter Systeme haben eine nicht
unerhebliche Mehrarbeit - und das ist schon recht oft vorgekommen.
4. Andere Gefahren
Auch vom Path: Header sollte jeder seine Finger lassen. Im Path-Header
sind die Systeme aufgeführt, durch die der Artikel auf jeden Fall
schon einmal geroutet wurde - modifiziert man diesen Header, bekommen
die gelöschten Systeme den Artikel ebenfalls ein zweites Mal
angeboten.
Das Selbe gilt für den Date: Header. Wenn im Posting nicht explizit
ein Expire: angegeben ist und der Newsadmin dieses zuläßt, wird anhand
des Date: Headers die Haltezeit eines Postings bestimmt - diesen auf
ein aktuelles Datum zu setzen, hätte als Effekt, daß Unmengen an
uralten Postings in Newsgruppen nicht expired (gelöscht) werden.
5. Reicht das?
Ich hoffe, ich konnte die Gefahr, die von einer solchen Praxis ausgeht,
ein bißchen klarer machen. Wenn Du weitere Fragen hast, dann stelle
diese in der Newsgruppe de.comm.software.newsserver. Wenn
Du Vorschläge oder Korrekturen hast, dann auch immer her damit.
6. Danke für Mitarbeit an
Boris 'pi' Piwinger <3.14@detebe.org>
Sven Paulus <sven@karlsruhe.org>
Florian Weimer <fw@cygnus.stuttgart.netsurf.de>
Andreas Barth <aba@muenchen.pro-bahn.org>
Cornelius Krasel <krasel@wpxx02.toxi.uni-wuerzburg.de>
Roland E. Lipovits <rel@lipo.at0.net>
Jörg Strohmayer <usenet@bigfoot.de>
Thomas Bader <thomasb@trash.net>
Albrecht Kolthoff <kolthoff@gmx.net>
... die Newsmaster der oben erwähnten Newsserver.
Autor diese Dokumentes:
Jonas Luster.
Kommentare, Anregungen oder Kritik bitte per e-mail an
www@hanau.net.
|