Linux - Wegweiser für Netzwerker Online-Version Copyright © 2001 by O'Reilly Verlag GmbH & Co.KG Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen. Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen. Wünschen Sie mehr Informationen zu der gedruckten Version des Buches Linux - Wegweiser für Netzwerker oder wollen Sie es bestellen, dann klicken Sie bitte hier.

Wie funktioniert Mail-Routing?

Das Verfahren, wie eine Nachricht an den Host des Empfängers zugestellt wird, bezeichnet man als Routing. Dazu gehört nicht nur die Ermittlung der Übertragungsstrecke vom Sender zum Empfänger, sondern auch Fehlerprüfung sowie Geschwindigkeits- und Kostenoptimierung.

Es gibt einen großen Unterschied in der Art und Weise, wie ein Internetsystem Routing durchführt und wie dies ein UUCP-System tut. Im Internet wird die Hauptarbeit beim Datentransport an den Empfänger (sofern seine IP-Adresse bekannt ist) von der IP-Netzwerkschicht erledigt. Im UUCP-Bereich dagegen muß die Route vom Benutzer angegeben oder vom Mail-Transportprogramm erzeugt werden.

Mail-Routing im Internet

Im Internet ist es ganz vom Zielsystem abhängig, ob überhaupt ein besonderes Mail-Routing vorgenommen wird. Im Normalfall wird eine Nachricht direkt an den Zielrechner übertragen, wobei zuerst festgestellt wird, an welchen Host die Nachricht gesendet werden soll, und danach die Nachricht direkt an diesen Host zugestellt wird. Die meisten Internet-Sites werden es allerdings vorziehen, daß alle eingehenden Mails von einem zentral verfügbaren Server entgegengenommen und lokal verteilt werden. Um diesen Dienst bekanntzumachen, veröffentlicht die Site im DNS einen sogenannten MX-Record für ihre lokale Domain. MX steht für den englischen Terminus Mail Exchanger. Im Grunde besagt ein MX-Record, daß der Server-Host bereit ist, alle Mail-Adressen in der Domain anzunehmen und weiterzuleiten. MX-Records können auch dazu verwendet werden, den Datenverkehr von Hosts, die nicht selbst ans Internet angeschlossen sind, zu verwalten. Typische Beispiele sind UUCP-Netzwerke und FidoNet-Rechner, deren Mails durch ein Gateway geleitet werden müssen.

Einem MX-Record ist immer eine positive Zahl, die sogenannte Präferenz, zugeordnet. Wenn mehrere Mail-Exchanger für einen Host existieren, versucht der MTA, die Nachricht an den Mail-Exchanger mit dem niedrigsten Präferenzwert auszuliefern. Wenn dieser Versuch fehlschlägt, probiert er einen Host mit einem höheren Wert. Ist der lokale Host selbst ein Mail-Exchanger für die Zieladresse, darf er Nachrichten nur an Mail-Exchanger mit niedrigerer Präferenz als seiner eigenen ausliefern. Diese Einschränkung verhindert, daß sich eine Mail zwischen verschiedenen MX-Records in einer Schleife verfängt. Existiert kein MX-Record für eine Domain (oder kein passender), kann der MTA ermitteln, ob zu der Domain eine IP-Adresse existiert, und den Versuch unternehmen, die Mail direkt an diese Adresse zu senden.

Angenommen, eine Firma namens Foobar GmbH möchte, daß alle anfallenden Mails von ihrem zentralen Server namens mailhub bearbeitet werden. Dann wird sie für jede ihrer Maschinen einen MX-Record wie diesen im DNS eintragen:

green.foobar.com.        IN   MX      5    mailhub.foobar.com.

Das macht mailhub.foobar.com als Mail-Exchanger für die Domain green.foobar.com mit einer Präferenz von 5 bekannt. Ein Host, der eine Nachricht an joe@green.foobar.com ausliefern will, findet im DNS den MX-Record, der auf mailhub zeigt. Wenn er keinen anderen MX-Record mit einer kleineren Präferenz als 5 findet, wird die Nachricht an mailhub übertragen und von dort an green versendet.

