Die Grundversorgung mit E-Mail in größeren Netzen ist eine besondere Herausforderung für den Admin. Die meisten Linux-Distributionen geben sich zwar Mühe, die elektronischen Briefe irgendwie weiterzuleiten. Echte Admins können es aber besser.

Wer auf einer einzelnen Workstation arbeitet, wird mit seiner E-Mail kaum Sorgen haben. Mail User Agents (MUA) wie Mozilla, KMail oder Evolution holen die Post vom Internet-Provider ab und geben neue Mitteilungen bei ihm wieder auf. Sie unterhalten sich also direkt mit dem Mail Transfer Agent beim Provider, siehe Abbildung 1. In dieser Konfiguration kann nur ein einzelner User mit einem einzelnen Programm arbeiten. Benutzt er mehrere Clients, muss er diese meist getrennt einrichten.

Sobald mehrere Nutzer auf der gleichen Workstation arbeiten, lohnt es sich, einen lokalen Mail Transfer Agent (MTA) einzurichten (siehe Abbildung 2). Der klassische MTA ist Sendmail[1], beliebt sind auch QMail[2] und zunehmend Postfix[3]. Mit Hilfe des MTA können auch automatisch ablaufende Prozesse E-Mail verschicken. Gerne nutzt dies der Cron-Daemon, der alle Ausgaben seiner Jobs an Root mailt.

Zentraler Dienst

Bereits in einem kleinen Serverraum mit nur 30 oder 40 Geräten sieht dieses Szenario nicht mehr so gut aus. Angenommen, jeder Host würde abgehende E-Mails selbst versenden. Hier den Überblick behalten ist kaum möglich. Spätestens wenn Ihr Brötchengeber Statistiken verlangt, wenn Sie Verschlüsselungssysteme installieren oder einheitliche Archive anlegen sollen, müssten Sie jeden einzelnen Host im Netz umkonfigurieren. Diese lästige Arbeit sollten Sie sich ersparen und lieber auf eine zentralisierte Mail-Infrastruktur setzen. Auch für die Paketfilter ist es wesentlich geschickter, wenn die internen Geräte nicht beliebig direkte Verbindung mit der Außenwelt aufnehmen.

