Interaktive Dienste sollten höher priorisiert werden, da bei ihnen die Geschwindigkeit direkt erfahren wird! -- Aus den Weisheiten eines Administrators

13 Mailserver unter Linux

In diesem Kapitel möchten wir einige der vielfältigen Möglichkeiten betrachten, einen Mailserver unter Linux zu betreiben.

Bevor wir uns jedoch auf konkrete Configfiles stürzen, sollen noch einige Bemerkungen gemacht werden.

13.1 Mailserver in Theorie und Praxis

Zuerst einmal möchten wir betrachten, wer überhaupt was für Mailserver braucht. Normalerweise sind Mailserver nur für Unternehmen mit eigenem IP-Segment und Standleitung interessant – Hobby-Bastler können zwar mit über Nacht laufenden Systemen und DynDNS experimentieren, aber ein produktives System sollte man aufgrund der Ausfallgefahr trotzdem nicht unbedingt aufsetzen. <Darüber hinaus werden E-Mails von Mailserverrn aus Dial-Up-Pools von den meisten Providern auch gar nicht erst angenommen.>

SMTP vs. POP3/IMAP

Auch sprechen wir bei E-Mail in der Regel von zwei Serverklassen: von SMTP-Servern, die Mails entgegennehmen und versenden, sowie von POP3-/IMAP-Servern, über die die Benutzer ihre Mails abrufen können. In kleinen Umgebungen kann man beide Dienste zwar auch über ein System realisieren, doch gerade in größeren Unternehmen skaliert der verteilte Ansatz besser.

13.1.1 Funktionsweise von Internet-Mail

Wie aber funktioniert »E-Mail« nun konkret? Im Folgenden wollen wir die wichtigsten Schritte vom Schreiben bis zur Auslieferung betrachten, um anschließend auf wichtige Features und Techniken gesondert einzugehen.

Das Simple Mail Transfer Protocol

E-Mails versenden

Das Simple Mail Transfer Protocol (SMTP) ist das Protokoll, das seit Urzeiten zum Versenden von E-Mails benutzt wird.

Da es textbasiert und für Menschen lesbar arbeitet, kann man die Funktionsweise anhand einer einfachen telnet-Sitzung nachvollziehen. Dazu wird eine Verbindung mit einem Mailserver auf Port 25 aufgebaut, dem Standardport für SMTP.

$ telnet mail.ploetner-it.de 25 
Trying 89.110.147.184... 
Connected to mail.ploetner-it.de. 
Escape character is '^]'. 
220 v935.ncsrv.de ESMTP Exim 4.63 Tue, 01 May 2007 13:34:46 +0200 
HELO localhost 
250 mail.ploetner-it.de Hello localhost 
MAIL FROM: test@localhost 
250 OK 
RCPT TO: jploetner@ploetner-it.de 
250 Accepted 
DATA 
354 Enter message, ending with "." on a line by itself 
From: "Ich bins!" <test@localhost> 
To: "Johannes" <jploetner@ploetner-it.de> 
CC: swendzel@ploetner-it.de 
Subject: Das ist eine Testmail 
 
Hallo. 
 
Das ist eine normale Testmail mit einem Header und etwas Text. 
Nix Besonderes. 
 
MfG 
. 
250 OK id=1Hiqdl-0007Hn-Am 
QUIT 
221 mail.ploetner-it.de closing connection 
Connection closed by foreign host.

Listing 13.1 Eine SMTP-Sitzung

In diesem Beispiel kann man die fünf wichtigsten SMTP-Befehle erkennen: HELO, MAIL FROM, RCPT TO, DATA und natürlich QUIT. Mit HELO stellt sich der versendende Rechner vor, und mittels MAIL FROM und RCPT TO gibt er den Absender beziehungsweise den Empfänger an. Die eigentliche Mail wird dann aber – samt Header! – im DATA-Befehl übertragen. Der im Beispiel verwendete Beispiel-Mailheader enthält wiederum das eigentliche »From«, »To«, »CC« und »Subject« der Mail. Im Normalfall werden »From« und »To« mit den in MAIL FROM und RCPT TO angegebenen Adressen übereinstimmen – sie müssen es aber nicht. Zwischen dem Header und dem eigentlichen Text der Mail muss eine Leerzeile liegen, und abgeschlossen wird der Text durch einen vereinzelten Punkt auf einer Zeile. Die Verbindung wird anschließend noch durch ein QUIT korrekt geschlossen.

Nach jedem SMTP-Befehl antwortet der Server mit einem Statuscode. Folgende Statuscodes sind definiert:

Bei diesem Statuscode wurde die Eingabe zwar akzeptiert, jedoch ist noch eine Bestätigungsmeldung erforderlich.