Soweit in groben Umrissen, wie MX-Records funktionieren. Weitergehende Informationen über Mail-Routing im Internet finden Sie in RFC-821, RFC-974 und RFC-1123.

Mail-Routing in der UUCP-Welt

Das Mail-Routing in UUCP-Netzen ist wesentlich komplizierter als im Internet, da die Transportsoftware selbst keinerlei Routing durchführen kann. Früher mußten deshalb alle Mail-Adressen als Bang-Pfade angegeben werden. Ein Bang-Pfad gibt eine Liste von Maschinen an, durch die eine Nachricht weitergeleitet werden muß, getrennt durch Ausrufezeichen und gefolgt vom Benutzernamen. Um einen Brief an Janet User auf einer Maschine namens moria zu richten, müßten Sie eine Adresse wie eek!swim!moria!janet angeben. Das würde die Nachricht zuerst an eek schicken, von dort an swim, danach an moria, von wo sie schließlich an janet ausgeliefert würde.

Der offensichtliche Nachteil dieser Technik ist, daß Sie dazu genötigt sind, sich wesentlich mehr über Netzwerktopologien, schnelle Verbindungen usw. zu merken als beim Routing übers Internet. Schlimmer noch, kurzfristige Veränderungen der Netzwerktopologie, wie die Entfernung von Links oder Hosts, können dazu führen, daß eine Nachricht ihr Ziel nicht erreicht, einfach weil Ihnen diese Änderung nicht bekannt ist. Zu guter Letzt müssen Sie sich im Falle eines Umzugs höchstwahrscheinlich alle Routen neu zusammensuchen.

Ein wichtiger Grund, der Source-Routing notwendig machte, waren mehrdeutige Hostnamen. Angenommen, es gäbe zwei Systeme namens moria — eins in den USA, das andere in Frankreich, dann stellt sich die Frage: Auf welches bezieht sich nun die Adresse moria!janet? Die Angabe eines Pfades zu moria kann hier eine klare Zuordnung schaffen.

Der erste Schritt in Richtung eindeutiger Hostnamen war die Gründung des UUCP Mapping Project. Es ist an der Rutgers University (USA) zu Hause und registriert alle offiziellen UUCP-Systeme mitsamt Informationen über die UUCP-Nachbarn jedes Systems und ihrer geographischen Position und stellt sicher, daß kein Name doppelt belegt wird. Die vom Mapping Project gesammelten Informationen werden in den Usenet Maps veröffentlicht und regelmäßig über das Usenet verteilt. Ein typischer Systemeintrag in einer Map sieht so aus (ohne Kommentare):¹

moria         bert(DAILY/2),         swim(WEEKLY)

Dieser Eintrag besagt, daß moria eine Verbindung zu bert besitzt, die mindestens zweimal täglich aufgebaut wird, sowie eine mit swim, die einmal wöchentlich angerufen wird. Wir werden uns weiter unten noch etwas ausführlicher mit dem Format der Map-Dateien befassen.

Mit Hilfe der Verbindungsinformationen in den Maps können Sie automatisch den vollen Pfad von Ihrem System zu jedem beliebigen Zielsystem erzeugen. Diese Pfade werden normalerweise in einer Datei namens paths oder pathalias aufbewahrt. Angenommen, Sie können von Ihrem System aus bert über ernie erreichen, dann sähe der aus obigem Map-Schnipsel erzeugte pathalias-Eintrag für moria so aus:

moria           ernie!bert!moria!%s

Wenn Sie nun eine Mail an janet@moria.uucp schicken, wird Ihr MTA die oben gezeigte Route auswählen und die Nachricht mit dem Envelope bert!moria!janet an ernie schicken.