01 define(`SMART_HOST', `relay.myorg.de')dnl
02 FEATURE(`no_default_msa',`dnl')dnl
03 DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')
04 FEATURE(`nocanonify')dnl

Gemeinsam sind wir stark

Größere Installationen delegieren meist einen oder mehrere Computer zum Relay oder Smart Host (Abbildung 3). Er nimmt die intern abgesandten Mails an und leitet sie an den Empfänger weiter, egal ob dieser im eigenen Netz oder außerhalb sitzt. Alle erweiterten E-Mail-Funktionen können Sie auf den Smart Host verlagern: Für eine Statistik der Mails müssen Sie nur die Logdateien dieses Rechners analysieren.

Jeder interne Host leitet stur alle Mails an immer das gleiche Relay. Listing 1 zeigt diese Smart-Hosts-Konfiguration für Sendmail in der »m4«-Datei »…/sendmail/cf/cf/sendmail.mc«. Gleichzeitig schaltet diese Konfiguration den selten benutzten Message Submission Agent aus und beschränkt den Daemon auf lokale SMTP-Verbindungen (Simple Mail Transfer Protocol,[5]). Die Smart-Host-Einstellung für QMail ist deutlich einfacher. Eine Zeile in »/var/qmail/control/smtproutes« genügt:

:relay.myorg.de

Der SMTP-Daemon von QMail wird über Inetd aufgerufen. Nur dort können Sie ihn auf Localhost einschränken, zum Beispiel mit Hilfe des TCP-Wrappers. Bei Postfix sind beide Einstellungen in »/etc/postfix/main.cf« möglich:

relayhost = relay.myorg.de
inet_interfaces = 127.0.0.1

Freilich darf das zentrale Relay seine Dienste nur den eigenen Rechnern anbieten, sonst droht die Ausbeutung durch Spammer. Bei den meisten Distributionen sind diese Einstellungen bereits Routine. Dort dürften Sie eher auf Probleme stoßen, wenn Sie es dem Relay gestatten wollen, intern erzeugte Mails weiterzuleiten. Bei Sendmail bearbeiten Sie dafür die Datei »/etc/mail/relay-domains«, bei QMail setzen Sie die Umgebungsvariable »RELAYCLIENT« und bei Postfix ist die Variable »mynetworks« in »main.cf« zuständig.

Eingehende E-Mail direkt am Endgerät empfangen ist in den meisten Fällen ungeschickt. Die E-Mail-Adressen müssten dazu für jedes Gerät eine eigene Domain aufweisen. Außerdem müssten Sie eventuelle Spamfilter und Virenscanner auf jedem Rechner installieren. Nicht zuletzt stellt der offene Port 25 (SMTP) ein geringes, aber doch vorhandenes Sicherheitsrisiko dar.

Die übliche Lösung funktioniert ähnlich wie beim Mailversand: Ankommende Mails werden gebündelt von einer kleinen Gruppe spezialisierter Computer bearbeitet. Wie das im Detail funktioniert, hängt stark von der Struktur der eigenen Institution und vom erwarteten E-Mail-Aufkommen ab.

Abbildung 1: Der E-Mail-Versand ist für Single-Systeme einfach: Ihr Mailclient (MUA) kontaktiert direkt den Mailserver (MTA) beim Provider.

Abbildung 2: Beim sauberen E-Mail-Versand auf einer einzelne Workstation gibt der MUA die elektronische Mitteilung beim lokalen MTA ab.

01 mas@ishi:~> dig uni-trier.de mx
02 
03 ; <<>> DiG 8.3 <<>> uni-trier.de mx
04 [...]
05 
06 ;; ANSWER SECTION:
07 uni-trier.de.          1D IN MX   10 rzmail.uni-trier.de.
08 uni-trier.de.          1D IN MX   50 rzmail2.uni-trier.de.
09 
10 ;; AUTHORITY SECTION:
11 [...]

01 mas@ishi:~> dig aol.com mx
02 
03 ; <<>> DiG 8.3 <<>> aol.com mx
04 [...]
05 
06 ;; ANSWER SECTION:
07 aol.com.               1H IN MX   15 mailin-01.mx.aol.com.
08 aol.com.               1H IN MX   15 mailin-02.mx.aol.com.
09 aol.com.               1H IN MX   15 mailin-03.mx.aol.com.
10 aol.com.               1H IN MX   15 mailin-04.mx.aol.com.
11 
12 ;; AUTHORITY SECTION:
13 [...]
14 
15 ;; ADDITIONAL SECTION:
16 mailin-01.mx.aol.com.  5M IN A    64.12.138.152
17 mailin-01.mx.aol.com.  5M IN A    152.163.224.26
18 mailin-01.mx.aol.com.  5M IN A    205.188.156.122
19 mailin-01.mx.aol.com.  5M IN A    64.12.136.57
20 mailin-01.mx.aol.com.  5M IN A    64.12.137.89
21 mailin-01.mx.aol.com.  5M IN A    64.12.137.184
22 mailin-01.mx.aol.com.  5M IN A    64.12.138.57
23 [...]

Zentrale Poststelle oder verteilte Zustellung

Eine wichtige Frage ist, ob Sie angekommene Mail generell zentral vorhalten oder auf die einzelnen Geräte verteilen wollen. Die zentrale Lösung ist einfacher und leichter abzusichern. Das Verteilen der Mail ist vor allem in technisch hochqualifizierten Umgebungen günstiger, weil es dem einzelnen User mehr Konfigurationsmöglichkeiten lässt. Er kann die Rechenleistung seiner Workstation für zusätzliche Filter- und Sortieraufgaben einsetzen.

In jedem Fall nimmt ein zentraler MX-Host (Mail Exchange) die elektronische Post entgegen. Die Mails der Profi-User leitet er an deren Workstation weiter, alle anderen speichert er lokal. Auf den restlichen Hosts können Sie den SMTP-Daemon ganz abschalten oder auf den nur-lokalen Empfang beschränken. Vom zentralen Mailbox-Rechner zum Arbeitsplatzrechner gelangen die Mails per Post Office Protocol (POP) oder Internet Message Access Protocol (IMAP), manchmal auch über ein Netzwerkdateisystem (zum Beispiel NFS).

Die bisherigen Beispiele gingen davon aus, dass ein einzelnes Relay und ein einzelner MX-Host das Mailaufkommen bewältigen. In vielen kleinen bis mittelständischen Firmen ist sogar nur ein einziges Gerät für beide Funktionen zuständig. Erfahrungsgemäß schafft ein aktueller Computer etwa 25000 E-Mails pro Tag, je nach lokalen Verhältnissen auch deutlich mehr.

Senden ist schwerer als empfangen

Der Versand ist meist kritischer als der Empfang. Er braucht zwar weniger Rechenleistung, dafür sind die abgehenden Verbindungen aber oft langsam oder gar erfolglos. Damit bleiben die Ressourcen länger belegt. Zudem kommen MTAs wie QMail mit großen Mail-Warteschlangen nur sehr zäh zurecht. Die allgegenwärtige Spamflut führt aber dazu, dass meist nur ein Bruchteil der Arbeit auf abgehende Mails entfällt – so vereinfacht sich die Skalierung sogar.

Beim E-Mail-Empfang begrenzen eventuelle Filtermechanismen die Leistung des Systems. Je mehr und je komplizierter diese Mechanismen filtern, desto länger dauert der Empfang einer einzelnen Mail, desto weniger Mails kann das System parallel abarbeiten und desto weniger Mails wird ein einzelner Computer täglich verkraften.

Nun wird die sorgfältige Auswahl und Programmierung von Filtern kritisch. Procmail bietet sich für Einzelanwender an, um einfach und schnell einen Filter zu erstellen, der alle möglichen Produkte wie Spam Assassin oder Antivirensoftware einbindet. Sobald das Volumen eine kritische Grenze erreicht, wird Procmail zum Killer: Es ruft freizügig viele Kindprozesse auf, delegiert also seine Arbeit und verschwendet dabei Systemressourcen. Besser ist Sendmail mit seinem eleganten und schlanken Milter-Mechanismus[4].

Wenn Ihr Mailserver überlastet ist, sollten Sie zunächst nach ungeschickten Einstellungen suchen, zum Beispiel in Procmail. Doch nicht immer reicht das aus. Falls es sich um den MX-Host für ankommende E-Mails handelt, können Sie recht problemlos weitere MX-Hosts ergänzen. Listing 2 zeigt die typische gestaffelte MX-Konfiguration, hier am Beispiel der Uni Trier. Zu jedem MX-Server ist unmittelbar vor dem Rechnernamen eine Priorität angegeben.

Gezielt verteilte Last

Mailabsender benutzen nach Möglichkeit den Computer mit der niedrigsten Priorität, »rzmail.uni-trier.de« (Priorität 10) erhält also die meisten E-Mails. Nur wenn er ausfällt, kommt das Ersatzsystem »rzmail2.uni-trier.de« (Priorität 50) zum Einsatz. Diese Methode bietet eine gute Ausfallsicherheit, verteilt die Last aber nicht. Jeder Client und jeder MTA wird »rzmail.uni-trier.de« mit der E-Mail-Zustellung beauftragen.

Ganz anders AOL.com (siehe Listing 3). Die Firma kombiniert gleich zwei Methoden der Lastverteilung. Zum einen sind die vier MX-Hosts alle mit der gleichen Priorität 15 versehen und werden daher von außen abwechselnd benutzt. Wenn Sie den gezeigten »dig«-Befehl mit etwas Zeitabstand mehrmals eingeben, sehen Sie, dass sich die Reihenfolge der Angaben ändert.

Zusätzlich verweist jeder der vier MX-Einträge seinerseits auf mehrere IP-Adressen (ab Zeile 16 in Listing 3). So verteilt AOL die ankommenden Mails über zwei Stufen auf eine Vielzahl von Maschinen, die sich die Last teilen.

Für die Postfächer der Kunden muss AOL die Mails der einzelnen Server zusammenführen. Eine typische Lösung dazu könnte ein schneller Fileserver für die Mailboxen sein. Jeder der MX-Hosts hat das Mailverzeichnis des Servers gemountet und schreibt ankommende Nachrichten direkt in die Mailbox des korrekten Users. Das Verfahren ist aber nicht trivial: Es muss verhindern, dass zwei MX-Hosts gleichzeitig eine E-Mail an den gleichen Benutzer zustellen und sich gegenseitig in die Quere kommen. Auf solche Probleme und deren Lösung wird ein späterer Artikel eingehen.

Wieder zusammen

Die vorgestellte Architektur spart noch an einer anderen Stelle Ressourcen: Während ein einzelner, zentraler MX-Host die Daemons für POP oder IMAP selbst vorhalten muss, können Sie diese nun auf den Fileserver auslagern oder weitere Computern einsetzen. Den zweiten Trick (einen Rechnernamen im DNS auf viele IP-Adressen verweisen lassen) können Sie auch zur Lastverteilung des Relay-Servers nutzen. Ist er überlastet, stellen Sie ihm einfach einen zweiten mit gleichem Namen zur Seite. (fjl)

Abbildung 3: Ein zentraler E-Mail-Spezialist kümmert sich als Relay oder Smart Host um die Weiterleitung abgehender Nachrichten. Soll er die Konfiguration ändern, muss der Admin nur an einer Stelle eingreifen.