Der Befehl wurde korrekt und ohne Fehler ausgeführt. Im Beispiellisting wurden ausschließlich 2XX-Codes zurückgegeben.

Bei diesem Code benötigt der Mailserver weitere Informationen, um den Befehl ausführen zu können.

Dieser Status zeigt einen temporären Fehler oder eine Überlastsituation beim Mailserver an. Zu einem anderen Zeitpunkt kann dieselbe Befehlsfolge durchaus zum Erfolg führen.

Dieser Statuscode zeigt einen fatalen Fehler an. Die Ausführung des SMTP-Befehls ist fehlgeschlagen.

Mailversand in der Praxis

Im Folgenden soll nun das SMTP-Protokoll in den richtigen Praxis-Kontext gesetzt werden. Die einzelnen Schritte beim Versenden einer E-Mail sehen dabei in Regel so aus:

1. Mailclient: Senden an den Smarthost

Im Mailclient ist meist konfiguriert, an welchem Mailserver – den sogenannten Smarthost – alle ausgehenden E-Mails versendet werden sollen. Der Mailclient verständigt sich mit diesem Server über das SMTP-Protokoll. Steht dieser Server im Internet, so muss sich der Mailcient in der Regel über eines von vielen möglichen Verfahren authentifizieren.

Ein Smarthost ist ein E-Mail-Server, der von einem Sender E-Mails annimmt und an beliebige Empfänger weiterleitet.

Da das ursprüngliche SMTP-Protokoll keine Mechanismen zur Authentifizierung <Wird der Zugriff auf einen Smarthost nicht eingeschränkt und kann jeder beliebige Internetnutzer über diesen Server E-Mails versenden, so spricht man von einem offenen Relay. Es ist ein großer Fehler, ein offenes Relay einzurichten, da der Server ziemlich schnell von Spammern missbraucht und in der Folge von vielen E-Mail-Anbietern geblockt werden wird.> bietet, wurden später verschiedene Features nachgerüstet. Diese Auth-Verfahren kann man nur mit Extended-SMTP (ESMTP) nutzen – das erste Kommando des SMTP-Clients heißt hier dann nicht mehr HELO, sondern EHLO. Je nach SMTP-Server und Konfiguration stehen dann weitere SMTP-Befehle zur Verfügung, um sich mit dem eigenen Benutzernamen und Passwort »einzuloggen«. Erst danach kann mit MAIL FROM und den anderen Befehlen eine E-Mail verschickt werden.

2.Smarthost: Lookup des Empfängers

Damit der Smarthost die E-Mail an den Empfänger zustellen kann, muss er zuerst wissen, welcher Server überhaupt für die Domain des Empfängers zuständig ist. Dazu ruft er aus dem DNS den MX-Record der Domain des Empfängers ab.

$ host -t MX ploetner-it.de 
ploetner-it.de mail is handled by 10 mail.ploetner-it.de.
Listing 13.2 Den MX-Record per Hand aus dem DNS abfragen

Anschließend wird die E-Mail mittels SMTP an diesen Server übertragen.

3. Optional: Sender Policy Framework (SPF)

Der Mailserver des Empfängers kann durch das Sender Policy Framework feststellen, ob der sendende Mailserver überhaupt autorisiert ist, Mails für eine bestimmte Domain zu versenden. Welche Systeme zum Versenden von E-Mail einer Domäne berechtigt sind, ist aus dem SPF- oder TXT-Record des DNS-Eintrags der Domain ersichtlich:

$ host -t TXT gmx.de 
gmx.de descriptive text "v=spf1 ip4:213.165.64.0/23 -all"
Listing 13.3 Den SPF-Record per Hand aus dem DNS abfragen

Dieses Beispiel zeigt, dass für die Domain gmx.de nur Rechner aus dem Netz 213.165.64.0/23 Mails verschicken dürfen. Ein Mailserver, der SPF unterstützt, wird also keine Mails mit einer GMX-Absenderadresse annehmen, wenn diese von anderen Rechnern verschickt werden. <Darum sollten Sie sich auch hüten, solche »fremden« Adressen über einen selbst betriebenen E-Mail-Server zu verschicken.>

Allerdings wird SPF nicht von allen Mailservern unterstützt oder genutzt, da es durchaus einige Probleme und Kritikpunkte an diesem Verfahren gibt: Beispielsweise ist das automatische Weiterleiten von E-Mails schwierig, da der weiterleitende Rechner unter Umständen nicht per SPF autorisiert ist, entsprechende Absenderadressen zu verwenden. Abhilfe schafft hier jedoch ein Whitelisting des Servers beziehungsweise der Absenderadressen auf dem Mailserver, der die weitergeleiteten Mails empfängt.

4. Mailserver: Mails abholen mit POP3 oder IMAP

