Copyright © 1996 by O'Reilly/International Thomson Verlag

Bitte denken Sie daran: Sie dürfen zwar die Online-Version ausdrucken, aber diesen Druck nicht fotokopieren oder verkaufen.

Wünschen Sie mehr Informationen zu der gedruckten Version des Buches "Linux: Wegweiser durch das Netzwerk" dann klicken Sie hier.


Kapitel 13
Elektronische Post

Die Idee, persönliche Botschaften über Computernetze auszutauschen, ist so alt wie die ersten Netze selber. E-Mail (vom englischen electronic mail) begann als sehr primitiver Dienst, der einfach eine Datei von einer Maschine auf eine andere transportierte und an die mailbox-Datei der Empfängerin anhängte. Dieses Prinzip hat sich im wesentlichen bis heute nicht geändert. Allerdings haben ein stetig wachsendes Netz mit seinen komplexen Anforderungen an das Routing und die ständig zunehmende Zahl der übertragenen Botschaften ein ausgefeilteres Konzept nötig gemacht.

Heute existiert eine ganze Reihe von Standards für den Transport elektronischer Post. Internet-Sites verwenden ein Format, das ursprünglich in RFC 822 definiert, aber seitdem um mehrere Einzelheiten wie die maschinenunabhängige Übertragung von Sonderzeichen wie Umlauten ergänzt wurde. In jüngster Zeit wurde auch viel Grips auf sogenannte Multimedia-Mail verwandt. Hinter diesem Schlagwort versteckt sich die Übertragung von Bildern und Sound in Mail-Botschaften. Ein anderer, von RFC 822 unabhängiger Standard wurde von der CCITT in X.400 festgelegt.

Für Unix-Systeme steht eine ganze Reihe von Software für den Transport von E-Mail bereit. Eins der bekanntesten Programme ist das an der Universität Berkeley entwickelte sendmail, das auf einer ganzen Reihe von Plattformen zum Einsatz kommt. sendmail wurde ursprünglich von Eric Allman entwickelt, dann aber von verschiedenen Firmen und Institutionen weitergepflegt. Eine recht bekannte Version ist sendmail-5.56c, die auch in Kapitel 15, Sendmail+IDA beschrieben wird. Seit kurzem arbeitet Eric Allman wieder an einer neuen Version von sendmail, dem sogenannten sendmail V8. Der derzeit aktuelle Sproß dieser neuen Generation ist sendmail-8.6.5.

Der unter Linux am häufigsten benutzte Mail-Transport ist sicherlich smail-3.1.28, geschrieben von Curt Landon Noll und Ronald S. Karr, und findet sich in nahezu allen Linux-Distributionen. Im folgenden werden wir kurz und bündig von smail, Kapitel 14, SMAIL zum Laufen bringen, sprechen; es gibt allerdings andere (ältere) smail-Inkarnationen, mit denen Version 3.1.28 unter keinen Umständen verwechselt werden sollte. Diese alten Versionen haben mit der hier genannten Version wenig mehr als den Namen gemein.

Verglichen mit sendmail ist smail verhältnismäßig jung. Solange es darum geht, Mail für eine kleinere Site mit geringem Aufkommen und einfachem Routing zu bewältigen, unterscheiden sich beide kaum. Beim Einsatz auf größeren Sites ist sendmail allerdings deutlich überlegen, da seine Konfiguration wesentlich flexibler ist.

Sowohl smail als auch sendmail werden durch eine Reihe von Konfigurations-Dateien gesteuert, die an die lokalen Verhältnisse angepaßt werden müssen. Abgesehen von Informationen, die nötig sind, um das lokale Mail-System zum Fliegen zu bringen (wie beispielsweise der Rechnername), lassen sich eine ganze Reihe weiterer Parameter einstellen. sendmails Konfigurations-Datei ist zu Anfang völlig unverständlich (vorsichtig ausgedrückt): Die Datei sieht in etwa so aus, als sei Ihre Katze über die Tastatur spaziert, während sie die Shift-Taste gedrückt hielten. smails Konfigurations-Dateien sind dagegen klarer strukturiert und einfacher zu verstehen, lassen Ihnen dafür allerdings nicht so viele Möglichkeiten, das Verhalten des Programms an Ihre Bedürfnisse anzupassen. Trotzdem ist der Aufwand, den Sie treiben müssen, um eine kleinere UUCP- oder Internet-Site einzurichten, in ungefähr derselbe.

In diesem Kapitel werden wir uns zunächst mit den Aufgaben beschäftigen, die auf Sie als Administrator zukommen. Die Kapitel 14, smail zum Laufen bringen und Kapitel 15, Sendmail+IDA geben dann nähere Anleitungen zur Installation von smail und sendmail. Mit Hilfe dieser Kapitel sollten Sie anschließend in der Lage sein, kleinere Sites einzurichten. Das ist natürlich noch lange nicht alles; wenn Sie wollen, können Sie Stunden um Stunden vor Ihrem Computer damit verbringen, die exotischsten Dinge zu konfigurieren. Aber so weit wollen wir hier nicht gehen.

Gegen Ende dieses Kapitels werden wir uns kurz mit der Einrichtung von elm beschäftigen, einem unter Unix -- und Linux --- sehr beliebten Benutzerprogramm für E-mail.

Weitere Informationen zum Thema elektronische Post finden Sie im Electronic Mail-HOWTO von Vince Skahan, das auf den einschlägigen FTP-Sites zu haben ist. Daneben enthalten die Quellkode-Distributionen von elm, smail und sendmail sehr ausführliche Dokumentationen, die die meisten Ihrer Fragen zur Konfiguration, Zucht und Pflege dieser Programme beantworten sollten. Wenn Sie nach Informationen über E-Mail im allgemeinen suchen, finden Sie in der Bibliographie am Ende des Buches eine Liste relevanter RFCs.

