Suche im Katalog
Linux Netzwerker-Handbuch

Linux Netzwerker-Handbuch


Tony Bautts, Terry Dawson & Gregor N. Purdy
3. Auflage Juli 2005
ISBN 3-89721-414-8
382 Seiten
Weitere Informationen zur gedruckten Version des Buches finden Sie unter:
www.oreilly.de/catalog/linag3ger/

Zur Übersicht aller OpenBooks


TOC PREV NEXT INDEX

Kapitel 11

Elektronische Post

Das Versenden von E-Mail war schon immer eine der gebräuchlichsten Netzwerkanwendungen, seit es die ersten Netzwerke gibt. 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 des Empfängers anhängte. Dieses Prinzip hat sich im Wesentlichen bis heute nicht geändert. Allerdings haben stetig wachsende Netzwerke mit ihren komplexen Anforderungen an das Routing und die ständig zunehmende Anzahl der übertragenen Botschaften ein ausgefeilteres Konzept nötig gemacht.

Heute existiert eine ganze Reihe von Standards für den Transport von Mail. Internet-Sites verwenden ein Format, das ursprünglich im RFC 822 definiert, aber seitdem um einige RFCs erweitert wurde, die die maschinenunabhängige Übertragung von nahezu allem Möglichen beschreiben, wozu auch Grafiken, Sound-Dateien und spezielle Zeichensätze gehören.1 Der CCITT hat noch einen weiteren Standard - X.400 - definiert. Dieser wird noch in manchen großen Unternehmens- und Regierungsbereichen eingesetzt, stirbt aber langsam aus.

Für Unix-Systeme wurde eine ganze Reihe von Programmen für den Transport von E-Mail implementiert. Eines der bekanntesten ist das von Eric Allman an der Universität Berkeley entwickelte sendmail. Eric Allman vertreibt sendmail nun kommerziell, das Programm bleibt aber freie Software. sendmail wird in einigen Linux-Distributionen als Standard-Mail-Programm (Mail Transfer Agent oder MTA) eingesetzt. Auf die Konfiguration von sendmail gehen wir in Kapitel 12 näher ein.

sendmail unterstützt eine Reihe von Konfigurationsdateien, die an Ihr System angepasst werden. Abgesehen von den Informationen, die nötig sind, um das Mail-Subsystem zum Laufen zu bringen (wie etwa der lokale Hostname), gibt es viele weitere Parameter, die Sie einstellen können. Die Hauptkonfigurationsdatei von sendmail ist zu Anfang völlig unverständlich. Die Datei sieht in etwa so aus, als sei Ihre Katze über die Tastatur spaziert, während Sie die Shift-Taste gedrückt hielten. Moderne Konfigurationstechniken ersparen Ihnen glücklicherweise eine Menge Anstrengungen.

Wenn Benutzer die Mail auf ihren persönlichen Systemen beziehen wollen, brauchen sie ein weiteres Protokoll, um damit den Mailserver anzusprechen. In Kapitel 15 besprechen wir einen leistungsfähigen und zunehmend beliebter werdenden Server-Typ, nämlich IMAP.

In diesem Kapitel beschäftigen wir uns damit, was E-Mails überhaupt sind und welche Aufgaben auf die Administratoren zukommen. Kapitel 12 enthält Anweisungen zum Einrichten von sendmail. Mit Hilfe dieser Informationen sollten Sie in der Lage sein, kleinere Sites einzurichten, aber das ist natürlich noch nicht alles. Wenn Sie wollen, können Sie Stunde um Stunde vor Ihrem Computer verbringen, um die tollsten Funktionen zu konfigurieren.

Weitere Informationen zum Thema E-Mail unter Linux finden Sie im Electronic Mail HOWTO von Guylhem Aznar. Die Quellcode-Distribution von sendmail enthält ebenfalls ausführliche Dokumentationen, die die meisten Fragen bezüglich der Einrichtung des E-Mail-Dienstes beantworten sollten.

Was genau ist eine E-Mail?

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

Diese administrativen Daten lassen sich in zwei Kategorien einteilen. In die erste Kategorie fallen alle Daten, die das Transportmedium betreffen, wie z.B. die Adresse des Absenders und des Empfängers. Man spricht deshalb auch vom Briefumschlag, dem Envelope. Diese Daten können von der Transportsoftware transformiert werden, während sie die Nachricht weiterreicht.