Mails abholen
Auf dem Zielsystem angekommen, müssen die Mails natürlich noch vom Empfänger abgeholt werden. Für diesen Vorgang kommt nicht SMTP, sondern ein anderes Protokoll – in der Regel POP3 oder IMAP – zum Einsatz. Über eines der beiden Protokolle wird sich der E-Mail-Client des Empfängers mit dem Server verständigen, um sich über die Anzahl ungelesener E-Mails informieren zu lassen und diese gegebenenfalls auch herunterzuladen.

SMTP-Server müssen nun aber oft mehr leisten, als E-Mails einfach nur korrekt weiterzuleiten beziehungsweise auszuliefern. Gerade in Produktivsystemen mit vielen Nutzern ist es wichtig, »bösen« Content bereits frühzeitig auszufiltern. Virenscanner sind dabei ein wichtiger Baustein.

13.1.2 Virenschutz

ClamAV

Der bekannteste Virenscanner für Linux ist sicherlich der Open-Source-Scanner ClamAV. ClamAV kann als Bibliothek in eigene Programme eingebunden werden, steht jedoch auch als Daemon und als Kommandozeilenprogramm zur Verfügung. Neben ClamAV gibt es noch weitere Virenscanner wie beispielsweise den McAfee vscan für Linux. Jedoch sollte man nicht vergessen, dass diese Scanner fast ausschließlich nach Viren für »Fremdbetriebssysteme« suchen und deshalb auch vor allem auf Mail- oder Fileservern eingesetzt werden.

13.1.3 Spamschutz

Ein weiterer wichtiger Punkt ist der Schutz vor Spam. Kaum ein Mailserver kommt heute noch ohne effektiven Spamfilter aus. Der unter Linux und anderen Unix-Systemen am häufigsten eingesetzte Spamfilter ist der SpamAssassin. Die Perl-basierte Software kann mit vielen verschiedenen SMTP-Servern, aber teilweise auch mit Mailclients eingesetzt werden, um eingehende E-Mails auf Spam zu untersuchen.

SpamAssassin wendet auf jede Mail einen ganzen Satz von Regeln an. Jede zutreffende Regel vergibt dabei einen bestimmten Punktwert, und erst wenn die Summe dieser Punkte einen gewissen Schwellenwert übersteigt, wird die Mail als Spam gekennzeichnet. Je nach Konfiguration werden die Mails in diesem Fall mit einem bestimmten Betreff (beispielsweise »**** SPAM ****«) oder über einen speziellen Header-Eintrag entsprechend markiert.

Reguläre Ausdrücke

Normale Spam-Assassin-Regeln sind eigentlich nichts weiter als reguläre Ausdrücke <Falls Sie selbst Regeln schreiben wollen: Regulären Ausdrücken haben wir das ganze Kapitel 4 gewidmet. :-)>. Eine einfache Regel kann dabei beispielsweise so aussehen:

body     FB_HARD_ERECTION  /hard(?:er)? (?:erection|penis)/i 
score    FB_HARD_ERECTION  2.169

Listing 13.4 Regel im SpamAssassin

Der Name der Regel ist hier »FB_HARD_ERECTION«. Wird in der Mail ein Text wie »harder erection« gefunden, auf den der reguläre Ausdruck passt, so werden zum aktuellen Score der E-Mail 2,169 Punkte addiert. Da der Standard-Schwellenwert meist bei 5 Punkten liegt, ist dann die Grenze zur Markierung als »Spam« schnell überschritten. Solche Regeln kann man auch recht einfach selbst schreiben, allerdings erfordert die Punkte-Bewertung sowie die genaue Gestaltung des regulären Ausdrucks ein hohes Maß an Fingerspitzengefühl und Erfahrung.

Bayes-Filter

Statistisches Filtern

In SpamAssassin kann aber auch ein sogenannter Bayes-Filter zum Einsatz kommen. Dieser statistische Filter versucht anhand von charakteristischen Wörtern in einer E-Mail auf die Wahrscheinlichkeit zu schließen, dass es sich bei dieser Mail um Spam handelt. Damit ein Bayes-Filter ordentlich funktionieren kann, muss man diesen natürlich trainieren: Man gibt dem SpamAssassin eine Mailbox voller Spam sowie eine Mailbox voller »Ham« (also Nicht-Spam, normale Mails). Anhand dieser Charakteristiken wird dann eine Bayes-Datenbank aufgebaut, mithilfe derer dann die Wahrscheinlichkeit ermittelt werden kann, dass es sich bei einer untersuchten E-Mail um Spam handelt. Je nach Wahrscheinlichkeit können dann wieder unterschiedliche Punktwerte vergeben werden. <Dabei sind für geringe Wahrscheinlichkeiten natürlich auch negative Werte möglich, um den Score insgesamt etwas abzusenken.>

