© jameek, photocase.com

Post – vor dem Austausch mit Kollegen, Kunden und Freunden steht jedoch das Einrichten des Mailsystems durch einen kundigen Admin. Für eine Zertifizierung erwartet das LPI Kenntnisse in der Konfiguration und dem Betrieb von Mailservern.

Wer sich erfolgreich LPIC-1-zertifizieren lassen möchte, muss grundlegende Kenntnisse der Konfiguration und des Betriebs von E-Mail-Servern – allgemein als MTA (Mail Transfer Agent) bezeichnet – vorweisen. Auf einem GNU-Linux-System hat der Admin die Wahl zwischen einer ganzen Reihe MTAs: Courier [1], Exim [2], Postfix [3], Qmail [4], Sendmail [5], Smail [6] oder MMDF [7], um nur einige zu nennen.

Ahnvater aller MTAs ist Sendmail, das seit der Anfangszeit des Internets als das Bindeglied zwischen der Vielzahl vorhandener E-Mail-Systeme gilt. Die Logik für die E-Mail-Zustellung ist nicht fest im Sendmail-Programm kodiert, sondern in seiner Konfiguration »sendmail.cf«. Diese Datei hat eine kryptische Syntax, aber glücklicherweise konfiguriert der moderne Admin Sendmail heute über die besser lesbare Datei »sendmail.mc«. Ein Präprozessor erzeugt daraus und aus Include-Dateien die eigentliche »sendmail.cf«. So ist es nicht mehr nötig, diese Datei direkt zu editieren.

Auf einer Vielzahl von Unix-Systemen ist Sendmail immer noch der Standard-MTA. Die meisten Linux-Distributionen sind aber von Sendmail abgekommen und verwenden einen neueren MTA. Die Autoren dieser Alternativen hatten dabei unterschiedliche Ziele, darunter Performance, Sicherheit oder Einfachheit der Konfiguration. Die Konfiguration der einzelnen MTAs unterscheidet sich deutlich, da Sendmail aber als Quasistandard gilt, enthalten die anderen MTAs meist noch eine rudimentäre Emulation des Traditionsprogramms. Exim, Postfix und Sendmail haben eine große Verbreitung in populären Distributionen (siehe Tabelle 1), aber alle Distributionen bieten auch andere gängige MTAs an und erlauben es, sie zu wechseln.

Aufgaben eines MTA

Ein MTA nimmt bis zu drei Aufgaben wahr: das Versenden, das Empfangen sowie das lokale Zustellen von E-Mails. Nicht jeder absolviert alle drei Aufgaben. Es lassen sich drei typische MTA-Konfigurationen unterscheiden.

Der einfachste MTA versendet lediglich E-Mails. Dedizierte Server nutzen diese Variante, wenn sie selbst nicht als Mailserver arbeiten, aber E-Mails versenden sollen. System-Cronjobs oder Webapplikationen erzeugen für Warnungen oder Hinweise an Benutzer beispielsweise E-Mails und wollen diese an einen entfernten Empfänger zustellen. Dazu braucht das System Nachrichten weder lokal zuzustellen noch welche von außen anzunehmen (siehe Abbildung 1).

Abbildung 1: Ein einfacher MTA nimmt über einen Server-internen Programmaufruf Mail an und leitet sie weiter. Er speichert keine Nachrichten und nimmt auch keine externen E-Mails an.

Ein weiterer MTA-Typ leitet E-Mails nur weiter (Relaying). In größeren Netzwerken findet sich gern eine hierarchische Struktur von Mailservern, oft in Kombination mit einer Firewall, die nur Verbindungen zu einen Mailserver zulässt, der Nachrichten an Sub-Mailserver weiterverteilt. Solche Mailserver empfangen E-Mails von draußen und versenden sie wieder, stellen aber nicht lokal zu (siehe Abbildung 2).

Abbildung 2: Der Relaying Forwarder nimmt Mails an und sendet sie direkt weiter. Firewalls setzen häufig diesen Aufbau voraus, da so klar festgelegt ist, welche IP-Adresse die Nachrichten versendet.

Ein vollständiger MTA übernimmt alle genannten Aufgaben. Kleinere Netzwerke verwenden nur diese Art. In größeren Netzwerken, in denen es auch die beiden anderen MTA-Typen gibt, übernehmen ein oder mehrere dedizierte MTAs die Aufgabe eines vollständigen MTA (siehe Abbildung 3).

