108.3 Lektion 1
Zertifikat: |
LPIC-1 |
---|---|
Version: |
5.0 |
Thema: |
108 Grundlegende Systemdienste |
Lernziel: |
108.3 Grundlagen von Mail Transfer Agents (MTA) |
Lektion: |
1 von 1 |
Einführung
In Unix-ähnlichen Betriebssystemen wie Linux hat jeder Benutzer sein eigenes Postfach (Inbox): ein spezieller Speicherort im Dateisystem, der für andere Nicht-Root-Benutzer unzugänglich ist und in dem die persönlichen E-Mail-Nachrichten des Benutzers gespeichert werden. Eingehende Nachrichten fügt der Mail Transfer Agent (MTA) zum Posteingang des Benutzers hinzu. Der MTA ist ein Programm, das als Systemdienst läuft und Nachrichten sammelt, die andere lokale Konten oder entfernte Benutzerkonten über das Netzwerk senden.
Derselbe MTA ist auch für den Nachrichtenversand im Netz zuständig, wenn die Zieladresse auf ein entferntes Konto verweist. Sobald ein Benutzer eine neue Nachricht in den Postausgang legt, identifiziert der MTA den Zielnetzknoten anhand des Domänennamens in der Ziel-E-Mail-Adresse (der Teil nach dem @
-Zeichen) und versucht dann, die Nachricht mit dem Simple Mail Transfer Protocol (SMTP) an den entfernten MTA zu übertragen. SMTP wurde mit Blick auf unzuverlässige Netzwerke entwickelt und versucht daher, alternative Zustellrouten einzurichten, wenn der primäre E-Mail-Zielknoten nicht erreichbar ist.
Lokaler und entfernter MTA
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.
Note
|
Die heute gängigste Methode zum Senden und Empfangen von E-Mails ist ein gehostetes Konto auf einem entfernten Server, z.B. der zentrale E-Mail-Server eines Unternehmens, auf dem alle Mitarbeiterkonten gehostet werden, oder ein persönlicher E-Mail-Dienst wie Google Gmail. Statt lokal zugestellte Nachrichten zu sammeln, stellt die E-Mail-Client-Anwendung eine Verbindung zum entfernten Postfach her und ruft die Nachrichten von dort ab. Üblicherweise erfolgt der Abruf der Nachrichten vom entfernten Server über die Protokolle POP3 und IMAP, aber auch andere, nicht standardisierte proprietäre Protokolle sind möglich. |
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:
-
Verwalten der Warteschlange der zu versendenden Nachrichten im Postausgang. Für jede in der Warteschlange stehende Nachricht ermittelt der lokale MTA den Ziel-MTA anhand der Empfängeradresse.
-
Kommunikation mit entfernten MTA-Daemons über SMTP. Der lokale MTA sollte das Simple Mail Transfer Protocol (SMTP) über den TCP/IP-Stack nutzen, um Nachrichten von/zu anderen entfernten MTA-Daemons zu empfangen, zu senden und weiterzuleiten.
-
Pflege eines eigenen Posteingangs für jedes lokale Konto. Der MTA speichert die Nachrichten normalerweise im mbox-Format: eine einzelne Textdatei mit sämtlichen E-Mail-Nachrichten fortlaufend.
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.
MTAs unter Linux
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:
DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
…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.
Tip
|
Aus Sicherheitsgründen wird bei den meisten Linux-Distributionen standardmäßig kein MTA installiert. Um die Beispiele in dieser Lektion zu testen, stellen Sie sicher, dass auf jedem Rechner ein MTA läuft und dass dieser Verbindungen über den TCP-Port 25 annimmt. Aus Sicherheitsgründen sollten diese Systeme während der Tests nicht für eingehende Verbindungen aus dem öffentlichen Internet geöffnet sein. |
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:
$ nc lab2.campus 25 220 lab2.campus ESMTP Sendmail 8.15.2/8.15.2; Sat, 16 Nov 2019 00:16:07 GMT HELO lab1.campus 250 lab2.campus Hello lab1.campus [10.0.3.134], pleased to meet you MAIL FROM: emma@lab1.campus 250 2.1.0 emma@lab1.campus... Sender ok RCPT TO: dave@lab2.campus 250 2.1.5 dave@lab2.campus... Recipient ok DATA 354 Enter mail, end with "." on a line by itself Subject: Recipient MTA Test Hi Dave, this is a test for your MTA. . 250 2.0.0 xAG0G7Y0000595 Message accepted for delivery QUIT 221 2.0.0 lab2.campus closing connection
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:
$ cat /var/spool/mail/dave From emma@lab1.campus Sat Nov 16 00:19:13 2019 Return-Path: <emma@lab1.campus> Received: from lab1.campus (lab1.campus [10.0.3.134]) by lab2.campus (8.15.2/8.15.2) with SMTP id xAG0G7Y0000595 for dave@lab2.campus; Sat, 16 Nov 2019 00:17:06 GMT Date: Sat, 16 Nov 2019 00:16:07 GMT From: emma@lab1.campus Message-Id: <201911160017.xAG0G7Y0000595@lab2.campus> Subject: Recipient MTA Test Hi Dave, this is a test for your MTA.
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:
$ nc lab2.campus 25 220 lab2.campus ESMTP Sendmail 8.15.2/8.15.2; Sat, 16 Nov 2019 00:31:44 GMT HELO lab1.campus 250 lab2.campus Hello lab1.campus [10.0.3.134], pleased to meet you MAIL FROM: emma@lab1.campus 250 2.1.0 emma@lab1.campus... Sender ok RCPT TO: henry@lab3.campus 550 5.7.1 henry@lab3.campus... Relaying denied
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:
$ sendmail dave@lab2.campus From: emma@lab1.campus To: dave@lab2.campus Subject: Sender MTA Test Hi Dave, this is a test for my MTA. .
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:
# mailq /var/spool/mqueue (1 request) -----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------- xAIK3D9S000453 36 Mon Nov 18 20:03 <emma@lab1.campus> (Deferred: Connection refused by lab2.campus.) <dave@lab2.campus> Total requests: 1
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:
$ cat /var/spool/mail/dave From emma@lab1.campus Mon Nov 18 20:07:39 2019 Return-Path: <emma@lab1.campus> Received: from lab1.campus (lab1.campus [10.0.3.134]) by lab2.campus (8.15.2/8.15.2) with ESMTPS id xAIK7clC000432 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for <dave@lab2.campus>; Mon, 18 Nov 2019 20:07:38 GMT Received: from lab1.campus (localhost [127.0.0.1]) by lab1.campus (8.15.2/8.15.2) with ESMTPS id xAIK3D9S000453 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT) for <dave@lab2.campus>; Mon, 18 Nov 2019 20:03:13 GMT Received: (from emma@localhost) by lab1.campus (8.15.2/8.15.2/Submit) id xAIK0doL000449 for dave@lab2.campus; Mon, 18 Nov 2019 20:00:39 GMT Date: Mon, 18 Nov 2019 20:00:39 GMT Message-Id: <201911182000.xAIK0doL000449@lab1.campus> From: emma@lab1.campus To: dave@lab2.campus Subject: Sender MTA Test Hi Dave, this is a test for my MTA.
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.
Der Befehl mail
und Mail User Agents (MUA)
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:
$ mail -s "Maintenance fail" henry@lab3.campus <<<"The maintenance script failed at `date`"
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.
Anpassung der Zustellung
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 vollständiger Pfad (beginnend mit
/
) zu einer Datei. Nachrichten an den entsprechenden Alias werden an die Datei angehängt. -
Ein Befehl zur Verarbeitung der Nachricht. Das
<Ziel>
muss mit einem Pipe-Zeichen beginnen. Enthält der Befehl Sonderzeichen (wie Leerzeichen), müssen Sie ihn in doppelte Anführungszeichen setzen. Zum Beispiel leitet der Aliassubscribe: |subscribe.sh
auflab2.campus
alle Nachrichten, die ansubscribe@lab2.campus
gesendet werden, an die Standardeingabe des Befehlssubscribe.sh
. Läuft sendmail im Restricted Shell Mode, sollten die erlaubten Befehle — oder die Links zu ihnen — in/etc/smrsh/
stehen. -
Eine Include-Datei. Ein einzelner Alias kann mehrere Ziele haben (durch Kommate getrennt), daher kann es praktischer sein, diese in einer externen Datei zu speichern. Das Schlüsselwort
:include:
gibt den Dateipfad an, wie in:include:/var/local/destinations
. -
Eine externe Adresse. Aliase können Nachrichten auch an externe E-Mail-Adressen weiterleiten.
-
Ein weiterer Alias.
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
:
$ cat ~/.forward emma@lab1.campus
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.
Geführte Übungen
-
Ohne weitere Optionen oder Argumente wechselt der Befehl
mail henry@lab3.campus
in den Eingabemodus, so dass der Benutzer eine Nachricht anhenry@lab3.campus
schreiben kann. Welcher Tastendruck schließt den Eingabemodus nach Beendigung der Nachricht und versendet die E-Mail? -
Welchen Befehl kann der Root-Benutzer ausführen, um die nicht zugestellten Nachrichten aufzulisten, die auf dem lokalen System entstanden sind?
-
Wie nutzt ein unprivilegierter Benutzer die Standard-MTA-Methode, um alle eingehenden E-Mails automatisch an die Adresse
dave@lab2.campus
weiterzuleiten?
Offene Übungen
-
Welcher Befehl sendet unter Verwendung des von
mailx
bereitgestelltenmail
-Befehls eine Nachricht anemma@lab1.campus
mit der Dateilogs.tar.gz
als Anhang und der Ausgabe des Befehlsuname -a
als E-Mail-Text? -
Der Administrator eines E-Mail-Dienstes möchte den E-Mail-Verkehr im Netz überwachen, aber seine Mailbox nicht mit Testnachrichten überfrachten. Wie könnte er einen systemweiten E-Mail-Alias konfigurieren, um alle an den Benutzer
test
gesendeten E-Mails in die Datei/dev/null
umzuleiten? -
Welcher Befehl außer
newaliases
dient dazu, die Alias-Datenbank zu aktualisieren, nachdem ein neuer Alias zu/etc/aliases
hinzugefügt wurde?
Zusammenfassung
In dieser Lektion haben wir die Rolle und die Verwendung von Mail Transfer Agents in Linux-Systemen kennengelernt. Der MTA bietet eine Standardmethode für die Kommunikation zwischen Benutzerkonten und ist mit anderer Software kombinierbar, um zusätzliche Funktionen bereitzustellen. In dieser Lektion wurden die folgenden Themen behandelt:
-
Konzepte zu E-Mail-Technologien, Postfächern und Protokollen.
-
Wie Linux-MTAs Nachrichten über das Netz austauschen.
-
E-Mail-Clients auf der Konsole und MUAs (Mail User Agents).
-
Lokales E-Mail-Aliasing und Weiterleitung.
Die behandelten Technologien, Befehle und Verfahren waren:
-
SMTP und verwandte Protokolle.
-
Für Linux verfügbare MTAs: Sendmail, Postfix, qmail, Exim.
-
MTA- und MUA-Befehle:
sendmail
undmail
. -
Administrative Dateien und Befehle:
mailq
,/etc/aliases
,newaliases
,~/.forward
.
Lösungen zu den geführten Übungen
-
Ohne weitere Optionen oder Argumente wechselt der Befehl
mail henry@lab3.campus
in den Eingabemodus, so dass der Benutzer eine Nachricht anhenry@lab3.campus
schreiben kann. Welcher Tastendruck schließt den Eingabemodus nach Beendigung der Nachricht und versendet die E-Mail?Strg+D schließt das Programm und versendet die E-Mail.
-
Welchen Befehl kann der Root-Benutzer ausführen, um die nicht zugestellten Nachrichten aufzulisten, die auf dem lokalen System entstanden sind?
Der Befehl
mailq
odersendmail -bp
. -
Wie nutzt ein unprivilegierter Benutzer die Standard-MTA-Methode, um alle eingehenden E-Mails automatisch an die Adresse
dave@lab2.campus
weiterzuleiten?Er fügt
dave@lab2.campus
zu~/.forward
hinzu.
Lösungen zu den offenen Übungen
-
Welcher Befehl sendet unter Verwendung des von
mailx
bereitgestelltenmail
-Befehls eine Nachricht anemma@lab1.campus
mit der Dateilogs.tar.gz
als Anhang und der Ausgabe des Befehlsuname -a
als E-Mail-Text?uname -a | mail -a logs.tar.gz emma@lab1.campus
-
Der Administrator eines E-Mail-Dienstes möchte den E-Mail-Verkehr im Netz überwachen, aber seine Mailbox nicht mit Testnachrichten überfrachten. Wie könnte er einen systemweiten E-Mail-Alias konfigurieren, um alle an den Benutzer
test
gesendeten E-Mails in die Datei/dev/null
umzuleiten?Die Zeile
test: /dev/null
in/etc/aliases
leitet alle an die lokale Mailboxtest
gesendeten Nachrichten in die Datei/dev/null
um. -
Welcher Befehl außer
newaliases
dient dazu, die Alias-Datenbank zu aktualisieren, nachdem ein neuer Alias zu/etc/aliases
hinzugefügt wurde?Der Befehl
sendmail -bi
odersendmail -I
.