108.3 Lektion 1

Herkömmliche Benutzerkonten in vernetzten Rechnern stellen das einfachste Szenario für den Austausch von E-Mails dar, bei dem auf jedem Netzknoten ein eigener MTA-Daemon läuft. Zum Senden und Empfangen von E-Mail-Nachrichten ist außer dem MTA keine weitere Software erforderlich. In der Praxis kommt es jedoch häufiger vor, dass ein entferntes E-Mail-Konto verwendet wird und kein aktiver lokaler MTA-Dienst vorhanden ist — es kommt stattdessen also eine E-Mail-Client-Anwendung für den Zugriff auf das entfernte Konto zum Einsatz.

Im Gegensatz zu lokalen Konten erfordert ein entferntes E-Mail-Konto — auch Remote Mailbox genannt — eine Benutzerauthentifizierung, die den Zugriff auf das Postfach des Benutzers und auf den entfernten MTA (in diesem Fall einfach SMTP-Server genannt) gestattet. Während der Benutzer, der mit einem lokalen Posteingang und MTA interagiert, bereits vom System identifiziert wird, muss ein entferntes System die Identität des Benutzers überprüfen, bevor es seine Nachrichten über IMAP oder POP3 bearbeitet.

Läuft ein MTA-Daemon auf dem lokalen System, können lokale Benutzer eine E-Mail an andere lokale Benutzer oder an Benutzer auf einem entfernten Rechner senden, sofern deren System ebenfalls über einen MTA-Dienst verfügt, der Netzwerkverbindungen akzeptiert. TCP-Port 25 ist der Standardport für die SMTP-Kommunikation — andere Ports sind, je nach Authentifizierungs- und/oder Verschlüsselungsschema (falls vorhanden) ebenfalls möglich.

Abgesehen von Topologien, die den Zugriff auf entfernte Postfächer umfassen, können Sie ein E-Mail-Austausch-Netzwerk zwischen gewöhnlichen Linux-Benutzerkonten implementieren, solange alle Netzwerkknoten über einen aktiven MTA verfügen, der die folgenden Aufgaben erfüllt:

Normalerweise wird bei E-Mail-Adressen ein Domänenname als Absender angegeben, z.B. lpi.org in info@lpi.org. Ist dies der Fall, fragt der MTA des Absenders den Domain Name Service (DNS) nach dem entsprechenden MX-Eintrag ab. Der DNS MX-Eintrag enthält die IP-Adresse des MTA, der die E-Mail für diese Domäne bearbeitet. Wenn für dieselbe Domäne mehr als ein MX-Eintrag im DNS angegeben ist, sollte der MTA versuchen, sie entsprechend ihrer Prioritätswerte zu kontaktieren. Enthält die Empfängeradresse keinen Domänennamen oder hat die Domäne keinen MX-Eintrag, wird der Teil nach dem @ als Host des Ziel-MTAs behandelt.

Sicherheitsaspekte müssen berücksichtigt werden, wenn die MTA-Hosts für Rechner im Internet sichtbar sind. So ist es beispielsweise möglich, dass ein unbekannter Benutzer den lokalen MTA missbraucht, um sich als ein anderer Benutzer auszugeben und potenziell schädliche E-Mails zu versenden. Einen MTA, der eine E-Mail blind weiterleitet, bezeichnet man als Open Relay, da er als Vermittler dienen kann, um den wahren Absender der Nachricht zu verschleiern. Um solchen Missbrauch zu verhindern, empfiehlt es sich, nur Verbindungen autorisierter Domänen zu akzeptieren und ein sicheres Authentifizierungsschema zu implementieren.

Darüber hinaus gibt es viele verschiedene MTA-Implementierungen für Linux, die sich jeweils auf bestimmte Aspekte wie Kompatibilität, Leistung, Sicherheit usw. konzentrieren, doch folgen alle den gleichen Prinzipien und bieten ähnliche Funktionen.