White- und Blacklists

Auch eine Art »Regel« stellen White- und Blacklists dar. In einer Whitelist sind alle Absender oder Absenderdomains eingetragen, denen man vertraut und von denen man keinen Spam erwartet. Diese Mails sollen also – unabhängig vom Inhalt der Mail – immer unmarkiert ankommen. Im Gegensatz dazu kann man über Blacklists bestimmte Absender oder ganze Domains von vornherein sperren. Natürlich gliedern sich auch White- und Blacklists in das Punkte-Schema des SpamAssassins ein. So vergeben Whitelists normalerweise –100 und Blacklists ganze 100 Punkte.

Greylisting

Temporäres Zurückweisen

Greylisting beschreibt ein relativ neues Konzept, mit dem Spam effektiv abgewehrt kann. Die Idee hinter Greylisting ist, eine E-Mail beim ersten Zustellungsversuch temporär abzuweisen. »Echte« SMTP-Server werden die Zustellung nach einer gewissen Zeit erneut versuchen, während von fiesen Spammern gekaperte Rechner diesen Zustellungsversuch wahrscheinlich nicht erneut unternehmen.

Im Detail ist der Ablauf beim Greylisting wie folgt:

1. SMTP-Verbindung des Absenders

Die Verbindung des Absenders läuft bis zum RCPT TO:-Schritt genau so ab wie in obigem Beispiel. Danach allerdings wird ein temporärer Fehler gemeldet:

$ telnet mail.ploetner-it.de 25 
Trying 89.110.147.184... 
Connected to mail.ploetner-it.de. 
Escape character is '^]'. 
220 v935.ncsrv.de ESMTP Exim 4.63 Tue, 01 May 2007 13:34:46 +0200 
HELO localhost 
250 mail.ploetner-it.de Hello localhost 
MAIL FROM: johannes.ploetner@de.clara.net 
250 OK 
RCPT TO: jploetner@ploetner-it.de 
451-212.82.240.100 is not yet authorized to deliver mail from 
451 <johannes.ploetner@de.clara.net> to <jploetner@ploetner-it.de>. Please try later.

Listing 13.5 Eine SMTP-Sitzung

Zu diesem Zeitpunkt kenn der Greylisting einsetzende Empfänger drei Daten: die Absender-IP-Adresse, von der die Verbindung stammt, den Absender sowie den Empfänger der Mail. Dieses Tripel wird nun gespeichert.

2. Warteschlange

Der Absender ist laut SMTP-Protokoll nun verpflichtet, den Zustellungsversuch nach einer gewissen Zeit (meist ist eine halbe Stunde eingestellt) zu wiederholen. Sollte dieser Versuch wieder fehlschlagen, wird die Zeit bis zum nächsten Versuch meist etwas erhöht.

3. Zweiter Versuch

Beim Zweiten Versuch des absendenden Mailservers hat der Empfänger das (Absender-IP, Absender-E-Mail, Empfänger-E-Mail)-Tripel schon in seiner Datenbank und wird diesen Zustellversuch annehmen.

4. Whitelists

Normalerweise wird das betreffende Tripel nach einer solchen erfolgreichen Zustellung noch in eine temporäre Whitelist eingetragen, damit bei einer erneuten Kommunikation des betreffenden Absenders mit dem zugehörigen Empfänger für die Dauer des Whitelistings keine temporäre Zurückweisung mehr erfolgt.

Spam-Erkennung zu SMTP-Zeit

Error nach DATA

Normalerweise werden E-Mails erst nach dem Empfang auf Spam gescannt und gegebenenfalls in einen separaten Spam-Ordner verschoben oder gleich ganz gelöscht. Eine Alternative dazu ist das Scanning zu SMTP-Zeit. Dabei wird, während vom versendenden Host noch die DATA-Sektion gesendet wird, die E-Mail bereits auf Spam gescannt. Wird eine Spam-Mail vermutet, bekommt dies der versendende Host direkt nach der DATA-Sektion als Errorcode zurückgeliefert. Normalerweise hat der SMTP-Server, der die Mail nicht ausliefern konnte und den Fehlercode bekam, dann eine Error-Mail an den Absender zu schicken.

Diese Mail soll den Absender informieren, dass sein Zustellversuch fehlgeschlagen und die E-Mail nicht angekommen ist.

Im Folgenden wollen wir nun jeweils eine Möglichkeit betrachten, wie man unter Linux einen entsprechenden SMTP- bzw. POP3/IMAP-Server aufsetzen kann. Aufgrund der vielfältigen Softwareprojekte kann man die hier vorgestellte Funktionalität aber auch mit völlig anderen Komponenten realisieren.