Eine pathalias-Datei aus den vollständigen Usenet Maps zu generieren ist allerdings kein besonders genialer Einfall. Die darin enthaltenen Informationen geben die realen Verhältnisse nur sehr ungenau wieder und sind auch nicht immer auf dem neuesten Stand. Aus diesem Grunde erzeugen nur einige der größten Hosts ihre paths-Datei aus den vollständigen UUCP-World-Maps. Die meisten beschränken sich auf Routing-Informationen über Systeme in ihrer Nachbarschaft und leiten Nachrichten an Systeme, die sich nicht in ihren Listen finden, an einen “Smart Host” weiter, der über umfangreichere Informationen verfügt. Diese Technik nennt sich Smart-Host-Routing. Systeme, die nur einen UUCP-Link haben (sogenannte Leaf-Sites), führen kein eigenes Routing durch, sondern überlassen dies ganz ihrem Smart Host.

UUCP und RFC-822

Die bis heute beste Medizin gegen Probleme beim Mail-Routing in UUCP-Netzen ist bis dato die Übernahme des Domainnamen-Systems in UUCP-Netzwerke. Natürlich können Sie über UUCP keine Name-Server befragen. Nichtsdestotrotz haben sich viele UUCP-Systeme zu kleinen Domains zusammengeschlossen, die ihr Mail-Routing untereinander abstimmen. In den Maps geben diese Domains dann ein oder zwei Maschinen als ihre Mail-Gateways bekannt, so daß nicht jede einzelne Maschine einen eigenen Map-Eintrag haben muß. Die Gateways bearbeiten alle ein- und ausgehenden Nachrichten der Domain, so daß das interne Routing für die Außenwelt vollständig unsichtbar ist.

Das funktioniert insbesondere im Zusammenspiel mit dem oben beschriebenen Smart-Host-Routing sehr gut. Nur das Gateway selbst muß über globale Routing-Informationen verfügen; kleinere Systeme kommen mit einer kleinen, handgeschriebenen paths-Datei aus, die Routen innerhalb ihrer Domain und zum Mail-Verteiler beschreibt. Selbst die Mail-Gateways brauchen jetzt nicht mehr die gesamte Routing-Information für jedes einzelne UUCP-System der Welt bereitzuhalten. Abgesehen von den gesamten Routing-Informationen ihrer eigenen Domain müssen sie sich nur noch Routen zu ganzen Domains merken. Der folgende pathalias-Eintrag beispielsweise routet alle Mail an Systeme in der Domain sub.org zum System smurf:

.sub.org        swim!smurf!%s

Eine Nachricht an claire@jones.sub.org wird mit der Envelope-Adresse smurf!jones!claire an swim gesendet.

Die hierarchische Organisation des Namensraums im DNS erlaubt es einem Mail-Server jetzt auch, spezifische Routen mit weniger spezifischen zu kombinieren. So kann zum Beispiel ein Server in Frankreich spezifische Routen für die Subdomains von fr kennen, aber Mails an die Hosts der us-Domain über einen Server in den USA routen. Auf diese Weise reduziert das domainorientierte Routing (wie diese Technik genannt wird) die Größe der Routing-Tabellen und den administrativen Aufwand.

Der größte Vorteil der Verwendung von Domainnamen in einer UUCP-Umgebung ist aber, daß Adressen nun konform zu RFC-822 sind und damit der Austausch mit dem Internet erheblich einfacher wird. Viele UUCP-Domains haben heute bereits einen direkten Link zu einem Internet-Gateway, das ihnen als Smart Host dient. Zum einen ist der Transport von Mails übers Internet wesentlich schneller, zum anderen ist die Routing-Information wesentlich zuverlässiger, da Internet-Hosts statt auf Usenet Maps auf DNS zurückgreifen können.

Um vom Internet aus erreichbar zu sein, muß eine UUCP-Domain über ihr Internet-Gateway einen MX-Record für sich bekanntgeben (MX-Records wurden oben im Abschnitt Mail-Routing im Internet beschrieben). Angenommen, moria gehört zur Domain orc­net.org und gcc2.groucho.edu dient als ihr Internet-Gateway. moria benutzt gcc2 dann als Smart Host, so daß Nachrichten an Systeme außerhalb der Domain übers Internet ausgeliefert werden. Umgekehrt gibt gcc2 einen MX-Record für *.orcnet.org bekannt und liefert alle ankommenden Mails für orcnet-Systeme an moria aus. Der Stern in *.orcnet. org ist ein Wildcard, das zu allen Hosts in dieser Domain paßt, denen kein anderer Record zugeordnet wurde. Das sollte normalerweise nur für reine UUCP-Domains zutreffen.

