Linux Professional Institute Learning Logo.
Weiter zum Inhalt
  • Home
    • Alle Ressourcen
    • LPI Lernmaterialien
    • Mitmachen
    • Publishing Partner
    • Publishing Partner werden
    • Über uns
    • FAQ
    • Mitwirkende
    • Roadmap
    • Kontakt
  • LPI.org
108.3 Lektion 1
Thema 105: Shells und Shell-Skripte
105.1 Die Shell-Umgebung anpassen und verwenden
  • 105.1 Lektion 1
  • 105.1 Lektion 2
  • 105.1 Lektion 3
105.2 Einfache Skripte anpassen oder schreiben
  • 105.2 Lektion 1
  • 105.2 Lektion 2
Thema 106: Benutzerschnittstellen und Desktops
106.1 X11 installieren und konfigurieren
  • 106.1 Lektion 1
106.2 Grafische Desktops
  • 106.2 Lektion 1
106.3 Barrierefreiheit
  • 106.3 Lektion 1
Thema 107: Administrative Aufgaben
107.1 Benutzer- und Gruppenkonten und dazugehörige Systemdateien verwalten
  • 107.1 Lektion 1
  • 107.1 Lektion 2
107.2 Systemadministrationsaufgaben durch Einplanen von Jobs automatisieren
  • 107.2 Lektion 1
  • 107.2 Lektion 2
107.3 Lokalisierung und Internationalisierung
  • 107.3 Lektion 1
Thema 108: Grundlegende Systemdienste
108.1 Die Systemzeit verwalten
  • 108.1 Lektion 1
  • 108.1 Lektion 2
108.2 Systemprotokollierung
  • 108.2 Lektion 1
  • 108.2 Lektion 2
108.3 Grundlagen von Mail Transfer Agents (MTA)
  • 108.3 Lektion 1
108.4 Drucker und Druckvorgänge verwalten
  • 108.4 Lektion 1
Thema 109: Netzwerkgrundlagen
109.1 Grundlagen von Internetprotokollen
  • 109.1 Lektion 1
  • 109.1 Lektion 2
109.2 Persistente Netzwerkkonfiguration
  • 109.2 Lektion 1
  • 109.2 Lektion 2
109.3 Grundlegende Netzwerkfehlerbehebung
  • 109.3 Lektion 1
  • 109.3 Lektion 2
109.4 Clientseitiges DNS konfigurieren
  • 109.4 Lektion 1
Thema 110: Sicherheit
110.1 Administrationsaufgaben für Sicherheit durchführen
  • 110.1 Lektion 1
110.2 Einen Rechner absichern
  • 110.2 Lektion 1
110.3 Daten durch Verschlüsselung schützen
  • 110.3 Lektion 1
  • 110.3 Lektion 2
How to get certified
  1. Thema 108: Grundlegende Systemdienste
  2. 108.3 Grundlagen von Mail Transfer Agents (MTA)
  3. 108.3 Lektion 1

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 Alias subscribe: |subscribe.sh auf lab2.campus alle Nachrichten, die an subscribe@lab2.campus gesendet werden, an die Standardeingabe des Befehls subscribe.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

  1. Ohne weitere Optionen oder Argumente wechselt der Befehl mail henry@lab3.campus in den Eingabemodus, so dass der Benutzer eine Nachricht an henry@lab3.campus schreiben kann. Welcher Tastendruck schließt den Eingabemodus nach Beendigung der Nachricht und versendet die E-Mail?

  2. Welchen Befehl kann der Root-Benutzer ausführen, um die nicht zugestellten Nachrichten aufzulisten, die auf dem lokalen System entstanden sind?

  3. Wie nutzt ein unprivilegierter Benutzer die Standard-MTA-Methode, um alle eingehenden E-Mails automatisch an die Adresse dave@lab2.campus weiterzuleiten?

Offene Übungen

  1. Welcher Befehl sendet unter Verwendung des von mailx bereitgestellten mail-Befehls eine Nachricht an emma@lab1.campus mit der Datei logs.tar.gz als Anhang und der Ausgabe des Befehls uname -a als E-Mail-Text?

  2. 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?

  3. 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 und mail.

  • Administrative Dateien und Befehle: mailq, /etc/aliases, newaliases, ~/.forward.

Lösungen zu den geführten Übungen

  1. Ohne weitere Optionen oder Argumente wechselt der Befehl mail henry@lab3.campus in den Eingabemodus, so dass der Benutzer eine Nachricht an henry@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.

  2. Welchen Befehl kann der Root-Benutzer ausführen, um die nicht zugestellten Nachrichten aufzulisten, die auf dem lokalen System entstanden sind?

    Der Befehl mailq oder sendmail -bp.

  3. 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

  1. Welcher Befehl sendet unter Verwendung des von mailx bereitgestellten mail-Befehls eine Nachricht an emma@lab1.campus mit der Datei logs.tar.gz als Anhang und der Ausgabe des Befehls uname -a als E-Mail-Text?

    uname -a | mail -a logs.tar.gz emma@lab1.campus

  2. 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 Mailbox test gesendeten Nachrichten in die Datei /dev/null um.

  3. 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 oder sendmail -I.

Linux Professional Insitute Inc. Alle Rechte vorbehalten. Besuchen Sie die LPI Learning Website: https://learning.lpi.org
Dieses Werk steht unter der Lizenz Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

Nächste Lektion

108.4 Drucker und Druckvorgänge verwalten (108.4 Lektion 1)

Nächste Lektion lesen

Linux Professional Insitute Inc. Alle Rechte vorbehalten. Besuchen Sie die LPI Learning Website: https://learning.lpi.org
Dieses Werk steht unter der Lizenz Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International.

LPI ist eine Non-Profit-Organisation.

© 2023 Linux Professional Institute (LPI) ist eine globale Organisation für Zertifizierungsstandards und zur Karriereplanung für Open-Source-Profis. Mit mehr als 200.000 Zertifikatsinhabern ist es die weltweit erste und größte herstellerneutrale Linux- und Open-Source-Zertifizierungsstelle. LPI verfügt über zertifizierte Fachleute in über 180 Ländern, bietet Prüfungen in mehreren Sprachen an und hat Hunderte von Trainingspartnern.

Unser Ziel ist es, wirtschaftliche und kreative Möglichkeiten für alle zu ermöglichen, indem wir Open-Source-Wissens- und Kompetenzzertifizierungen allgemein zugänglich machen.

  • LinkedIn
  • flogo-RGB-HEX-Blk-58 Facebook
  • Twitter
  • Kontaktieren Sie uns
  • Datenschutz und Cookie-Richtlinien

Haben Sie einen Fehler entdeckt oder möchten Sie helfen, diese Seite zu verbessern? Lassen Sie es uns wissen.

© 1999–2023 The Linux Professional Institute Inc. Alle Rechte vorbehalten.