Der traditionelle MTA für Linux-Systeme ist Sendmail, ein sehr flexibler Allzweck-MTA, den viele Unix-ähnliche Betriebssysteme einsetzen. Anderen gängige MTAs sind Postfix, qmail und Exim. Hauptgrund für die Wahl eines alternativen MTA ist die einfachere Implementierung fortgeschrittener Funktionen, da die Konfiguration benutzerdefinierter E-Mail-Server in Sendmail eine komplizierte Aufgabe sein kann. Jede Distribution hat ihren bevorzugten MTA mit vordefinierten Einstellungen für die meisten gängigen Konfigurationen. Alle MTAs sind als Drop-in-Ersatz für Sendmail konzipiert, so dass alle Sendmail-kompatiblen Anwendungen unabhängig vom verwendeten MTA funktionieren sollten.

Läuft der MTA, kann aber keine Netzwerkverbindungen annehmen, wird er E-Mail-Nachrichten nur auf dem lokalen Rechner zustellen. Für den MTA sendmail ist die Datei /etc/mail/sendmail.mc so zu ändern, dass auch nicht-lokale Verbindungen akzeptiert werden. Fügen Sie dazu den folgenden Eintrag hinzu:

…​und setzen Sie die richtige Netzwerkadresse — anschließend starten Sie den Dienst neu. Einige Linux-Distributionen, wie z.B. Debian, bieten Konfigurationswerkzeuge an, die den E-Mail-Server mit einem vordefinierten Satz häufig verwendeter Funktionen einzurichten helfen.

Sobald der MTA läuft und Verbindungen aus dem Netz annimmt, werden neue E-Mail-Nachrichten mit SMTP-Befehlen über eine TCP-Verbindung an ihn weitergeleitet. Sie können den Befehl nc — ein Netzwerkdienstprogramm, das allgemeine Daten über das Netzwerk liest und schreibt — nutzen, um SMTP-Befehle direkt an den MTA zu senden. Ist der Befehl nc nicht verfügbar, installieren Sie ihn mit dem Paket ncat oder nmap-ncat, je nach Paketverwaltungssystem. Das Schreiben von SMTP-Befehlen direkt an den MTA hilft Ihnen, das Protokoll und andere allgemeine E-Mail-Konzepte besser zu verstehen, aber es bietet sich auch für die Diagnose von Problemen bei der E-Mail-Zustellung an.

Sendet zum Beispiel der Benutzer emma auf dem Rechner lab1.campus eine Nachricht an den Benutzer dave auf dem Rechner lab2.campus, kann sich emma mit nc direkt mit dem MTA lab2.campus verbinden, sofern dieser auf dem TCP-Port 25 lauscht:

Sobald die Verbindung hergestellt ist, identifiziert sich der entfernte MTA und ist dann bereit, SMTP-Befehle zu empfangen. Der erste SMTP-Befehl im Beispiel, HELO lab1.campus, gibt lab1.campus als den Initiator des Austauschs an. Die nächsten beiden Befehle, MAIL FROM: emma@lab1.campus und RCPT TO: dave@lab2.campus, nennen Absender und Empfänger. Die eigentliche E-Mail-Nachricht beginnt nach dem Befehl DATA und endet mit einem Punkt in einer eigenen Zeile. Um der E-Mail ein Feld subject hinzuzufügen, sollte es in der ersten Zeile nach dem Befehl DATA stehen, wie im Beispiel zu sehen. Wenn das Betrefffeld verwendet wird, muss es durch eine Leerzeile vom Inhalt der E-Mail getrennt sein. Der Befehl QUIT beendet die Verbindung mit dem MTA auf dem Host lab2.campus.

Auf dem Host lab2.campus erhält der Benutzer dave eine Nachricht wie You have new mail in /var/spool/mail/dave, sobald er eine Shellsitzung startet. Diese Datei enthält die von emma gesendete Roh-E-Mail-Nachricht sowie die vom MTA hinzugefügten Kopfzeilen:

Die Kopfzeile Received: zeigt, dass die Nachricht von lab1.campus direkt von lab2.campus empfangen wurde. Standardmäßig akzeptieren MTAs nur Nachrichten an lokale Empfänger. Der folgende Fehler tritt wahrscheinlich auf, wenn der Benutzer emma versucht, eine E-Mail an den Benutzer henry auf dem Host lab3.campus zu senden, aber den MTA lab2.campus anstelle des richtigen MTA lab3.campus verwendet:

