Was ist eine
Message-ID? Was ist ein
FQDN?
Und was soll man damit anfangen?
Eine Message-ID ist ein Identifizierungsmerkmal für E-Mails und Usenet-Postings.
E-Mails und Postings in Newsgroups1 enthalten zumeist2 ein eindeutiges Identifizierungsmerkmal, die sog. Message-ID, vergleichbar einer Seriennumer, die aber nicht auf Zahlen beschränkt ist.
Dies ermöglicht die Herstellung einer Bezugsverkettung, d.h. die Darstellung, auf welche E-Mail oder welchen Newsbeitrag geantwortet wird, so dass ein E-Mail-Programm oder Newsreader daraus einen sog. Thread, einen Diskussionsfaden, erzeugen kann, in dem Beiträge so in eine Baumstruktur eingeordnet werden, dass Antworten jeweils unter den Urspungsbeitrag eingerückt werden. Außerdem ermöglicht die Message-ID, identische Nachrichten zu erkennen - diese haben dann nämlich logischerweise dieselbe Message-ID.
Postings sind in ihrem technischen Aufbau und ihrer Struktur E-Mails sehr ähnlich - wenig überraschend, weil ihr Format auf dem einer E-Mail aufbaut. ↩
In E-Mails ist sie nach dem zugrundeliegenden technischen Standard, RFC 5322, optional, wird aber in der Praxis heutzutage eigentlich immer durch das Mailprogramm gesetzt oder durch einen Mailserver auf dem Transportweg ergänzt. Für Postings im Usenet ist die Message-ID hingegen ein zwingender, sehr wichtiger Bestandteil, auf dem der Datenaustausch der Server untereinander und die Vermeidung von Duplikaten basiert. ↩
Besonders wichtig ist letzteres im Usenet: Newsserver synchronisieren ihren Nachrichtenbestand nämlich in der Weise, dass sie allen Nachbarn ("Peers") jedes neue Posting anbieten, das sie erhalten. Von ihren Nachbarn erhalten sie im Gegenzug ebenfalls alle neuen Beiträge angeboten, die diese erhalten.
Um eine unnötige vielfache Übertragung derselben Daten zu vermeiden, fragt daher jeder Newsserver jeden Partner zuvor, ob er die Message-ID schon kennt. Ist das der Fall, wird das Posting nicht übertragen. Umgekehrt lehnt jeder Newsserver Beiträge ab, deren Message-ID in seiner Datenbank (der "History") schon vorhanden ist. So werden Duplikate verhindert1.
Deshalb geht es auch furchtbar schief, wenn ein System Message-IDs empfangener Beiträge verändert und sie dann wieder ins Netz einspeist. ↩
Message-IDs sehen aus wie E-Mail-Adressen.
Vom Aussehen entspricht eine Message-ID optisch einer E-Mail- Adresse: beginnend mit einer öffnenden spitzen Klammer, dann eine Zeichenfolge, dann ein "Klammeraffe" (at-Symbol), dann eine weitere Zeichenfolge, dann eine schließende spitze Klammer.
Kurzum, so: <linke.seite@rechte.seite>.
Wünschenswert - und im Fall des Usenets aus den geschilderten Gründen sogar zwingend - ist es dabei, wenn eine Message-ID eindeutig ist und dies auch möglichst lange bleibt, damit nicht zufällig irgendwann einmal zwei unterschiedliche Nachrichten mit der gleichen Message-ID unterwegs sind.
Um sich nicht auf den Zufall verlassen zu müssen - der bei großen Zahlen manchmal ganz erstaunliche Ergebnisse zeigt - und sicherlich auch, weil die Message-ID - kurz MID - nun schon einmal wie eine E-Mail-Adresse aussieht, hat es sich eingebürgert, dass auf der rechten Seite des "@"-Symbols der Name des Systems steht, das die Message-ID erzeugt hat. Das begrenzt die Möglichkeit von Duplikaten auf einen Rechner, und auf diesem können sie durch die Aufnahme eindeutiger Elemente wie sekundengenaue Zeit, Kennung des Newsserverprozesses uws. in die linke Seite der MID verhindert werden.
Man bildet Message-IDs üblicherweise aus dem Namen des Rechners, auf dem sie erzeugt wurden.
Dieses System hat mehrere Vorteile: So lässt sich direkt erkennen, welches System die Message-ID erzeugt hat, und wenn jemand dieses System alleine nutzt, kann er seine eigenen Beiträge im Usenet schon an der Message-ID erkennen (und damit auch jede direkt und indirekte Antwort, denn dort steht ja die Message-ID des beantworteten Beitrags in der Bezugsverkettung, dem References-Feld).
Allerdings gibt es auch ein Problem: Dieses System funktioniert nur, wenn jeder Rechner (a) einen Namen hat und dieser Name (b) auch einmalig ist.
In größeren organisatorischen Strukturen - und damit dort, wo diese Prinzipien entstanden sind - ist das kein Problem, weil man die dort vorhandenen Rechner ohnehin benennen und strukturieren muss. Sie erhalten einen Namen ("Hostname") und werden einem Organisationsbereich ("Domain") zugeordnet.
Dort liegen auch die Urspünge des Domain Name System, kurz DNS, und dem, was wir als "Internetadressen", "Domains" und letztlich auch E-Mail-Adressen kennen: www.beispiel.de bezeichnet eigentlich und ursprünglich den Rechner mit dem Namen www in der Organisation beispiel.de, und thomas@rechner027.informatik.uni-beispiel.de war ursprünglich nichts anderes als die Bezeichnung für den Benutzer mit der Kennung Thomas auf dem Rechner 27 der Fakultät für Informatik der Universität Beispiel.
Der Name rechner027 kann dabei natürlich weltweit - und auch an der Universität Beispiel - mehrfach vorkommen, aber eben nur einmal in der Fakultät für Informatik. Wenn rechner027 der Eigenname, der hostname, ist, dann ist informatik.uni- beispiel.de hier die Domain (und zugleich eine Unterdomain, eine sog. Subdomain, der Domain uni-beispiel.de). Der volle Name rechner027.informatik.uni-beispiel.de wird daher auch als "voller", "qualifizierter" oder "domainisierter" Name bezeichnet, oder eben als "fully qualified domain name", kurz FQDN.
Ein FQDN ist mithin der vollständige Name eines Rechners samt der Domain.
Auch heute noch hat ein jeder Rechner - ob unter Unix/Linux oder unter Windows - einen Namen; nicht immer hat er aber auch eine (gültige) Domain. Woher sollte der durchschnittliche Internetnutzer auch eine eigen Domain haben? Und was sollte er sonst damit anfangen, wenn er sie eigentlich nicht braucht?
Was kann man tun, wenn der eigene Rechner keinen FQDN hat?
Es gibt daher andere Möglichkeiten, Message-IDs zu erzeugen - man kann diese Aufgabe bspw. dem Server überlassen, also gar keine eigene Message-ID setzen, oder man kann zur Erzeugung der Message- ID die E-Mail-Adresse des Absenders verwenden1.
Nun hat eine selbst erzeugte Message-ID mit einem individuellen Namen des eigenen Rechners aber durchaus die genannten Vorteile, und die letztgenannte Art der Generierung der Message-ID aus der E-Mail-Adresse verstößt gegen das alteingeführte Prinzip, dass deren rechte Seite den Verantwortlichen für die Erzeugung der MID (und damit zumeist auch für die Nachricht) ausweisen sollte.
Dazu kommt, dass viele Programme zum einen Message-IDs erzeugen, ohne dass man das abstellen könnte, und zum anderen bei dem ursprünglichen Prinzip der Erzeugung von Message-IDs geblieben sind und diese eben einfach mit dem auf diesem Rechner gesetzten hostname generieren. Wenn dieser dann localhost lautet, weil er bei der Installation so gesetzt wurdem ist die Gefahr von Duplikaten erhöht; lautet er mistkiste oder ist nicht wirklich druckreif, weil der Benutzer sich bei der Einrichtung seines Rechners geärgert hat, oder gibt er persönliche Informationen preis, kann das zumindest peinlich sein. In allen Fällen ist es suboptimal und technisch nicht korrekt.
Oft besteht aber die Möglichkeit, einen Namen zu definieren, der - statt des Rechnernamens - als FQDN für die Erzeugung von Message-IDs verwendet werden soll. Oder man kann schlicht den Rechnernamen und die Domain auf passende Werte setzen.
Stellt sich nur die Frage: was sind "passende Werte", und wo bekommt man eine Domain für diesen Zweck her?
Lautet diese benutzer@domain.beispiel, dann hat die MID die Form linke.seite%benutzer@domain.beispiel. ↩
Letztlich ist ein FQDN nichts anderes als ein Name, bei dem sichergestellt ist, dass er nur einmal vergeben werden kann.
Ansonsten ist er beliebig. Voraussetzung für die Erzeugung korrekter eigener Message-IDs ist es daher (nur), dass man seinem Rechner einen eindeutigen Namen geben bzw. dafür eine eigene (Sub-)Domain nutzen darf. Wenn man die Erzeugung von Message-IDs also nicht dem Newsserver1 überlassen möchte, benötigt man das Recht zur Verwendung eines Namens.
Oder dem Mailserver - aber im Bereich E-Mail spielt die Message-ID keine so große Rolle. ↩
Dafür gibt es verschiedene Möglichkeiten:
Man verfügt über eine eigene Domain oder reserviert sie sich. Dann kann man einfach seinen Domainnamen oder eine beliebige Subdomain als FQDN vewenden. Wer sich also example.org reserviert hat, kann direkt example.org oder vielleicht besser noch news.example.org oder mail.example.org verwenden.
Wer keine eigene Domain hat, hat vielleicht einen verständnisvollen Provider, der das Problem kennt, und die Generierung von Message-IDs mit einer Subdomain seiner Domain gestattet, bpsw. loginname.kunde.provider.de. Das war früher verbreiteter, als auch das Angebot eines Usenet-Zugangs noch verbreiteter war; eine Liste uns bekannter entsprechender Anbieter findet sich am Ende der Seite.
Außerdem gibt es die Möglichkeit, sich einfach irgendwo eine Subdomain zu "leihen".
Und genau das ist es, was my-fqdn.de anbietet:
die Nutzung einer Subdomain in der Form
ihrname.my-fqdn.de, um damit Message-IDs
zu erzeugen.
Mehr über Message-IDs und FQDNs
Warum man beim Betrieb eines Newsservers niemals vorhandene Message-IDs löschen darf, woher man einen FQDN bekommt und wo man ihn bei Newsservern wie INN oder leafnode einträgt.
Was eine Message-ID ist, und wie man in verschiedenen Newsreadern den FQDN zu ihrer Erzeugung eintragen kann.
Weitere Anbieter ergänzen wir gerne, wenn wir von ihnen erfahren.