Das einzige verbleibende Problem ist, daß die UUCP-Transportprogramme mit voll qualifizierten Domainnamen nichts anfangen können. Die meisten UUCP-Pakete kommen nur mit Namen bis zu acht Zeichen zurecht, einige sogar mit noch weniger. Die Benutzung von nichtalphanumerischen Zeichen wie Punkten steht für die meisten sowieso außer Frage.

Aus diesem Grunde ist eine Abbildung der RFC-Namen auf UUCP-Hostnamen nötig. Diese Abbildung ist aber vollständig abhängig von der Implementierung. Eine gängige Methode, FQDNs auf UUCP-Namen abzubilden, ist die Verwendung der pathalias-Datei.

moria.orcnet.org  ernie!bert!moria!%s

Dies erzeugt aus einer Adresse, die einen voll qualifizierten Domainnamen angibt, einen reinen UUCP-Bang-Path. Einige Mail-Programme stellen hierfür eine spezielle Datei bereit; sendmail beispielsweise verwendet uucpxtable.

Beim Versenden von Nachrichten aus einem UUCP-Netz ins Internet ist manchmal die umgekehrte Vorgehensweise notwendig (auch “Domainisieren” genannt). Solange der Absender der Mail den voll qualifizierten Domainnamen in der Zieladresse verwendet, kann dieses Problem vermieden werden, indem die Mail-Software den Domainnamen nicht aus dem Envelope entfernt, sondern unverändert an den Smart Host weiterreicht. Allerdings gibt es immer noch UUCP-Systeme, die keiner Domain angehören. Sie werden in der Regel “domainisiert”, d.h. um die Pseudo-Domain uucp ergänzt.

In UUCP-Netzen stellt die pathalias-Datei die wesentliche Quelle für Routing-Informationen dar. Ein typischer Eintrag sieht so aus:

moria.orcnet.org  ernie!bert!moria!%s moria             ernie!bert!moria!%s

Hierbei sind der Systemname und die Pfadangabe jeweils durch Tabulatorzeichen ­voneinander getrennt. Dieser Eintrag bewirkt, daß Mails an moria über ernie und bert ausgeliefert werden. Sowohl der FQDN als auch der UUCP-Name von moria müssen angegeben werden, wenn der Mailer keine andere Möglichkeit hat, diese Namen aufeinander abzubilden.

Wenn Sie alle Nachrichten an die Hosts innerhalb einer Domain an deren Mail-Exchanger delegieren wollen, können Sie in einer pathalias-Datei auch einen Pfad eintragen, indem Sie den Domainnamen mit vorangestelltem Punkt als Ziel angeben. Wenn zum Beispiel alle Systeme in sub.org über swim!smurf erreichbar sind, könnte der pathalias-Eintrag so aussehen:

.sub.org        swim!smurf!%s

Das Schreiben einer pathalias-Datei ist aber nur zumutbar, wenn Ihr System selbst nicht viel Routing vornehmen muß. Wenn Sie Routing für eine große Anzahl von Systemen durchführen müssen, ist es angebracht, die Pfade mit dem Programm pathalias aus Map-Dateien zu generieren. Maps lassen sich viel leichter auf dem neuesten Stand halten, da Sie ein System einfach dadurch hinzufügen oder entfernen können, indem Sie seinen Map-Eintrag editieren und die Pfadinformationen neu erzeugen lassen. Obwohl die vom Usenet Mapping Project veröffentlichten Maps kaum noch fürs Routing benutzt werden, ist es für kleinere Netze durchaus noch sinnvoll, ihre Routing-Informationen über ihre eigenen Maps auszutauschen.

