»Interaktive Dienste sollten höher priorisiert werden, da bei ihnen die Geschwindigkeit direkt erfahren wird!«
– Aus den Weisheiten eines Administrators
18 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 Anmerkungen gemacht werden.
18.1 Mailserver in Theorie und Praxis 

Zuerst einmal möchten wir klären, 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 Mailservern aus Dial-up-Pools von den meisten Providern auch gar nicht erst angenommen.]
SMTP versus POP3/IMAP
Auch sprechen wir bei E-Mail in der Regel von zwei Serverklassen: von SMTP-Servern, die Mails entgegennehmen und versenden, und 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.
18.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 einer Mail 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 Standard-Port 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: xyz@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 18.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, 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:
- 1XX
Bei diesem Statuscode wurde die Eingabe zwar akzeptiert, jedoch ist noch eine Bestätigungsmeldung erforderlich.
- 2XX
Der Befehl wurde korrekt und ohne Fehler ausgeführt. Im Beispiellisting wurden ausschließlich 2XX-Codes zurückgegeben.
- 3XX
Bei diesem Code benötigt der Mailserver weitere Informationen, um den Befehl ausführen zu können.
- 4XX
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.
- 5XX
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 Praxiskontext gesetzt werden. Die einzelnen Schritte beim Versenden einer E-Mail sehen dabei in der Regel wie folgt aus:
- Mailclient: Senden an den Smarthost
Im Mailclient ist konfiguriert, an welchem Mailserver – dem sogenannten Smarthost – alle ausgehenden E-Mails versendet werden sollen. [Ein Smarthost ist ein E-Mail-Server, der von einem Sender E-Mails annimmt und an beliebige Empfänger weiterleitet.] 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. 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 Authentifizierungs-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. - Smarthost: Lookup des Empfängers
Damit der Smarthost die E-Mail dem Empfänger zustellen kann, muss er 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. - 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:
- Mailserver: Mails abholen mit POP3 oder IMAP
Auf dem Zielsystem angekommen, müssen die Mails 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.
$ host -t MX ploetner-it.de ploetner-it.de mail is handled by 10 mail.ploetner-it.de.
Listing 18.2 Den MX-Record per Hand aus dem DNS abfragen
Anschließend wird die E-Mail mittels SMTP an diesen Server übertragen.$ host -t TXT gmx.de gmx.de descriptive text "v=spf1 ip4:213.165.64.0/23 -all"
Listing 18.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 (siehe Abschnitt 18.1.3) des Servers beziehungsweise der Absenderadressen auf dem Mailserver, der die weitergeleiteten Mails empfängt.
Mails abholen
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öswilligen Content bereits frühzeitig auszufiltern. Virenscanner sind dabei ein wichtiger Baustein.
18.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 Dämon 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.
18.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 SpamAssassin-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 8 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 18.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 schließt anhand von charakteristischen Wörtern in einer E-Mail auf die Wahrscheinlichkeit, dass es sich bei dieser Mail um Spam handelt. Damit ein Bayes-Filter ordentlich funktionieren kann, muss man diesen »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 von ihrem Inhalt – 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 Punkteschema des SpamAssassins ein. So vergeben Whitelists normalerweise –100 und Blacklists 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.