SMTP-Antwortnummern, die mit 5 beginnen, wie z.B. die Meldung Relaying denied, weisen auf einen Fehler hin. Es gibt Situationen, in denen Relaying, also eine Weiterleitung, wünschenswert ist, z.B. wenn die Hosts, die E-Mails senden und empfangen, nicht ständig verbunden sind: Ein zwischengeschalteter MTA kann so konfiguriert werden, dass er E-Mails annimmt, die für andere Hosts bestimmt sind, und so als Relay SMTP-Server fungieren, der Nachrichten zwischen MTAs weiterleitet.

Die Möglichkeit, den E-Mail-Verkehr über zwischengeschaltete SMTP-Server zu leiten, macht es unnötig, eine direkte Verbindung zu dem in der E-Mail-Adresse des Empfängers angegebenen Host herzustellen, wie in den vorherigen Beispielen gezeigt. Außerdem enthalten E-Mail-Adressen oft einen Domänennamen als Standort (nach dem @), so dass der tatsächliche Name des entsprechenden MTA-Hosts über DNS abgerufen werden muss. Daher ist es empfehlenswert, bei entfernten Mailboxen die Aufgabe der Identifizierung des entsprechenden Zielhosts an den lokalen MTA oder an den entfernten SMTP-Server zu delegieren.

Sendmail bietet den Befehl sendmail für viele E-Mail-bezogene Operationen, einschließlich der Unterstützung beim Verfassen neuer Nachrichten. Es erfordert auch, dass der Benutzer die E-Mail-Kopfzeilen angibt, aber deutlich komfortabler als bei der direkten Verwendung von SMTP-Befehlen. Eine geeignetere Methode für den Benutzer emma@lab1.campus, eine E-Mail-Nachricht an dave@lab2.campus zu senden, wäre also:

Auch hier beendet der einzelne Punkt in einer Zeile die Nachricht. Die Nachricht geht sofort an den Empfänger, es sei denn, der lokale MTA kann den entfernten MTA nicht kontaktieren. Der Befehl mailq, von root ausgeführt, zeigt alle nicht zugestellten Nachrichten an. Antwortet zum Beispiel der MTA von lab2.campus nicht, nennt der Befehl mailq die nicht zugestellte Nachricht und die Ursache des Fehlers:

Der Standardspeicherort für die Postausgangswarteschlange ist /var/spool/mqueue/, aber verschiedene MTAs können andere Speicherorte im Verzeichnis /var/spool/ nutzen. Postfix zum Beispiel erstellt einen Verzeichnisbaum unter /var/spool/postfix/, um die Warteschlange zu verwalten. Der Befehl mailq entspricht sendmail -bp und sollte unabhängig von dem im System installierten MTA vorhanden sein. Um die Abwärtskompatibilität zu gewährleisten, bieten die meisten MTAs diese traditionellen Befehle der Mailverwaltung an.

Ist der primäre E-Mail-Zielhost — sofern er in einem MX-DNS-Eintrag für die Domäne angegeben ist — nicht erreichbar, versucht der MTA, die Einträge mit niedrigerer Priorität zu kontaktieren (sofern welche angegeben sind). Ist keiner von ihnen erreichbar, verbleibt die Nachricht in der Warteschlange des lokalen Postausgangs, um später versendet zu werden. So konfiguriert, prüft der MTA in regelmäßigen Abständen die Erreichbarkeit der entfernten Hosts und unternimmt einen neuen Zustellversuch. Bei einem Sendmail-kompatiblen MTA unternimmt der Befehl sendmail -q sofort einen neuen Versuch.

Sendmail speichert eingehende Nachrichten in einer Datei, die nach dem Besitzer des Posteingangs benannt ist, zum Beispiel /var/spool/mail/dave. Andere MTAs, wie Postfix, können die eingehenden Nachrichten an Orten wie /var/mail/dave speichern, aber der Inhalt der Datei ist der gleiche. Im Beispiel wurde die Nachricht mit dem Befehl sendmail auf dem Rechner des Absenders verfasst, und die unbearbeiteten Kopfzeilen der Nachricht zeigen, dass die E-Mail weitere Stationen durchlaufen hat, bevor sie den endgültigen Empfänger erreicht:

Von unten nach oben zeigen die Zeilen, die mit Received: beginnen, den Weg, den die Nachricht genommen hat. Die Nachricht wurde vom Benutzer emma mit dem Befehl sendmail dave@lab2.campus auf lab1.campus übermittelt, wie aus dem ersten Received:-Header hervorgeht. Dann, immer noch auf lab1.campus, verwendet der MTA ESMTPS — eine erweiterte Version von SMTP mit Verschlüsselungsfunktionalität --, um die Nachricht an den MTA auf lab2.campus zu senden, wie im letzten (obersteen) Received:-Header angegeben.

Der MTA beendet seine Arbeit, sobald die Nachricht im Posteingang des Benutzers gespeichert wurde. Es ist üblich, eine Art E-Mail-Filterung durchzuführen, wie z.B. Spamblocker oder die Anwendung benutzerdefinierter Filterregeln. Diese Aufgaben übernehmen Drittanwendungen, die mit dem MTA zusammenarbeiten. Der MTA könnte z.B. das Dienstprogramm SpamAssassin aufrufen, um verdächtige Nachrichten mithilfe seiner Textanalysefunktionen zu markieren.

Möglich, aber nicht sinnvoll ist es, die Mailbox-Datei direkt zu lesen. Dafür empfiehlt sich ein E-Mail-Client-Programm (z.B. Thunderbird, Evolution oder KMail), das die Datei analysiert und die Nachrichten entsprechend verwaltet. Solche Programme bieten auch zusätzliche Funktionen, wie Verknüpfungen zu allgemeinen Aktionen, Unterverzeichnisse für den Posteingang usw.

Sie können eine E-Mail-Nachricht direkt im Rohformat schreiben, aber es ist deutlich sinnvoller, dafür eine Client-Anwendung, einen sog. Mail User Agent (MUA) zu nutzen, um den Prozess zu beschleunigen und Fehler zu vermeiden. Der MUA kümmert sich um die Arbeit im Hintergrund, d.h. der E-Mail-Client präsentiert und organisiert die empfangenen Nachrichten und kümmert sich um die richtige Kommunikation mit dem MTA, nachdem der Benutzer eine E-Mail verfasst hat.

Es gibt viele verschiedene Arten von Mail User Agents. Desktopanwendungen wie Mozilla Thunderbird und Evolution von Gnome unterstützen sowohl lokale als auch entfernte E-Mail-Konten. Auch Webmail-Schnittstellen bilden eine Art MUA, da sie die Interaktion zwischen dem Benutzer und dem zugrunde liegenden MTA vermitteln. E-Mail-Clients sind jedoch nicht auf grafische Oberflächen beschränkt: Konsolen-E-Mail-Clients sind weit verbreitet, um auf Postfächer zuzugreifen, die nicht in eine grafische Oberfläche integriert sind, und um E-Mail-bezogene Aufgaben in Shellskripten zu automatisieren.

Ursprünglich war der Unix-Befehl mail nur für den Austausch von Nachrichten zwischen lokalen Systembenutzern gedacht (der erste mail-Befehl war bereits in der ersten Unix-Ausgabe 1971 enthalten). Mit zunehmendem E-Mail-Austausch über das Netzwerk entstanden andere Programme für das neue Übermittlungssystem, die nach und nach das alte mail-Programm ersetzten.

Heute ist der am häufigsten verwendete mail-Befehl Teil des Pakets mailx, das mit allen modernen E-Mail-Funktionen kompatibel ist. In den meisten Linux-Distributionen ist der Befehl mail nur ein symbolischer Link auf den Befehl mailx. Andere Implementierungen, wie das Paket GNU Mailutils, bieten im Grunde die gleichen Funktionen wie mailx. Es gibt jedoch kleinere Unterschiede insbesondere in Bezug auf die Kommandozeilenoptionen.

Ungeachtet ihrer Implementierung arbeiten alle modernen Varianten des mail-Befehls in zwei Modi: Normal Mode und Send Mode. Ist eine E-Mail-Adresse als Argument für den Befehl mail angegeben, geht er in den Sendemodus, andernfalls in den normalen (Lese-)Modus. Im normalen Modus werden die empfangenen Nachrichten jeweils mit einem numerischen Index aufgelistet, so dass der Benutzer bei der Eingabe von Befehlen in der interaktiven Eingabeaufforderung auf die einzelnen Nachrichten verweisen kann. Der Befehl print 1 dient zum Beispiel dazu, den Inhalt von Nachricht Nummer 1 anzuzeigen. Interaktive Befehle können Sie abkürzen, z.B. print, delete oder reply durch p, d bzw. r. Der Befehl mail berücksichtigt immer die zuletzt empfangene oder die zuletzt gesehene Nachricht, wenn Sie keine Indexnummer angeben. Der Befehl quit oder q beendet das Programm.