Was ist denn nun eine Mail?

Ein elektronischer Brief besteht zunächst aus dem Rumpf der Nachricht, also dem von Ihnen geschriebenen Text, und speziellen Daten, die die Empfänger angeben, den Absender, das Transportmedium usw., ganz ähnlich dem, was Sie sehen, wenn Sie einen normalen Briefumschlag anschauen.

Diese administrativen Daten lassen sich in zwei Kategorien unterteilen; In die erste Kategorie fallen alle Daten, deren Format vom Transportmedium abhängt, wie z. B. die Adresse des Absenders und Empfängers. Man spricht deshalb auch vom Briefumschlag, dem envelope. Diese Daten können von der Transport-Software transformiert werden, während sie die Botschaft weiterreicht.

Die zweite Sorte umfaßt alle Informationen, die von jedwedem Transportmechanismus unabhängig sind. Dazu gehören beispielsweise die Betreff-Zeile (engl. subject), die Liste aller Empfänger sowie Datum und Uhrzeit, wann die Botschaft abgeschickt wurde. In den meisten Netzen hat es sich eingebürgert, diese Informationen vor der eigentlichen Botschaft als Briefkopf anzufügen. Dieser Kopf oder mail header ist vom Rumpf oder mail body der Botschaft durch eine Leerzeile getrennt.(1)

Die meiste Mail-Software in der UNIX-Welt verwendet ein Header-Format, das in RFC 822 beschrieben wird. Sein ursprünglicher Zweck war es, einen Standard für das ARPANET zu schaffen. Dank seiner Unabhängigkeit von irgendeiner bestimmten Netzwerk-Umgebung ist RFC 822 auch von anderen Netzen übernommen worden, einschließlich vieler UUCP-basierter Netze.

RFC 822 ist allerdings nur der größte gemeinsame Nenner. In jüngerer Zeit sind verschiedene Standards entwickelt worden, die den wachsenden Bedarf an Dingen wie Verschlüsselung, Unterstützung für internationale Zeichensätze und Multimedia (MIME -- multi-media mail extensions) befriedigen sollen.

Alle diese Standards gehen davon aus, daß ein Mail-Header aus mehreren Zeilen besteht, getrennt durch Newline-Zeichen. Eine Zeile setzt sich jeweils aus einem Feldnamen zusammen, der in Spalte eins beginnt, und dem Feld selbst, das durch einen Doppelpunkt und ein Leerzeichen von Feldnamen abgesetzt ist. Das Format und die Bedeutung der einzelnen Felder variiert abhängig vom Feldnamen. Ein Feld kann in jedem Fall mehrere Zeilen fortgesetzt werden, wenn die nächste Zeile mit einem Leerzeichen (Blank oder TAB) beginnt. Die Reihenfolge der Felder spielt keine Rolle.