Die zweite Sorte umfasst alle Informationen, die zur Verarbeitung der E-Mail erforderlich und von jeglichem 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 vielen Netzwerken hat es sich eingebürgert, diese Informationen der eigentlichen Nachricht als Briefkopf voranzustellen. Dieser Kopf (oder Mail Header) ist vom Rumpf (oder Mail Body) der Nachricht durch eine Leerzeile getrennt.2 Die meisten Mail-Transportprogramme in der Unix-Welt verwenden das im RFC 822 beschriebene Header-Format. Seine ursprüngliche Aufgabe bestand darin, einen Standard für die Benutzung im ARPANET vorzugeben. Da es so entworfen wurde, dass es unabhängig von irgendeiner bestimmten Netzwerkumgebung ist, wurde es leicht an andere Netzwerke angepasst, einschließlich vieler UUCP-basierter Netzwerke.

RFC 822 ist allerdings nur der kleinste gemeinsame Nenner. In jüngerer Zeit sind verschiedene Standards entwickelt worden, die die wachsenden Anforderungen, wie Verschlüsselung, Unterstützung für internationale Zeichensätze und MIME (Multipurpose Internet Mail Extensions, beschrieben im RFC 1341 und anderen RFCs), bewältigen sollen.

In all diesen Standards besteht der Mail-Header aus mehreren Zeilen, die durch Zeilenendezeichen getrennt sind. Eine Zeile setzt sich aus einem Feldnamen zusammen, der in Spalte eins beginnt, und dem Feld selbst, das durch einen Doppelpunkt und ein Leerzeichen abgesetzt ist. Das Format und die Bedeutung der einzelnen Felder hängen vom jeweiligen Feldnamen ab. Ein Header-Feld kann über eine Zeile hinaus fortgesetzt werden, wenn die nächste Zeile mit einem Leerfeld (Leerzeichen oder Tabulator) beginnt. Die Reihenfolge der Felder spielt keine Rolle.

Ein typischer Mail-Header sieht so aus:

Return-Path: <root@oreilly.com>
X-Original-To: spam@xtivix.com
Delivered-To: spam@ xtivix.com
Received: from smtp2.oreilly.com (smtp2.oreilly.com [209.58.173.10])
by www.berkeleywireless.net (Postfix) with ESMTP id B05C520DF0A
for <spam@ xtivix.com>; Wed, 16 Jul 2003 06:08:44 -0700 (PDT)
Received: (from root@localhost)
by smtp2.oreilly.com (8.11.2/8.11.2) id h6GD5f920140;
Wed, 16 Jul 2003 09:05:41 -0400 (EDT)
Date: Wed, 16 Jul 2003 09:05:41 -0400 (EDT)
Message-Id: <200307161305.h6GD5f920140@smtp2.oreilly.com>
From: Andy Oram <root@oreilly.com>
To: spam@ xtivix.com
Subject: Article on IPv6

Im Normalfall werden alle notwendigen Einträge im Header der Mail von Ihrem Mail-Programm wie elm, Outlook, Evolution oder pine generiert. Einige sind allerdings optional und können vom Benutzer angefügt werden. elm ermöglicht Ihnen beispielsweise, einen Teil des Headers zu bearbeiten. Andere Felder werden von der Transportsoftware angefügt. Wenn Sie sich eine lokale mailbox-Datei ansehen, werden Sie vielleicht feststellen, dass jeder Mail-Nachricht eine »From«-Zeile (ohne Doppelpunkt) vorangestellt ist. Dabei handelt es sich nicht um einen RFC 822-Header, sondern dieser Header wurde von Ihrer Mail-Software nachträglich eingefügt, um anderen Programmen das Lesen der E-Mails zu erleichtern. Um mögliche Verwechslungen mit Zeilen im Rumpf der Nachricht zu vermeiden, die auch mit »From« beginnen, hat sich die Standardkonvention durchgesetzt, solchen Wörtern immer ein >-Zeichen voranzustellen.

Hier ist eine Liste geläufiger Header-Einträge mit ihrer jeweiligen Bedeutung:

