»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 Konfigurationsdateien stürzen, sollen noch einige Anmerkungen gemacht werden.
18.1 Mailserver in Theorie und Praxis
Zuerst einmal möchten wir klären, wer überhaupt welchen 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. [Fn. 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.
Listing 18.1 Eine SMTP-Sitzung
$ 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 bin's!" <test@localhost>
To: "Johannes" <jploetner@ploetner-it.de>
CC: xyz@ploetner-it.de
Subject: Dies ist eine Testmail
Hallo.
Dies 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.
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 auf einer Zeile einzeln stehenden Punkt. 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. [Fn. 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 [Fn. 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 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 dem Empfänger die E-Mail 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.
Listing 18.2 Den MX-Record per Hand aus dem DNS abfragen
$ host -t MX ploetner-it.de
ploetner-it.de mail is handled by 10 mail.ploetner-it.de.
Anschließend wird die E-Mail mittels SMTP an diesen Server übertragen.
Listing 18.3 Den SPF-Record per Hand aus dem DNS abfragen
$ host -t TXT gmx.de
gmx.de descriptive text "v=spf1 ip4:213.165.64.0/23 -all"
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. [Fn. Darum sollten Sie sich auch hüten, Mails von solchen »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 Whitelist) 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 die Open-Source-Software ClamAV. Sie kann als Bibliothek in eigene Programme eingebunden werden, steht jedoch auch als Dämon und als Kommandozeilenprogramm zur Verfügung. Neben ClamAV gibt es für Linux noch weitere Virenscanner wie beispielsweise VirusScan von McAfee. 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 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. Jedes Zutreffen einer Regel führt zur Vergabe eines bestimmten Punktwerts, und erst wenn die Summe der 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 einen speziellen Header-Eintrag entsprechend markiert.
Reguläre Ausdrücke
Normale SpamAssassin-Regeln sind eigentlich nichts weiter als reguläre Ausdrücke. [Fn. 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:
Listing 18.4 Regel im SpamAssassin
body FB_HARD_ERECTION /hard(?:er)? (?:erection|penis)/i
score FB_HARD_ERECTION 2.169
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 erfordern die Punkte-Bewertung und 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 ihr um Spam handelt. Damit ein Bayes-Filter ordentlich funktionieren kann, muss man ihn »trainieren«: Man gibt 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. [Fn. 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.
[zB]Im Detail ist der Ablauf beim Greylisting wie folgt:
- 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: - Warteschlange
Der Absender ist laut SMTP-Protokoll 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. - Zweiter Versuch
Beim zweiten Versuch des absendenden Mailservers hat der Empfänger das Tripel (Absender-IP, Absender-E-Mail, Empfänger-E-Mail) schon in seiner Datenbank und wird diesen Zustellversuch annehmen. - 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.
Listing 18.5 Eine SMTP-Sitzung
$ 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.
Zu diesem Zeitpunkt kennt 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.
Spam-Erkennung zur Versandzeit
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 zur Versandzeit SMTP-time filtering). 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 Error-Code zurückgeliefert. Normalerweise hat der SMTP-Server, der die Mail nicht ausliefern konnte und den Fehlercode empfing, 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 eine Möglichkeit betrachten, wie man unter Linux einen SMTP- oder POP3/IMAP-Server aufsetzen kann. Aufgrund der vielfältigen Softwareprojekte kann man die hier vorgestellte Funktionalität aber auch mit ganz anderen Komponenten realisieren.
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.