Ein typischer Mail-Header sieht so aus:

   From brewhq.swb.de!ora.com!andyo Wed Apr 12 00:17:03 1995
   return-Path: <brewhq.swb.de!ora.com!andyo>
   Received: from brewhq.swb.de by monad.swb.de with uucp
           (Smail3.1.28.1 #6) id m0pqqlT-00023aB; Wed, 12 Apr 95 00:17 MET DST
   Received: from ora.com (ruby.ora.com) by brewhq.swb.de with smtp
           (Smail3.1.28.1 #28.6) id <m0pqoQr-0008qhc>; Tue, 11 Apr 95 21:47 MEST
   Received: by ruby.ora.com (8.6.8/8.6.4) id RAA26438; Tue, 11 Apr 95 15:56 -0400
   Date: Tue, 11 Apr 1995 15:56:49 -0400
   Message-Id: <199404121956.PAA07787@ruby>
   From: andyo@ora.com (Andy Oram)
   To: okir@monad.swb.de
   Subject: Re: Your RPC section
Im Normalfall werden alle notwendigen Einträge im Kopf der Mail von Ihrem Mailprogramm wie elm, pine, mush oder mailx generiert. Einige sind optional und können vom Benutzer angefügt werden. elm erlaubt Ihnen beispielsweise, einen Teil des Headers zu editieren. Andere Felder werden von der Transport-Software angefügt. Hier ist eine Liste der wichtigsten Header-Einträge und ihrer Bedeutung:
From:
Dieses Feld enthält die E-Mail-Adresse des Absenders und den »richtigen« Namen. Ein ganzer Zoo an Formaten ist hier erlaubt.
To:
Dies gibt die E-Mail-Adresse des Empfängers an.
Subject:
Beschreibt den Inhalt der Nachricht in einigen Worten. Zumindest sollte es das tun.
Date:
Datum und Uhrzeit, zu denen die Nachricht abgeschickt wurde.
Reply-To:
Dieses Feld ist optional und gibt eine alternative Adresse an, wenn Antworten auf diese Mail an eine andere als die ursprüngliche Adresse des Absenders gehen sollen. Das ist beispielsweise nützlich, wenn Sie verschiedene Accounts besitzen, aber den allergrößten Teil Ihrer Mail auf dem am häufigsten genutzten empfangen wollen.
Organization:
Die Organisation, der der Rechner gehört, von der die Nachricht verschickt wurde. Wenn es Ihr eigener Rechner ist, lassen Sie das Feld einfach leer, tragen Sie »private« ein oder einen völligen Unsinn. Auch dieses Feld ist optional.
Message-ID:
Eine eindeutige Kennung, die von der Transport-Software des Absendersystems erzeugt wurde. Sie dient dazu, die Nachricht beispielsweise in Log-Dateien eindeutig identifizieren zu können.
Received:
Jedes System, das eine Mail bearbeitet (einschließlich der Maschinen von Absender und Empfänger) fügt ein solches Feld in den Header ein, das den Namen des Systems angibt, Datum und Uhrzeit, zu der die Nachricht bearbeitet wurde, von welchem System sie kam und an welches sie weitergereicht wurde. Mit dieser Information können Sie, wenn nötig, die Route zurückverfolgen, die eine Nachricht genommen hat, und im Notfall feststellen, wo das Problem liegt, wenn eine Mail einmal unzustellbar sein sollte.
X-irgendwas:
Mail-Software sollte sich niemals über Header-Zeilen beschweren, die mit X- anfangen. Feldnamen dieser Art können dazu benutzt werden, zusätzliche Dienste zu implementieren, die noch kein Internet-Standard sind und es vielleicht auch niemals werden. Dies wird beispielsweise von der Linux Activists Mailing-Liste ausgenutzt, wo von mehreren sogenannten »Channels« durch das X-Mn-Key: Header-Feld ausgewählt werden kann.

Die einzige Ausnahme von dieser Struktur ist die allererste Zeile. Sie beginnt mit dem Schlüsselwort From, gefolgt von einem Leerzeichen anstelle eines Doppelpunktes. Um es deutlich vom From:-Feld zu unterscheiden, werden wir es im folgenden immer als From_ bezeichnen. Dieses Feld enthält unter anderem die Route, die die Mail genommen hat, in Bang Path-Notation (wird später erklärt) und die Uhrzeit des Empfangs. Das Feld wird von jeder Maschine, die die Nachricht bearbeitet, regeneriert und wird deshalb oft dem Envelope zugeordnet.

Das From_-Feld dient der Rückwärts-Kompatibilität mit älteren Mail-Programmen und wird kaum noch benutzt. Eine Ausnahme bilden Benutzerprogramme wie elm, die anhand dieses Felds den Anfang der Nachrichten in der Mailbox-Datei erkennen. Um möglichen Problemen vorzubeugen, hat es sich eingebürgert, Zeilen im Rumpf der Nachricht, die auch mit »From« beginnen, durch ein vorangestelltes »>« zu schützen.

Wie wird Mail transportiert?

Für gewöhnlich werden Sie Ihre elektronischen Briefe mit Hilfe von Programmen wie mail oder mailx schreiben oder mit etwas komfortableren wie elm, mush oder pine. Diese Programme werden im Englischen als mail user agents bezeichnet (agent heißt Werkzeug) und MUA abgekürzt. Wenn Sie eine Nachricht abschicken, wird sie von Ihrem Benutzerprogramm an ein anderes Programm weitergereicht, das den Transport zum Zielsystem übernimmt. Dieses Programm heißt mail transport agent, kurz MTA. Auf manchen Systemen gibt es je ein Transportprogramm für die lokale Auslieferung und den Transport übers Netz; auf anderen Systemen übernimmt ein Programm beide Aufgaben.

Die Auslieferung einer Mail an einen lokalen Benutzer umfaßt natürlich mehr, als sie nur an die Mailbox-Datei des Benutzers anzuhängen. Normalerweise muß sich der lokale MTA um Aliase (lokale Empfänger, die in Wirklichkeit auf andere Adressen verweisen) und Forwarding (Umleiten aller Mail für einen Benutzer auf ein anderes System oder einen anderen Account) kümmern. Außerdem müssen nicht zustellbare Mails mitsamt einem Fehlerreport an den Absender zurückgesandt werden; im Englischen wird dieser Vorgang als bouncing bezeichnet und die generierte Fehlermeldung als bounce mail.

Bei der Auslieferung über ein anderes System hängt es ganz von der Art der Netzverbindung ab, welche Transport-Software verwendet wird. Wird die Nachricht über ein TCP/IP-basiertes Netz weitergereicht, wird für gewöhnlich SMTP verwendet. SMTP steht für Simple Mail Transfer Protocol, und wird in RFC 788 und RFC 821 definiert. SMTP baut im allgemeinen eine direkte Verbindung zum Zielrechner auf und überträgt die Nachricht an den SMTP-Dämon der anderen Seite.

In UUCP-Netzen kann Mail dagegen nicht direkt ausgeliefert werden, sondern wird von einer Reihe von Zwischensystemen bis zum Zielrechner weitergereicht. Um eine Nachricht über einen einzelnen UUCP-Link weiterzureichen, ruft der sendende MTA auf dem Nachbarsystem mit Hilfe von uux das Programm rmail auf und übergibt ihm die Nachricht auf der Standardeingabe.

Da dies für jede Nachricht separat geschieht, kann es auf größeren Mailverteilern zu einer beträchtlichen Arbeitslast kommen und gleichzeitig die UUCP-Spoolverzeichnisse mit Hunderten kleiner Dateien füllen, die überdurchschnittlich viel Plattenplatz belegen.(2) Einige MTAs erlauben Ihnen darum, mehrere Nachrichten, die an dasselbe System weitergereicht werden sollen, in einer Batch-Datei zu sammeln. Diese Batch-Datei enthält die SMTP-Befehle, die der lokale MTA normalerweise ausgeben würde, wenn eine echte SMTP-Verbindung benutzt würde. Diese Technik nennt sich BSMTP, oder batched SMTP. Der fertige Batch wird dann auf dem anderen System an das Programm rsmtp oder bsmtp verfüttert, das die Eingabe verarbeitet, als ob eine normale SMTP-Verbindung vorläge.

E-Mail-Adressen

Eine Adresse für elektronische Mail enthält mindestens den Namen der Maschine, die die Mail des Empfängers bearbeitet, sowie eine Benutzer-Identifikation, die von diesem System erkannt wird. Das ist häufig der Login-Name des Benutzers, kann aber auch etwas völlig anderes sein. Andere Adressierungsmethoden wie X.400 verwenden einen allgemeineren Satz von »Attributen« wie Land und Organisation, aus denen mit Hilfe eines X.500 Directory-Servers das Empfängersystem ermittelt wird.

Die Interpretation eines Rechnernamens, d. h. auf welchem System Ihre Mail am Ende auftauchen wird, und wie dieser Name mit dem Empfängernamen verknüpft wird, hängt stark davon ab, in was für einem Netz Sie sich befinden.

Internet-Systeme halten sich an den Standard RFC 822, der die Schreibweise user@host.domain verlangt, wobei host.domain der voll qualifizierte Domainname des Zielsystems ist. Das Ding in der Mitte heißt im Deutschen Klammeraffe; der englische Name »at« macht einem eher begreiflich, wieso es als Trennsysmbol gewählt wurde. Da diese Notation nur den Rechnernamen, aber keine Routing-Information angibt, wird diese Form auch gelegentlich als absolute Adresse bezeichnet.

In der ursprünglichen UUCP-Umgebung war die vorherrschende Form path!host!user, wobei path die Reihenfolge der Systeme beschrieb, die die Nachricht zu passieren hatte, bevor sie das Zielsystem host erreichte. Die im Pfad angegebenen Systeme werden untereinander ebenfalls durch Ausrufezeichen getrennt. Diese Angabe einer Route nennt sich bang path, da im Amerikanischen ein Ausrufezeichen auch manchmal »bang« genannt wird. Heute haben viele UUCP-basierte Netze RFC 822 angenommen und verstehen auch die RFC-Adressen.

Diese zwei Arten der Adressierung lassen sich allerdings nicht gut mischen. Betrachten Sie die Adresse hostA!user@hostB. Es ist nicht ohne weiteres klar, ob das &guilsinglright;@&guilsinglleft;-Zeichen Vorrang vor der Pfadangabe hat, oder umgekehrt: Schicken wir die Nachricht zuerst an hostB, von wo sie an hostA!user weitergereicht wird, oder muß sie an System hostA geschickt werden, das sie an user@hostB sendet?

Solche Adressen, die zwei Typen von Adreßoperatoren vermischen, werden hybride Adressen genannt. Das oben genannte Beispiel ist das berüchtigste und wird im allgemeinen dadurch gelöst, daß dem @-Zeichen eine höhere Präzedenz eingeräumt wird. Die Mail würde also zuerst an hostB geschickt.

Allerdings sieht auch RFC 822 eine Möglichkeit vor, Routen anzugeben: <@hostA,@hostB:user@hostC> ist die Adresse von user auf hostC, wobei hostC durch hostA und hostB (in dieser Reihenfolge) erreicht werden kann. Dies wird oft als route-addr-Adresse bezeichnet.

Dann ist da noch der &guilsinglright;%&guilsinglleft;-Operator: Eine Mail an user%hostB@hostA wird zuerst an hostA geschickt, das das am weitesten stehende (und in diesem Falle einzige) Prozentzeichen durch ein &guilsinglright;@&guilsinglleft;-Zeichen ersetzt. Die Adresse lautet nun user@hostB, und das Mail-System wird sie nun fröhlich an hostB weiterreichen, das sie an user ausliefert. Diese Art der Adressierung wird manchmal als »Ye Olde ARPANET kludge« bezeichnet, und von ihrer Verwendung wird dringend abgeraten. Viele Mail-Transportprogramme erzeugen sie trotzdem.

Andere Netze haben noch ganz andere (und oft nicht weniger barocke) Adressierungsmöglichkeiten. Auf DECnet basierende Netze benutzen beispielsweise zwei Doppelpunkte als Trennzeichen, was Adressen der Form host::user ergibt.(3)

Im FidoNet wird jeder Benutzer durch einen Kode wie 2:320/204.9 identifiziert, der aus vier Zahlen besteht, die die Zone bezeichnen (2 für Europa), das Netz (320 für Paris und Banlieue), den Knoten (der lokale Mailverteiler), und den sogenannten Point (der PC des Benutzers). FidoNet-Adressen können auf RFC 822-Adressen abgebildet werden; die obige würde als Thomas.Quinot@p9.f204.n320.z2.fidonet.org geschrieben werden. Sagte ich nicht, daß Domainnamen einfach zu merken sind?

Aus den unterschiedlichen Adressierungsarten ergeben sich einige Implikationen für die Mail-Software, die wir im folgenden diskutieren werden. Lassen Sie sich dadurch aber nicht abschrecken; in einer RFC 822-Umgebung werden Sie selten etwas anderes als absolute Adressen wie user@host.domain verwenden.

Wie funktioniert Mail-Routing?

Eine zentrale Aufgabe eines MTA ist herauszufinden, wie eine gegebene Nachricht zum Zielsystem transportiert werden kann. Dieser Vorgang heißt Routing. Neben der Suche nach einem Pfad zum Zielsystem gehören dazu die Absicherung gegen Fehler ebenso wie Geschwindigkeits- und Kostenoptimierung.

Es gibt einen großen Unterschied in der Art und Weise, wie ein Internet-System dieses Routing-Problem löst und wie dies ein UUCP-System tut. Im Internet kann eine Nachricht meist direkt an das Zielsystem übertragen werden, da der Transport zum Zielsystem von TCP/IP transparent erledigt wird. Im UUCP-Bereich dagegen muß Ihr Mailer im schlimmsten Falle die genaue Route zum Zielsystem kennen, da die UUCP-Transportprogramme keine Möglichkeit haben, sie selbst zu generieren. Im allgemeinen bedeutet dies, daß die Route entweder vom Benutzer vorgegeben oder vom Transportprogramm selbst erzeugt werden muß.

Mail-Routing im Internet

Im Internet ist es ganz vom Zielsystem abhängig, ob ihr MTA überhaupt ein besonderes Routing vornimmt. Im Normalfall wird eine Nachricht direkt an den Zielrechner übertragen, wobei das tatsächliche Routing ganz der IP-Ebene überlassen wird.

Die meisten Systeme werden es allerdings vorziehen, daß alle eingehenden Mails von einem zentralen Server entgegengenommen und anschließend lokal verteilt werden. Um diesen Server anderen Systemen bekanntzumachen, veröffentlicht dieses System im DNS einen sogenannten MX-Record für seine Domain. MX steht für den englischen Terminus mail exchanger. Ein MX-Record besagt, daß der angegebene Server willens und in der Lage ist, Mails an die Domain anzunehmen und weiterzuleiten. MX-Records können deshalb auch dazu verwendet werden, alle Mails für eine Gruppe von Maschinen, die nicht selbst ans Internet angeschlossen sind, auf ein Gateway umzudirigieren. Typische Beispiele sind UUCP- oder firmeninterne Netze, die aus Gründen der Sicherheit vom Internet getrennt sind.

Mit einem MX-Record ist immer eine sogenannte Präferenz verbunden. Die Präferenz ist eine positive Zahl, die angibt, wie bevorzugt Nachrichten über dieses Gateway ausgeliefert werden sollen. Wenn mehrere Gateways für einen Zielrechner existieren, wird der MTA versuchen, die Nachricht an das Gateway mit dem niedrigsten Präferenzwert auszuliefern. Wenn dieser Versuch fehlschlägt, weil beispielsweise die Maschine nicht erreichbar ist, versucht der MTA, die Nachricht an das Gateway mit der nächsthöheren Präferenz auszuliefern. Ist die lokale (ausliefernde) Maschine selbst ein Mail-Exchanger für das Zielsystem, darf sie die Nachricht nur an einen MX mit niedrigerer Präferenz als ihrer eigenen ausliefern. Diese Einschränkung verhindert, daß eine Mail zwischen verschiedenen Gateways Karussell fährt.

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

foobar.com.     IN     MX     5 mailhub.foobar.com.
Das macht mailhub.foobar.com als Mail-Gateway für die Domain foobar.com mit einer Präferenz von 5 bekannt. Ein MTA, der eine Nachricht an joe@foobar.com ausliefern will, wird im DNS nach foobar.com suchen und obigen MX-Record finden. Wenn er keinen anderen MX-Record mit niedrigerer Präferenz findet, wird er die Nachricht an mailhub übertragen, das sienun innerhalb der Firma an joe ausliefert.

Soweit in groben Umrissen, wie der MX-Mechanismus funktioniert. Weitergehende Informationen über das Mail-Routing im Internet finden Sie in RFC 974.

Mail-Routing in der UUCP-Welt

Soweit war ja alles noch recht einfach. Das Mail-Routing in UUCP-Netzen ist allerdings wesentlich komplizierter als im Internet, da die Transport-Software alleine 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, würden Sie eine Adresse wie eek!swim!moria!janet angeben müssen. Das würde die Nachricht zuerst an eek schicken, von dort an swim und schließlich an moria, wo sie an janet ausgeliefert würde.

Der offensichtliche Nachteil dieser Technik ist, daß Sie dazu genötigt sind, sich viel über die Netztopologie zu merken, wie beispielwsweise schnelle und zuverlässige Verbindungen etc. Schlimmer noch, kurzfristige Veränderungen der Netztopologie wie die Entfernung eines Links oder einer Maschine 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 alle Routen neu zusammensuchen.

Ein wichtiger Grund für die Verwendung solch Absender-abhängiger Adressen (der englische Begriff lautet source routing) war, daß Maschinennamen oft nicht eindeutig waren: Nehmen Sie an, es gäbe zwei Systeme namens moria; eins in den USA, das andere in Frankreich -- auf welches bezieht sich nun die Adresse moria!janet? Die Angabe eines Pfades kann hier eine klare Zuordnung schaffen.

Der erste Schritt in Richtung eindeutiger Systemnamen war die Gründung des UUCP Mapping Project. Das Projekt 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 regeläßig in den Usenet Maps veröffentlicht und durch das Usenet verteilt.(4)

Ein typischer Map-Eintrag sieht nach der Entfernung der Kommentare so aus:

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, mit dem es einmal wöchentlich Mail austauscht. 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 schicken, wird Ihr MTA die oben gezeigte Route auswählen und die Nachricht mit einer Envelope-Adresse von bert!moria!janet an ernie schicken.

Es ist allerdings keine besonders gute Idee, eine pathalias-Datei aus den kompletten Usenet Maps zu generieren. Die darin enthaltenen Link-Bewertungen geben die realen Verhältnisse nur sehr ungenau wieder und sind auch nicht immer auf dem neuesten Stand. Aus diesem Grunde erzeugen nur einige sehr große Sites wie uunet ihre paths-Datei aus den vollen 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 ein intelligenteres System mit vollständigeren Informationen weiter. Diese Technik heißt im Englischen smart-host routing. Sie ist besonders nützlich für Systeme, die nur einen UUCP-Link haben; solche Systeme brauchen sich dann überhaupt nicht mehr um ein intelligentes Routing zu kümmern, sondern überlassen die ganze Arbeit ihrem Smart Host.

UUCP und RFC 822

Die bis heute beste Medizin gegen die Probleme des Mail-Routings in UUCP-Netzen ist die Übernahme von Domainnamen aus dem DNS. Natürlich können Sie über UUCP einen Name-Server nicht nach der optimalen Route zu einem UUCP-System befragen. Trotzdem schließen sich die meisten UUCP-Systeme in Domains zusammen, die ihr Mail-Routing untereinander abstimmen. In den Maps publizieren diese Domains dann ein oder zwei Maschinen als ihre Mail-Gateways, so daß nicht jede einzelne Maschine einen eigenen Map-Eintrag haben muß. Die Gateways bearbeiten alle ein- und ausgehenden Nachrichten, so daß das interne Routing vor der Außenwelt verborgen bleiben kann.

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 der Domain beschreibt. Alle anderen Mails werden an das Gateway weitergereicht. Selbst die Mail-Gateways brauchen jetzt nicht mehr die gesamte Routing-Information für jedes einzelne UUCP-System der Welt bereitzuhalten. Abgesehen von den Informationen über die Topologie 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 nun mit einem Envelope vom smurf!jones!claire an swim weitergereicht werden.

Die hierarchische Organisation des Namensraums im DNS erlaubt es einem Gateway jetzt auch, spezifische Routen mit weniger spezifischen zu mischen. Zum Beispiel kannte seinerzeit das System unido in Dortmund alle Routen für UUCP-Domains in Deutschland, aber routete alle Mail an Systeme unterhalb der Domain nl (Niederlande) über das System iafnl.iaf.nl. Auf diese Art und Weise reduziert das domainorientierte Routing (wie diese Technik genannt wird) sowohl die Größe der Routing-Tabellen als auch den administrativen Aufwand erheblich.

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-System, das als ihr Relay-System dient. Einerseits ist nämlich der Transport von Mails übers Internet wesentlich schneller, andererseits ist die Routing-Information wesentlich zuverlässiger, da das Gateway anstelle der Maps auf DNS zurückgreifen kann.

Um vom Internet aus erreichbar zu sein, muß eine UUCP-Domain einen MX-Record einrichten lassen, der auf ihr Internet-Gateway zeigt (MX-Records wurden oben im oberen Abschnitt beschrieben). Nehmen Sie beispielsweise an, moria gehöre zur Domain orcnet.org und gcc2.groucho.edu diene als ihr Internet-Gateway. moria wird gcc2 dann als seinen Smart Host benutzen, so daß Nachrichten an Systeme außerhalb der Domain übers Internet ausgeliefert werden. Umgekehrt ist gcc2 als Mail-Exchanger für orcnet.org eingetragen und liefert alle einkommenden Mails an orcnet-Systeme über UUCP in die Domain aus.

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

Aus diesem Grunde ist eine Abbildung der RFC-Namen auf UUCP-Namen nötig. Unterschiedliche Mail-Pakete gehen dieses Problem aber unterschiedlich an; eine gängige Methode ist, hierfür die pathalias-Datei zu benutzen.

moria.orcnet.org     ernie!bert!moria!%s
Dies erzeugt aus einer Adresse, die den Domainnamen enthält, einen reinen UUCP-Bang-Pfad. Andere Mail-Programme benutzen hierfür spezielle Dateien; sendmail beispielsweise verwendet eine Datei namens uucpxtable.

Beim Versenden von Nachrichten aus einem UUCP-Netz ins Internet ist manchmal die umgekehrte Umsetzung 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 das Gateway weiterreicht. Allerdings gibt es immer noch UUCP-Sites, die keiner Domain angehören. Sie müssen im allgemeinen durch hybride Formen adressiert werden: Nehmen Sie an, Sie wollten von einem Internet-System aus eine Mail an big@bird schreiben und wissen, daß bird ein UUCP-Nachbar von ernie ist. Dann können Sie beispielsweise die Adresse big%bird@ernie.sesame.com verwenden.

Pfade und Landkarten

In UUCP-Netzen stellen pathalias-Dateien die wesentliche Quelle der Routing-Information dar. Dabei kann ein einzelnes System durchaus über mehrere Dateien für unterschiedliche Aufgaben verfügen, beispielsweise je eine für das Routing innerhalb der Domain und über die Domain-Grenze hinweg. Uns geht es im folgenden jedoch nur um das Format dieser Dateien. Ein typischer Eintrag sieht so aus:
moria.orcnet.org     ernie!bert!moria!
moria                ernie!bert!moria!%s
Hierbei sind der Systemname und die Pfadangabe jeweils durch TABs voneinander getrennt. Dieser Eintrag bewirkt, daß Mails an moria über ernie und bert ausgeliefert werden. Sowohl morias UUCP- als auch Domainname müssen angegeben werden, wenn der MTA keine andere Möglichkeit hat, diese Namen aufeinander abzubilden.

In einer pathalias-Datei können Sie auch Pfade für ganze Domains angeben, indem Sie den Domainnamen mit vorangestelltem Punkt als Zielsystem angeben. Wenn zum Beispiel alle Systeme in sub.org über deren Gateway smurf erreichbar sind, könnte der entsprechende 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 Mail für eine größere Zahl von Systemen verarbeiten müssen, ist es angebracht, die Pfade mit dem Programm pathalias aus einer sogenannten UUCP-Map 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 Pfade-Informationen 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 im wesentlichen aus einer Liste von Systemen und ihren unmittelbaren Nachbarn. der Systemname beginnt in Spalte eins und wird gefolgt von einer Liste von Links. Die Liste darf sich über mehrere Zeilen erstrecken, wenn die Fortsetzungszeilen mit einem TAB beginnen. Jede Link-Angabe besteht aus dem Namen des Nachbarsystems und den in Klammern angegebenen »Kosten« des Links. Diese Kosten sollen annäherungsweise beschreiben, wie schnell diese Verbindung im Vergleich zu anderen ist, so daß pathalias aus mehreren möglichen Pfaden immer den besten auswählen kann. Mit einem Doppelkreuz beginnende Zeilen sind Kommentare und werden ignoriert.

Betrachten wir moria, das zweimal täglich eine Verbindung zu swim.two.birds aufbaut und einmal pro Woche mit bert.sesame.com. Außerdem ist die Verbindung mit bert sehr langsam, da dieses System nur ein 2400bps-Modem verwendet. morias Map-Schnipsel sähe also so aus:

moria.orcnet.org
         bert.seame.com(WEEKLY+LOW),
         swim.twobirds.com(DAILY/2)  
moria.orcnet.org = moria
Die letzte Zeile macht das System auch unter seinem UUCP-Namen bekannt. Beachten Sie, daß es tatsächlich DAILY/2 heißen muß, da zwei Anrufe täglich die durchschnittliche Laufzeit einer Nachricht über diesen Link tatsächlich halbierten (ganz im Gegensatz zur Telephonrechnung).

Anhand der Informationen aus solchen Maps kann pathalias nun einen optimalen Pfad zu jedem in der Datei aufgeführten System finden und in der pathalias-Datei ablegen, die dann direkt von Ihrem MTA verwendet werden kann.

pathalias stellt daneben noch eine ganze Reihe anderer Dienste bereit, wie das »Verstecken« einer Reihe von Systemen hinter einem Gateway (engl.site hiding). Diese Fähigkeiten werden heute kaum noch benutzt. Details hierzu entnehmen Sie bitte der Manual-Seite zu pathalias ebenso wie eine vollständige Liste der symbolischen Link-Kosten.

Die Kommentare in einer Map-Datei enthalten oft noch 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. Zum Beispiel enthält die smail-Distribution Programme, um diese Informationen aufzubereiten und in lesbarer Form darzustellen.

Wenn Sie Ihr UUCP-System in den deutschen Subnet-Maps registrieren, müssen Sie solch einen Map-Schnipsel ausfüllen. Dasselbe gilt, wenn Sie Ihr System beim UUCP Mapping Project registrieren lassen wollen. Als Beispiel sei hier der Eintrag meines Linux-Systems gezeigt:

#N      monad, monad.swb.de, monad.swb.sub.org
#S      AT 486DX50; Linux 1.x
#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 1994
#
monad   brewhq(DAILY)
# Domains
monad = monad.swb.de monad = monad.swb.sub.org
Der Leerraum nach den ersten zwei Zeichen ist ein TAB. Die Bedeutung der meisten Felder ist recht offensichtlich; eine detaillierte Beschreibung wird regelmäßig in der Newsgruppe de.admin.submaps veröffentlicht. 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, um die Usenet-Systeme in verschiedenen Ländern sowie weltweit zu zeigen.(5)

Die Konfiguration von elm

elm steht für electronic mail und ist eins der eher einleuchtend benannten UNIX-Utilities. Es besitzt eine bildschirmorientierte Benutzerschnittstelle mit einer guten Hilfefunktion. Wir werden uns im folgenden nicht damit befassen, wie Sie elm bedienen, sondern uns nur mit seiner Konfiguration beschäftigen.

Theoretisch können Sie elm benutzen, ohne sich in irgendeiner Weise um die Konfiguration zu kümmern -- wenn sie Glück haben. Es gibt aber einige Optionen, die Sie unbedingt einstellen müssen, auch wenn sie selten benutzt werden.

Wenn Sie elm aufrufen, liest es verschiedene Konfigurations-Variablen aus der Datei elm.rc im Verzeichnis /usr/lib. Anschließend versucht es, .elm/elmrc in Ihrem Home-Directory zu lesen. Diese Datei schreiben Sie gewöhnlich nicht selber. elm erzeugt sie für Sie, wenn Sie die elm-Option »save options« anwählen.

Globale elm-Optionen

Alle Optionen aus der privaten Konfigurations-Datei lassen sich auch im globalen elm.rc setzen. Sie gelten dann für alle Benutzer als Voreinstellung und können von Ihnen in ihrem lokalen elmrc überschrieben werden.

Daneben hat die globale Datei aber noch eine andere, sehr wichtige Funktion. Sie enthält nämlich Optionen, die den Namen Ihres lokalen Rechners betreffen. In der Virtuellen Brauerei enthält elm.rc beispielsweise diese Zeilen:

#
# Der lokale Systemname
hostname = vlager
#
# Domainname
hostdomain = .vbrew.com
#
# Voll qualifizierter Domainname (FQDN)
hostfullname = vlager.vbrew.com
Diese Optionen legen fest, was sich elm unter dem lokalen Systemnamen vorstellt. Obwohl diese Information nur selten benötigt wird, sollten Sie diese Variablen trotzdem anpassen. Es sei darauf hingewiesen, daß diese Angaben nur wirksam werden, wenn sie in der globalen Konfigurations-Datei auftauchen; im privaten elmrc werden sie ignoriert.

Nationale Zeichensätze

In letzter Zeit hat es verschiedene Vorschläge gegeben, den RFC 822-Standard dahingehend zu erweitern, daß Mails auch andere Arten von Daten als bloßen Text enthalten können, wie zum Beispiel Postscript-Dateien, Bilder, binäre Daten etc. Die Familie der Standards und RFCs, die diese Aspekte behandelt, wird oft unter dem Begriff MIME zusammengefaßt. MIME heißt Multipurpose Internet Mail Extensions, oder Mehrzweckerweiterungen für Internet-Mail. Unter anderem kann mit einer solchen Erweiterung dem Empfänger mitgeteilt werden, ob eine Nachricht Sonderzeichen aus anderen Zeichensätzen als dem US-ASCII Standard enthält, wie zum Beispiel französische Akzente oder deutsche Umlaute. Diese Techniken werden von elm in gewissem Umfange unterstützt.

Linux verwendet zur Darstellung von Zeichen intern einen Zeichensatz namens ISO-8859-1. Dieser aparte Name ist die offizielle Bezeichnung eines ISO-Standards; umgangssprachlich ist er auch als Latin1 bekannt. Latin1 ist eine Obermenge des ASCII-Zeichensatzes und wird häufig zur Darstellung von Sonderzeichen westlicher Sprachen verwendet. Latin1 ist auch deswegen so beliebt, weil es alle Zeichen noch in 8 Bits unterbringt; andere Standards verwenden sogenannte Multi-Byte-Zeichen, bei denen ein Buchstabe oft mehrere Bytes benötigt.

Ein solcher MIME-Standard, RFC 1049, spezifiziert eine Methode, um anzuzeigen, welchen Zeichensatz der Absender benutzt hat. Eine Nachricht, die Symbole aus Latin1 verwendet, sollte im Nachrichtenkopf beispielsweise folgende Zeilen enthalten:

Content-Type: text/plain; charset=iso-8859-1 
Content-Transfer-Encoding: 8bit
Das empfangende System sollte diese Zeile auswerten und Sonderzeichen, wenn nötig, in den lokal verwendeten Zeichensatz konvertieren. Für Nachrichten vom Typ text/plain hat das Attribut charset per Voreinstellung den Wert us-ascii.

Die zweite Zeile gibt an, daß die Latin1-Zeichen direkt als 8-Bit-Werte übertragen wurden. Diese Vorgehensweise ist zwar bestechend einfach, hat aber einen großen Nachteil: Die Spezifikation von SMTP sieht nämlich vor, daß Nachrichten nur 7-Bit-Zeichen enthalten dürfen. Viele MTAs sind dieser Vorschrift bis heute auf den Buchstaben treu und löschen beim Bearbeiten jeder Nachricht jeweils das achte Bit, so daß ein ö plötzlich zu einem v mutiert usw. Dem sollen spezielle Kodierungen wie quoted-printable oder base64 Abhilfe schaffen, die 8-Bit-Zeichen in eine Folge von 7-Bit-Zeichen verschlüsseln. Mit quoted-printable wird aus einem ö beispielsweise die Folge =F6. Die Verwendung solcher speziellen Kodierungen kann im Encoding-Feld des Nachrichtenkopfes angezeigt werden. Leider werden diese Kodierungen aber nur von sehr wenigen Mail-Programmen unterstützt, so daß der Empfänger einer so behandelten Nachricht oft ratlos vor empfangenen Buchstabensalat steht.

Um Nachrichten mit anderen Zeichensätzen als US-ASCII darstellen zu können, muß elm wissen, wie es diese Zeichen ausgeben soll. Wenn es eine Mail mit einem anderen charset-Attribut als us-ascii erhält (oder einem anderen Typ als text /plain), versucht es die Nachricht von dem Programm metamail konvertieren und passend ausgeben zu lassen. Mails, die metamail benötigen, werden im Übersichts-Menü mit einem M in der ersten Spalte angezeigt.

Da Linux von Hause aus ISO-8859-1 versteht, ist es nicht nötig, Nachrichten, die Latin1 verwenden, gesondert zu behandeln. Wenn Sie folgende Option in Ihrem globalen elm.rc setzen, wird elm solche Mails direkt darstellen und auf metamail verzichten:

displaycharset = iso-8859-1
Damit ist es allerdings noch nicht getan. Wenn elm eine Nachricht mit seinem eingebauten Pager darstellt, ruft es für jedes Zeichen eine Bibliotheks-Funktion auf, um festzustellen, ob es druckbar ist oder nicht. Im Normalfall erkennt diese Funktion nur ASCII-Zeichen als druckbar an, so daß elm alle Umlaute nun als »^ ?« ausgibt. Dieses Problem räumen Sie dadurch aus der Welt, daß Sie die Umgebungsvariable LC_CTYPE auf den Wert ISO-8859-1 setzen. Das teilt der Bibliothek mit, daß sie Latin1-Buchstaben als druckbar akzeptieren soll. Die Unterstützung für diese (und verwandte Funktionen) ist seit Version 4.5.8 der C-Bibliothek vorhanden.

Wenn Sie in Ihren eigenen Mails Umlaute oder ähnliche Sonderzeichen verwenden, sollten Sie sicherstellen, daß in Ihrem elm.rc die folgenden zwei Variablen gesetzt sind:

charset = iso-8859-1
textencoding = 8bit
Das veranlaßt elm, im Content-Type-Feld des Nachrichtenkopfes das charset-Attribut auf iso-8859-1 zu setzen und alle Zeichen als 8-Bit-Werte zu übertragen. Im Normalfall löscht elm vor dem Versenden einer Mail nämlich immer das oberste Bit, was alle Sonderzeichen zerstören würde.

Fußnoten

(1)
Es ist auch üblich, eine Art Unterschrift an alle Mails anzuhängen, die Informationen über den Absender enthält, zusammen mit einem Witz oder einem Motto. Diese signature oder .sig wird vom Rest der Botschaft durch eine einzelne Zeile abgesetzt, die die Zeichen » « enthält.
(2)
Das kommt daher, daß Plattenplatz in größeren Einheiten wie 1024 Bytes alloziert wird. Dadurch verschwendet jede Mail im Durchschnitt 512 Byte Plattenspeicher.
(3)
Wenn Sie aus einem Netz mit RFC-Adressierung eine DECnet-Adresse erreichen wollen, können Sie "host::user"@relay verwenden, wobei relay ein Internet-DECnet-Gateway sein muß.
(4)
Die Maps für vom Projekt registrierte Systeme werden in der Newsgruppe comp.mail.maps gepostet. Andere Organisationen veröffentlichen unter Umständen ihre eigenen Maps. Die Liste aller deutschen UUCP-Systeme im Subnetz und im Individual Network wird über die Newsgruppe de.admin.submaps verteilt.
(5)
Sie werden regelmäßig in news.lists.ps-maps veröffentlicht. Seien Sie vorsichtig--sie sind sehr GROSS.

Inhaltsverzeichnis Kapitel 12 Kapitel 14