From:
Dieses Feld enthält die E-Mail-Adresse des Absenders und eventuell den »richtigen« Namen. Ein ganzer Zoo von Formaten kommt hier zum Einsatz, da fast jeder Mailer es anders macht.
To:
Eine Liste von E-Mail-Adressen der Empfänger. Mehrere Empfängeradressen werden durch Kommas voneinander getrennt.
Cc:
Eine Liste von E-Mail-Adressen, die »Durchschläge« (carbon copies) der Nachricht bekommen. Mehrere Empfängeradressen werden durch Kommas voneinander getrennt.
Bcc:
Eine Liste verborgener E-Mail-Adressen, die »Durchschläge« (carbon copies) der Nachricht bekommen. Der Hauptunterschied zwischen »Cc:« und »Bcc:« liegt darin, dass die in »Bcc:« aufgeführten Adressen nicht im Header der versendeten Mail-Nachrichten erscheinen. Mehrere Empfängeradressen werden durch Kommas voneinander getrennt.
Subject:
Beschreibt den Inhalt der Nachricht mit wenigen Worten.
Date:
Datum und Uhrzeit, wann die Nachricht abgeschickt wurde.
Reply-To:
Gibt die Adresse vor, an die der Empfänger seine Antwort schicken soll. Das kann nützlich sein, wenn Sie mehrere Zugänge haben, aber die meisten Mails nur auf dem Zugang empfangen wollen, den Sie am häufigsten benutzen. Dieses Feld ist optional.
Organization:
Die Organisation, der der Rechner gehört, von dem aus die Nachricht verschickt wurde. Wenn es Ihr eigener Rechner ist, lassen Sie das Feld einfach leer oder tragen »privat« oder irgendwelchen Unsinn ein. Dieses Feld wird in keinem RFC erwähnt und ist völlig optional. Manche Mail-Programme unterstützen es direkt, viele jedoch nicht.
Message-ID:
Ein String, der von der Transportsoftware des Absenders erzeugt wird. Er dient dazu, die Nachricht eindeutig zu identifizieren.
Received:
Jedes System, das Ihre Mail verarbeitet (einschließlich der Maschinen des Absenders und des Empfängers), fügt ein solches Feld in den Header ein, das den Namen des Systems angibt, eine Nachrichten-ID, Datum und Uhrzeit, zu der die Nachricht empfangen wurde, von welchem System sie kam und welche Transportsoftware benutzt wurde. Mit diesen Informationen können Sie notfalls die Route zurückverfolgen, die eine Nachricht genommen hat, und sich bei der verantwortlichen Person beschweren, falls etwas schief gegangen ist.
X-irgendetwas:
Kein Mail-Programm sollte sich jemals über einen Header beschweren, der mit X- beginnt. Er wird dazu benutzt, zusätzliche Funktionen zu implementieren, die noch kein RFC-Standard sind und es vielleicht nie werden. Zum Beispiel gab es einmal einen sehr großen Linux-Mailinglist-Server, der es Ihnen gestattet, mittels der Zeichenfolge X-Mn-Key:, gefolgt vom Kanalnamen, einen bestimmten Kanal für Ihre Mail anzugeben.

Wie wird Mail ausgeliefert?

Im Allgemeinen werden Sie Ihre E-Mails mit einem Programm wie mail oder mailx schreiben oder mit etwas Komfortablerem wie mutt, tkrat oder pine. Diese Programme werden im Englischen als Mail User Agents, abgekürzt MUAs, bezeichnet. Wenn Sie eine Nachricht abschicken, wird sie von Ihrem Benutzerprogramm in der Regel zur Auslieferung an ein anderes Programm übergeben. Dieses Programm heißt Mail Transport Agent (MTA). Auf den meisten Systemen wird ein und derselbe MTA sowohl für den lokalen als auch für den fernen Versand benutzt - üblicherweise /usr/sbin/sendmail (bzw. /usr/lib/sendmail auf nicht-FSSTND-konformen Systemen).

Die Auslieferung einer Mail an einen lokalen Benutzer umfasst natürlich mehr, als sie nur an die Mailbox-Datei des Benutzers anzuhängen. Für gewöhnlich muss sich der lokale MTA um Aliasing (die Einrichtung lokaler Empfänger-Adressen, die auf andere Adressen verweisen) und Forwarding (die Umleitung einer Benutzer-Mail auf ein anderes Ziel) 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.

Bei der Auslieferung über ein anderes System hängt es ganz von der Art der Netzwerkverbindung ab, welche Transportsoftware verwendet wird. Werden die Nachrichten über ein TCP/IP-basiertes Netzwerk zugestellt, wird üblicherweise SMTP verwendet. SMTP steht für Simple Mail Transfer Protocol und ist im RFC 821 beschrieben. SMTP wurde so entworfen, dass eine Nachricht direkt an eine Empfänger-Maschine zugestellt wird, wobei die Nachrichtenübertragung mit dem SMTP-Dämon der Gegenseite ausgehandelt wird. In Unternehmen ist es heutzutage üblich, spezielle Hosts zur Verfügung zu stellen, die alle an Empfänger im Unternehmen gerichteten Mails aufnehmen und sie ordnungsgemäß an die gewünschten Empfänger weiterleiten.

E-Mail-Adressen

E-Mail-Adressen bestehen aus mindestens zwei Teilen. Ein Teil ist die Mail-Domain, bei der es sich entweder um den Namen des Empfänger-Hosts oder um den Namen einer Maschine handelt, die die Mail im Auftrag des Empfängers bearbeitet. Der andere Teil ist eine Art eindeutige Benutzer-Identifikation, wie der Login-Name des Benutzers oder der echte Name des Benutzers im »Vorname.Nachname«-Format oder ein beliebiger Alias, der zu einem Benutzer bzw. einer Liste von Benutzern übersetzt wird. Andere Adressierungsschemata wie X.400 verwenden einen allgemeineren Satz von »Attributen«, aus denen mit Hilfe eines X.500-Directory-Servers das Empfängersystem ermittelt wird.