Abbildung 3: Ein vollständiger MTA nimmt Nachrichten an und sendet sie auch an weitere MTAs weiter, wenn sie nicht für lokale Empfänger bestimmt sind. In diesem Fall liefert der Mailserver sie lokal aus.

Funktionsweise eines MTA

Relevant sind heute für den E-Mail-Transport nur das Simple Mail Transfer Protocol (SMTP, RFC 821, [8]) und seine Erweiterung, das Extended SMTP (ESMTP, RFC 2821, [9]). Beide Protokolle verwenden den TCP-Port 25. Um E-Mails zu empfangen, muss ein Daemon sich an diesen Port binden und von dort Verbindungen entgegennehmen.

Ein System, das lediglich E-Mails versendet, sollte selbst keine Verbindungen auf Port 25 entgegennehmen. Es reicht, wenn es lediglich Verbindungen zum Port 25 anderer MTAs aufbaut. Ein Benutzerprogramm hat zwei Möglichkeiten, will es eine E-Mail versenden: Es implementiert entweder ein Mailprotokoll und verbindet sich zu einem Mailserver (das kann auch »localhost« sein) oder es ruft einen lokal vorhandenen MTA als Programm auf − typischerweise ist das »/usr/sbin/sendmail«, auch wenn der MTA nicht Sendmail ist, ein Kompatibilitätsprogramm ist vorhanden. Dann verschickt der MTA die E-Mail.

Ab die Post!

Soll ein MTA (oder ein Clientprogramm, das selbst das Mailprotokoll implementiert) eine E-Mail an »kester.habermann@linuxtag.org« verschicken, sendet er zunächst den Teil rechts vom »@« an einen DNS-Server (Domain Name System, [10]). Dort erfragt er den eingetragenen Mail-Exchanger (MX) für die übermittelte Domain, Subdomain oder den Host. Im Beispiel lautete die Antwort »mail1.linuxtag.net«. Als Nächstes baut der MTA eine TCP-Verbindung zu Port 25 des ermittelten Mail-Exchangers auf. Er versucht üblicherweise zunächst per ESMTP mit dem Server zu kommunizieren. Versteht dieser die Protokollvariante nicht, fällt der Client auf SMTP zurück (siehe Abbildung 4).

Abbildung 4: Ein MTA ermittelt den zuständigen Mail-Exchanger per DNS-Abfrage und verbindet sich auf dessen Port 25. Dort versucht er ESMTP oder – falls dies scheitert – SMTP mit dem Empfänger zu sprechen.

Mailserver konfigurieren und starten

Eine sehr schlichte Sendmail-Konfiguration »sendmail.mc« zeigt Listing 1. Aus dieser Datei erzeugt ein Aufruf des Makroprozessors »m4« die eigentliche Konfiguration »sendmail.cf«, die über 1000 Zeilen lang ist:

m4 sendmail.mc > sendmail.cf

Das Ergebnis »sendmail.cf« sollte niemand editieren. Wenn ein Parameter zu ändern ist, passt der Administrator die Definition in der »sendmail.mc« an und erzeugt »sendmail.cf« neu.

Ein Daemon kann entweder über »inetd« beziehungsweise »xinted« [11] oder als Standalone-Server starten. Viele Administratoren nutzen dazu ein Init-Skript, das sie in den passenden Runlevels durch einen symbolischen Link in das Verzeichnis »/etc/init.d« aktivieren [12]. Manuell lässt sich Sendmail so starten:

/etc/init.d/sendmail start

Das Skript startet den Sendmail-Daemon mit bestimmten Optionen, typischerweise als »/usr/bin/sendmail -bd -q10«. Der Parameter »-bd« sorgt dafür, dass der MTA im Hintergrund als Daemon läuft und Verbindungen auf Port 25 entgegennimmt. Die Option »-q10m« veranlasst, alle 10 Minuten gespeicherte E-Mails in der Mailqueue abzuarbeiten.