Der Send Mode dient insbesondere dem Versenden automatisierter E-Mail-Nachrichten, z.B. eine E-Mail an den Systemadministrator, wenn ein Wartungsskript fehlschlägt. Im Sendemodus verwendet mail den Inhalt der Standardeingabe als Nachrichtentext:

Im Beispiel haben wir mit der Option -s der Nachricht ein Betrefffeld hinzugefügt. Der Nachrichtentext ensteht durch die Umleitung Hereline auf die Standardeingabe. Wir hätten aber auch den Inhalt einer Datei oder die Ausgabe eines Befehls über die Pipe an stdin des Programms leiten können. Wenn kein Inhalt durch eine Umleitung auf die Standardeingabe bereitgestellt wird, wartet das Programm auf die Eingabe des Nachrichtentextes durch den Benutzer. In diesem Fall beendet die Tastenkombination Strg+D die Nachricht. Der Befehl mail wird sofort beendet, sobald die Nachricht in die Warteschlange des Postausgangs aufgenommen wurde.

Per Default sind die E-Mail-Konten auf einem Linux-System mit den Standard-Systemaccounts verknüpft. Hat beispielsweise die Benutzerin Carol den Anmeldenamen carol auf dem Rechner lab2.campus, lautet ihre E-Mail-Adresse carol@lab2.campus. Diese Eins-zu-Eins-Zuordnung zwischen Systemkonten und Postfächern können Sie durch Standardmethoden erweitern, die die meisten Linux-Distributionen bereitstellen, insbesondere durch den E-Mail-Routing-Mechanismus über die Datei /etc/aliases.

Ein E-Mail-Alias ist ein “virtueller” E-Mail-Empfänger, dessen eingehende Nachrichten an bestehende lokale Postfächer oder an andere Arten von Nachrichtenspeichern oder -verarbeitungszielen weitergeleitet werden. Aliasnamen sind zum Beispiel nützlich, um Nachrichten an postmaster@lab2.campus in Carols Postfach zu leiten, das ein gewöhnliches lokales Postfach im System lab2.campus ist. Dazu fügen Sie die Zeile postmaster: carol in die Datei /etc/aliases auf lab2.campus ein. Nach einer Änderung der Datei /etc/aliases sollten Sie den Befehl newaliases ausführen, um die Alias-Datenbank des MTA zu aktualisieren und die Änderungen wirksam zu machen. Die Befehle sendmail -bi oder sendmail -I dienen ebenfalls der Aktualisierung der Alias-Datenbank.

Aliase definieren Sie einzeln pro Zeile im Format <Alias>: <Ziel>. Neben den normalen lokalen Postfächern unter den entsprechenden Benutzernamen sind auch andere Zieltypen verfügbar:

Ein unprivilegierter lokaler Benutzer kann Aliase für seine eigenen E-Mails in der Datei .forward in seinem Heimatverzeichnis definieren. Da die Aliase nur die eigene Mailbox betreffen, ist nur der Teil <Ziel> notwendig. Um alle eingehenden E-Mails an eine externe Adresse weiterzuleiten, erstellt der Benutzer dave auf lab2.campus die folgende Datei ~/.forward:

Sie leitet alle an dave@lab2.campus gesendeten E-Mail-Nachrichten an emma@lab1.campus weiter. Wie bei der Datei /etc/aliases sind weitere Umleitungsregeln in .forward möglich, jeweils eine pro Zeile. Dennoch darf die Datei .forward nur von ihrem Besitzer beschreibbar sein, und es ist nicht notwendig, den Befehl newaliases nach der Änderung auszuführen. Dateien, die mit einem Punkt beginnen, erscheinen nicht in den regulären Dateilisten, was dazu führen kann, dass der Benutzer aktive Aliase nicht bemerkt. Daher ist es wichtig, bei der Diagnose von E-Mail-Zustellungsproblemen zu überprüfen, ob die Datei existiert.