Wie E-Mail-Adressen interpretiert werden, hängt stark davon ab, welche Art von Netzwerk Sie benutzen. Wir konzentrieren uns darauf, wie TCP/IP-Netzwerke E-Mail-Adressen interpretieren.

RFC 822

Internet-Systeme halten sich an den RFC 822-Standard, der die übliche Schreibweise benutzer@host.domain verlangt, wobei host.domain der voll qualifizierte Domainname des Hosts ist. Das Ding in der Mitte ist ein »Klammeraffe«; der englische Name lautet »commercial at« (kurz »at«). Diese Notation gibt keine Route zum Zielhost an. Wie Mails geroutet werden, beschreiben wir in Kürze.

Veraltete Mail-Formate

Bevor wir weitermachen, wollen wir einen Blick darauf werfen, wie diese Dinge früher erledigt wurden. In der ursprünglichen UUCP-Umgebung war path!host!user die vorherrschende Form, wobei path die Reihenfolge der Systeme beschrieb, die die Nachricht zu durchlaufen hatte, bevor sie das Zielsystem host erreichte. Diese Konstruktion nennt sich Bang-Path-Notation, da im Amerikanischen ein Ausrufezeichen auch manchmal als »bang« bezeichnet wird.

Andere Netzwerke haben noch ganz andere Adressierungsmöglichkeiten. Auf DECnet basierende Netze benutzen beispielsweise zwei Doppelpunkte als Trennzeichen, was Adressen der Form host::user ergibt. Der X.400-Standard verwendet wiederum ein anderes Schema. Dort wird ein Empfänger durch eine Menge von Attribut/Wert-Paaren beschrieben, wie z. B. Land und Organisation.

Im FidoNet schließlich wird jeder Benutzer durch einen Code 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 Mail-Verteiler) und den so genannten 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. Sind wir da nicht froh, dass wir heutzutage einfache Domainnamen haben?!

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 eine Fehlerprüfung sowie Geschwindigkeits- und Kostenoptimierung.

Im Internet wird die Hauptarbeit beim Datentransport an den Empfänger (sofern seine IP-Adresse bekannt ist) von der IP-Netzwerkschicht erledigt.

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 die Nachricht danach direkt an diesen Host zugestellt wird. Die meisten Internet-Sites werden es allerdings vorziehen, dass alle eingehenden Mails von einem zentral verfügbaren Server entgegengenommen und lokal verteilt werden. Um diesen Dienst bekannt zu machen, veröffentlicht die Site im DNS einen so genannten MX-Record für ihre lokale Domain. MX steht für den englischen Begriff Mail Exchanger. Im Grunde besagt ein MX-Record, dass der Server-Host bereit ist, alle Mail-Adressen in der Domain anzunehmen und weiterzuleiten. MX-Records können auch dazu verwendet werden, um den Datenverkehr von Hosts, die nicht selbst ans Internet angeschlossen sind, zu verwalten. Die Mail solcher Hosts muss durch ein Gateway geleitet werden. Dieses Konzept wurde in Kapitel 6 ausführlicher behandelt.

Einem MX-Record ist immer eine positive Zahl, die so genannte 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 einer niedrigeren Präferenz als seiner eigenen ausliefern. Diese Einschränkung verhindert, dass 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, dass alle anfallenden E-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 niedrigeren Präferenz als 5 findet, wird die Nachricht an mailhub übertragen und von dort an green versendet.

So weit in groben Zügen, wie MX-Records funktionieren. Weitere Informationen über das Mail-Routing im Internet finden Sie in RFC 821, RFC 974 und RFC 1123.

1Wenn Sie das nicht glauben, lesen Sie RFC 1437!
2Es ist auch üblich, eine Art Unterschrift an eine Mail anzuhängen, die normalerweise Informationen über den Absender enthält. Diese Signatur oder .sig wird vom Rest der Nachricht durch eine einzelne Zeile abgetrennt, die die Zeichen »-- «, also zwei Bindestriche, gefolgt von einem Leerzeichen, enthält. Die Netiquette rät: »Fasse dich kurz.«

TOC PREV NEXT INDEX


O'Reilly Home | O'Reilly-Partnerbuchhandlungen | Bestellinformationen
Kontakt | Über O'Reilly | Datenschutz

© 2005, O'Reilly Verlag GmbH & Co. KG