01 include(`/usr/share/sendmail/cf/m4/cf.m4')dnl
02 OSTYPE(linux)dnl
03 MAILER_DEFINITIONS
04 MAILER(`local')dnl
05 MAILER(`smtp')dnl

Die Konfiguration von Exim liegt normalerweise unter »/etc/exim4/«. Der Admin startet Exim analog zu Sendmail über das Init-Skript »exim«. Die Konfigurationsdateien von Postfix befinden sich üblicherweise in »/etc/postfix/«. Die wichtigsten Einstellungen erfolgen in der Datei »main.cf«, das Init-Skript heißt »postfix«. Es startet einige Daemons, die Aufgaben im Rahmen der Mailverteilung und -zustellung übernehmen. Das Annehmen von E-Mail oder das Abarbeiten der Mailqueue gehören auch dazu.

Sicherheitsverwahrung

SMTP und seine spätere Ergänzung ESMTP wurden entworfen, um zu vermeiden, dass E-Mails durch Verbindungsabbrüche oder Rechnerabstürze verloren gehen. Aus diesem Grund ist der sendende Partner so lange für eine E-Mail verantwortlich, bis der empfangende Server bestätigt, die E-Mail erfolgreich erhalten zu haben. Programme halten E-Mails daher nicht im Arbeitsspeicher, sondern legen sie auf der Festplatte ab, bis die Nachricht nachweislich zugestellt ist.

Die Nachrichten reihen sie in eine Mail-Warteschlange (Queue) ein. Dieses Zwischenspeichern auf Festplatte mag zwar langsamer sein als das Halten im RAM, reduziert jedoch die Wahrscheinlichkeit, dass eine E-Mail verloren geht. Quittiert ein Empfänger eine Nachricht nicht, so verbleibt sie in der Queue des Sendenden. Ist eine Wartezeit verstrichen, versucht der Server sie erneut zuzustellen. War dies erfolgreich, löscht er die Nachricht aus der Queue. Die Verantwortung liegt nun beim Empfänger.

In der Praxis durchläuft eine E-Mail mehrere Stationen auf dem Weg vom Sender zum MTA des Empfängers. Kann einer der beteiligten MTAs die E-Mail über einen konfigurierbaren Zeitraum, typischerweise sind das mehrere Stunden, nicht zustellen, schickt er eine Warnung an den Absender der E-Mail, versucht aber weiterhin die Mail zuzustellen. Scheitert er über einen längeren, zu konfigurierenden Zeitraum, gibt der MTA auf und schickt die Nachricht mit einer Fehlermeldung zurück an den Absender (siehe Abbildung 5).

Abbildung 5: Der Weg einer E-Mail vom Absender zum Empfänger durchläuft mehrere Stationen. Essenziell ist, dass keine Nachrichten verloren gehen. Darum speichert jeder MTA sie in Warteschlangen auf der Festplatte, bis der Empfänger bestätigt hat, sie empfangen zu haben.

Will sich der Administrator E-Mails anzeigen lassen, die sich aktuell in der Mailqueue befinden, stehen ihm dafür je nach MTA unterschiedliche Befehle zur Verfügung: Für Sendmail, Exim und Postfix funktionieren sowohl das Kommando »mailq« als auch der Aufruf »sendmail -bp«. Postfix kennt zusätzlich »postqueue -p«. Möchte der Postmaster den MTA dazu veranlassen, sofort und einmalig alle wartenden Mails in der Mailqueue abzuarbeiten, gibt er für Sendmail, Exim und Postfix das Kommando »sendmail -q« ein, Postfix kennt auch noch »postqueue -f«.

In den Anfangszeiten des Internets war es möglich, über jeden Mailserver eine E-Mail an einen beliebigen Empfänger zu schicken. Einen Mailserver, der sich heute so verhält, nennen Sicherheitsexperten ein “offenes Relay”. Da Spammer diese Systeme gerne missbrauchen, empfiehlt es sich nicht, solche offene Relays zu betreiben.

Dazu sind auf dem Mailserver zwei Einstellungen zu konfigurieren: Erst gibt der Admin an, für welche Clients sein Mailserver zuständig ist. Nur diese Rechner dürfen fortan den Server als Relay benutzen und Nachrichten an beliebige Adressaten über ihn schicken. Dann konfiguriert der Postmaster, für welche Domains sein Server zuständig zeichnet. Nur für diese Domains nimmt der Server dann Nachrichten entgegen. Dazu überprüft er, ob die Zieladressen der eingehenden E-Mails in seinem Zuständigkeitsbereich liegen.

Relaying

Sendmail bietet verschiedene Möglichkeiten, um das Relaying einzuschränken. Flexibel ist der Einsatz der Access-DB, die in »sendmail.mc« mit »FEATURE(access_db)« aktiviert wird. Steht in »/etc/mail/access«

linuxtag.org RELAY

erlaubt der Postmaster das Relaying für diese Domain. Alternativ kann er es, je nachdem, wie er Sendmail konfiguriert hat, auch in der Datei »/etc/mail/relay-domains« erlauben. Die Datei »/etc/mail/local-host-names« gibt an, für welche Hosts oder Domains der Server Post entgegennimmt.

Aus Leistungsgründen liest Sendmail diese Textdatei nicht direkt. Daher muss der Admin sie nach jeder Änderung in Binärform konvertieren:

makemap hash /etc/mail/access < /etc/mail/access

Postfix konfiguriert der Administrator in der Datei »/etc/postfix/main.cf«. Das Attribut »mynetworks« enthält eine Liste der Netzwerke oder Adressen, die diesen Server als Relay benutzen dürfen. Die zweite wichtige Einstellung konfiguriert er über das Attribut »mydestination«, das eine Liste der Domains enthält, für die dieser MTA zuständig ist. Um alles zu aktivieren, setzt er »smtpd_recipient_restrictions« auf »permit_mynetworks, reject_unauth_destination«.

Bei Exim ab Version 4 konfiguriert er das Relaying mittels Access Control Lists. Die relevante ACL für Relaying ist »acl_check_rcpt«, »accept hosts« gibt an, welche Hosts über den Server versenden dürfen. Das Attribut »accept domains« verlangt eine Liste von Domains, für die der MTA fortan E-Mails akzeptiert.

Der im Kasten “Protokoll einer ESMTP-Verbindung” beschriebene Telnet-Dialog eignet sich gut, um zu überprüfen, ob der Server ein offenes Relay ist. Dazu öffnet der simulierte Angreifer eine Verbindung von einem laut Konfiguration unberechtigten Rechner, um Mails einzuliefern. Ferner darf die Adresse des Empfängers nicht im Zuständigkeitsbereich des Servers liegen. Sind beide Bedingungen erfüllt und hat er die »RCPT TO:«-Zeile eingegeben, soll eine Warnung erscheinen:

554 5.7.1 <user@somewhere.com>: Relay access denied

So ist der Postmaster sicher, dass Spammer den Server nicht mißbrauchen.

Für Admins ist es außerdem oft problematisch, wenn jeder MTA in einem internen Netz eine direkte Verbindung zum Mail-Exchanger der Zieladresse öffnet. Firmennetzwerke haben oft viele Mailserver, dann ist es besser, Nachrichten bei einem zentralen Server abzuliefern. Der wird auch als Smarthost (schlauer Rechner) bezeichnet, da er die eigentliche Aufgabe wahrnimmt, die E-Mail zuzustellen. Zugleich vereinfacht sich die Aufgabe der einzelnen Abteilungs-MTAs, denn sie müssen nun keine MX-Abfragen mehr stellen.

220 mythos.linuxtag.org ESMTP
HELO butch.linuxtag.net
250 mythos.linuxtag.org
MAIL FROM: some-user@somehwere.org
250 2.1.0 Ok
RCPT TO: kester.habermann@linuxtag.org
250 2.1.5 Ok
DATA
354 End data with <CR><LF>.<CR><LF>
From: some-user@somehwere.org
To: kester.habermann@linuxtag.org
Subject: Von Hand verschickte Mail
Hallo, wie gehts?
.
250 2.0.0 Ok: queued as 18B47DC4008
QUIT
221 2.0.0 Bye

Schlauer Mailhost

Firewalls lassen in Firmennetzen meist keine eingehenden Verbindungen zu. Dann nimmt ankommende E-Mail denselben Weg wie über einen Smarthost ausgehende, nur in umgekehrter Richtung. Die Systemplaner bestimmen ein Mail-Gateway als MX für die gesamte Organisation, selbst wenn die Abteilungen eigene MTAs für ihre Sub-Domains betreiben. Das Gateway erhält alle eingehenden Nachrichten und leitet sie per Relaying weiter. Dieses System eignet sich auch, um die Nachrichten zentral auf Spam und Viren zu prüfen.

Die Konfiguration eines Smarthosts ist auch für den Heimanwender von Interesse. Für sie ist von Vorteil, Mails direkt vom Mail-Reader (im Fachjargon MUA, Mail User Agent genannt) abzusenden. Der Smarthost kümmert sich fortan um das Weiterleiten – unabhängig davon, ob gerade eine Netzwerkverbindung besteht oder nicht. Im letzteren Fall wartet der MTA einfach ab und versucht es später noch einmal.

Einige Mailserver akzeptieren keine E-Mails von Rechnern mit dynamisch zugewiesenen IP-Adressen, die Provider ihren Dial-up- oder DSL-Nutzern zuweisen. Solche Adressen werden nämlich oft von Spammern mißbraucht. Daher bieten ISPs fast immer Mailserver als Smarthosts an, die Nachrichten von den Onlinekunden annehmen. Dazu definiert Exim seinen Smarthost über:

smart_route:
  driver = manualroute
  transport = remote_smtp
  route_list = !+local_domains mail.net

Sendmail konfiguriert den Server durch einen Eintrag in »sendmail.mc«:

define(`SMART_HOST',`[mail.net]')dnl

Bei Postfix erreicht der Admin das Gleiche durch »relayhost=mail.net« in der Konfigurationsdatei »main.cf«.

Mail-Umleitung

Anwender wünschen sich oft, an bestimmte Empfänger adressierte E-Mails an andere Adressen um- oder weiterzuleiten (siehe auch den Artikel über Mailinglistensoftware in dieser Ausgabe). Der Systemverwalter trägt solche Weiterleitungen in der Datei »/etc/mail/aliases« ein, manchmal auch in »/etc/aliases«. In der zweispaltigen Textdatei steht in der linken Spalte eine lokale Adresse (ohne »@«), der ein Doppelpunkt folgt. Dazu muss kein Unix-Account existieren, durch den Eintrag in der Aliasdatei wird die Adresse gültig.

Die rechte Spalte definiert, was mit Nachrichten passieren soll, die der Mailserver für diese lokale Adresse empfängt. Auf der rechten Seite darf der Administrator auch mehrere Ziele, durch Komma getrennt, angeben. Jedes davon ist eine lokale, eine entfernte Adresse oder ein Programmpfad, den der MTA aufruft, um die Mail auszuliefern. Solche Ziele beginnen mit einem Pipe-Symbol »|«. Mailinglisten-Programme nutzen dieses Feature. Sie sind jedoch mit äußerster Vorsicht einzusetzen, da sie es externen Benutzern erlauben, lokale Programme zu starten:

root: user1, user2
postmaster: root
webmaster: wm@some-other-domain.org

Einige MTAs lesen die Aliasdatei nur beim Start und legen ihren Inhalt aus Performance-Gründen in einer Berkely-DB-Datei ab. Daher ist es nach Änderungen in der Aliasdatei nötig, »newaliases« aufzurufen. Das hat auch den Vorteil, dass ungültige Einträge sofort auffallen, da »newaliases« dann eine Fehlermeldung erzeugt. Für Sendmail, Exim und Postfix funktioniert sowohl das Kommando »newaliases« als auch der Aufruf »sendmail -bi«:

/etc/mail/aliases: 3 aliases, longest 24 bytes, 63 bytes total

Nutzer ohne Root-Rechte richten sich selbst eine Weiterleitung für ihre eigene Adresse ein, indem sie in ihrem Heimverzeichnis eine Datei mit Namen ».forward« anlegen. Der Inhalt gleicht der rechten Seite der Aliasdatei. Ein Aufruf von »newaliases« ist in diesem Fall nicht erforderlich.

Handwerkszeug

Das Aufsetzen eines Mailservers gehört zum Handwerkszeug eines Systemadministrators. Viele Distributionen haben schon gute Konfigurationen für den jeweiligen MTA an Bord, von denen der Admin nur noch wenige anpassen muss. Hat er einmal festgelegt, wie der MTA Nachrichten versenden soll und für welche Domains er sie akzeptiert, steht dem Empfang nichts mehr im Wege. (mg)