Eine Map-Datei besteht hauptsächlich aus einer Liste von Systemen und ihren unmittelbaren Nachbarn. Der Systemname beginnt in Spalte eins und wird gefolgt von einer Liste von Links (mit Kommata als Trennzeichen). Die Liste kann sich über mehrere Zeilen erstrecken, wenn die Fortsetzungszeilen mit einem Tabulatorzeichen beginnen. Jede Link-Angabe besteht aus dem Namen des Nachbarsystems und den in Klammern angegebenen “Kosten” des Links. Bei diesen Kosten handelt es sich um arithmetische Ausdrücke aus Zahlen und Symbolen wie DAILY oder WEEKLY. Zeilen, die mit einem Doppelkreuz (#) beginnen, sind Kommentare und werden ignoriert.

Betrachten wir moria, das zweimal täglich eine Verbindung zu swim.twobirds.com aufbaut und einmal pro Woche mit bert.sesame.com. Die Verbindung zu bert verwendet ein langsames 2.400-Bps-Modem. morias Map-Eintrag sähe dann so aus:

moria.orcnet.org         bert.sesame.com(DAILY/2),         swim.twobirds.com(WEEKLY+LOW) moria.orcnet.org = moria

Die letzte Zeile macht moria auch unter dessen UUCP-Namen bekannt. Beachten Sie, daß es tatsächlich DAILY/2 heißen muß, da zwei Anrufe täglich die Kosten für diesen Link halbieren.

Anhand der Informationen aus solchen Map-Dateien kann pathalias optimale Wege zu jedem in der paths-Datei aufgeführten System berechnen und daraus eine pathalias-Datei erzeugen, die direkt für das Routing zu diesen Systemen verwendet werden kann.

pathalias stellt daneben noch eine ganze Reihe anderer Features bereit, wie das “Verstecken” einer Reihe von Systemen hinter einem Gateway (engl. site hiding). Details hierzu entnehmen Sie bitte der Manpage pathalias. Dort finden Sie auch eine vollständige Liste der Link-Kosten.

Die Kommentare in einer Map-Datei enthalten im allgemeinen zusätzliche Informationen über die beschriebenen Systeme. Diese Angaben müssen in einem sehr rigiden Format gemacht werden, so daß sie später automatisch weiterverarbeitet werden können. So benutzt zum Beispiel das Programm uuwho eine aus Map-Dateien erzeugte Datei, um diese Informationen in einem übersichtlichen Format anzuzeigen. Wenn Sie Ihr System bei einer Organisation registrieren lassen, die Map-Dateien an ihre Mitglieder verteilt, müssen Sie in der Regel immer einen solchen Map-Eintrag ausfüllen. Nachfolgend ein Beispieleintrag (tatsächlich ist es der für Olafs System):

#N      monad, monad.swb.de, monad.swb.sub.org #S      AT 486DX50; Linux 0.99 #O      private #C      Olaf Kirch #E      okir@monad.swb.de #P      Kattreinstr. 38, D-64295 Darmstadt, FRG #L      49 52 03 N / 08 38 40 E #U      brewhq #W      okir@monad.swb.de (Olaf Kirch); Sun Jul 25 16:59:32 MET DST 1993 # monad   brewhq(DAILY/2) # Domains monad = monad.swb.de monad = monad.swb.sub.org

Der Leerraum nach den ersten zwei Zeichen ist ein Tabulatorzeichen. Die Bedeutung der meisten Felder ist recht offensichtlich; eine detaillierte Beschreibung erhalten Sie dort, wo Sie sich haben registrieren lassen. Den größten Spaß macht es, das Feld L auszufüllen: Es gibt Ihre Position in geographischer Länge und Breite an und wird dazu benutzt, die Postscript-Karten zu erzeugen, die die Usenet-Systeme für jedes Land bzw. weltweit zeigen.²

Weitere Informationen zum Linux - Wegweiser für Netzwerker

Weitere Online-Bücher & Probekapitel finden Sie in unserem Online Book Center