© Carlo Villa, 123RF

Sendmail oder Postfix in Betrieb zu nehmen, ist kein Vergnügen: Nach dem Wälzen dicker Bücher und Dokus unklarer Aktualität weiß der Admin am Ende doch nicht, ob das Ergebnis sicher ist. Als simpler zu administrieren und wegen der Open-BSD-Herkunft als sicherer gilt der MTA Open SMTPD.

Der Code komplexer und historisch gewachsener Software wie Sendmail ist extern kaum mehr tief und zugleich umfassend auf Fehlerfreiheit und Sicherheit zu prüfen. Hinzu kommt in dem speziellen Fall, dass allein die Konfigurationsdatei einem unübersichtlichen Moloch von vielen Hundert Zeilen gleicht. Jede einzelne Option darin kann vielfältige Auswirkungen auf das Verhalten und die Sicherheit des Mailservers haben.

Das sind eigentlich Gründe genug, um sich nach einer schlanken und zugleich sicheren Alternative umzuschauen. Der Blick schweift schnell zu Open SMTPD [1], dem MTA des Open-BSD-Teams. Open BSD ist bekannt für seinen hohen Sicherheitsstandard: In den letzten beiden Jahrzehnten gab es gerade mal zwei remote ausnutzbare Sicherheitslücken. Das liegt vor allem daran, dass strenge Coding-Standards, Code-Reviews und Datenflussanalysen Fehler verhindern oder wenigstens frühzeitig aufspüren.

Open SMTPDs Projektziele [2] entsprechen diesen Vorgaben: Sicherheit und Verlässlichkeit stehen ganz oben. Die Community erreicht das durch defensives Programmieren, Privilege Separation und eine schlanke Implementierung (Abbildung 1). Dazu kommt ein Konfigurationsfile, mit dem sich fast alle Mailserver-Standardfälle in weniger als zehn Zeilen lösen lassen – selbst komplexe Setups brauchen kaum mehr Aufwand.

Abbildung 1: Nur selten macht eine spät gefundene Sicherheitslücke eine neue Open-SMTPD-Version nötig.

Fertige Pakete gibt es für mehrere Linuxe

Open SMTPD fühlt sich nicht nur im Elternhaus Open BSD heimisch, sondern läuft auch auf Linux und anderen BSDs inklusive Mac OS X. Darum sollten Linux-Admins, die mit Postfix und Sendmail partout keine Freundschaft schließen wollen, Open SMTPD das Du anbieten. Für Gentoo, Slackware, Debian und Arch Linux gibt es fertige Packages. Gleiches gilt für Ubuntu, das im Folgenden als Basis dienen wird. Nach

sudo apt-get install opensmtpd

ist der MTA schnell installiert. Doch auch klassisch lässt sich Open SMTPD zügig ins System holen und auspacken:

wget https://www.opensmtpd.org/archives/opensmtpd-portable-latest.tar.gz
tar -xzf opensmtpd-portable-latest.tar.gz

Nachdem einige fehlende Pakete mit »apt-get« nachinstalliert sind, machen

./configure
make
sudo make install

den Postsack zu. Bei einer manuellen Installation muss der Admin die User »_smtpd« und »_smtpq« anlegen, andernfalls erledigt »apt-script« dies mit leicht abweichenden Namen (»opensmtpd« , »opensmtpq« ) jeweils mit einer User Private Group.

Die “smtpd.conf”

Die Konfigurationsdatei landet bei der Apt-Installation an dem für Open-BSDler ungewöhnlichen Ort »/etc/« (statt »/etc/mail/« ). Die Standard-»smtpd.conf« sorgt für eine positive Überraschung: Vier Zeilen Konfigurationsanweisungen reichen für die lokale Konfiguration, um Mails vom eigenen Rechner zu empfangen und weiterzuleiten.

Soll der Mailserver von außen erreichbar sein, gibt es mehrere Varianten. Die einfachste: »listen on all« nimmt Mails freizügig auf allen lokalen IP-Adressen entgegen. Wer dagegen zum Beispiel über Port 587 mit SMTP-Authentication und TLS Mails seinen Server von unterwegs nutzen und auf Port 25 alle normal eingehenden Mails abhandeln möchte, konfiguriert wie in Listing 1.

Die Zeilen 1 und 2 legen SSL-Keys für den Server fest, einen nur für die Authentifizierung entfernter Nutzer, den anderen für eingehende Mails. Man kann trefflich streiten, ob zwei Keys nötig sind, wenn absehbar kein zweiter Server geplant ist; die beiden Anweisungen zeigen aber, wie einfach mehrere Schlüssel einzubinden sind: Über die Kurznamen »post« und »mail« weisen die Zeilen 4 und 5 sie den jeweiligen Verbindungen zu.

Während Zeile 4 TLS optional anbietet, legt es Zeile 5 verpflichtend fest (»tls-require« ). Die einzelnen Ports nutzen unterschiedliche Rechnernamen. Wer das nicht möchte, lässt die Direktive »hostname« entfallen. Dann nimmt Open SMTPD den Rechnernamen des laufenden Systems. Zeile 5 verlangt zusätzlich, dass sich Nutzer authentifizieren. Zulässige SMTP-Nutzer enthält die Datei »smtpd_remote.db« . Die erzeugt

makemap smtpd_remote

aus der Datei »smptd_remote« . In dieser Textdatei stehen pro Zeile ein Nutzername und das zugehörige verschlüsselte Passwort, durch ein Tab getrennt. Die Passwortverschlüsselung erledigt:

smtpctl encrypt

Durch das Tag »remote« lassen sich die so eingereichten Mails später erkennen und gezielt einer besonderen Behandlung zuführen. Zeile 6 bestimmt, dass für Mails, die von Localhost kommen, kein TLS nötig ist. Open SMTPD beherrscht IPv4 und IPv6, wem das zu viel ist, darf pro vorgesehene Verbindung (Zeilen 4 bis 6) ausschließlich IPv4 erlauben oder aber den ganzen Mail Transfer Agent auf IPv4 beschränken (Zeile 7).

01 pki post key '/etc/ssl/private/post.example.org'
02 pki mail key '/etc/ssl/private/mail.example.org'
03 table remote db:/etc/smtpd_remote.db
04 listen on 192.0.2.15 inet4 port 25 hostname post.example.org tls pki post
05 listen on 192.0.2.15 inet4 port 587 hostname mail.example.org tls-require pki mail auth <remote> tag remote
06 listen on 127.0.0.1 inet4 port 25 hostname local.example.org
07 limit mta inet4

Mails weitergeben

Damit ist alles konfiguriert, was nötig ist, damit Open SMTPD Mails entgegennimmt – und das sogar in einer durchaus für die Verhältnisse des Programms aufwändigen Konstruktion. Jetzt muss Open SMTPD noch lernen die Mails auch zu verarbeiten. Dazu gibt es wieder mehrere Wege. Für echte lokale Nutzer des Linux-Systems stellt der »smtpd.conf« -Befehl

accept for local alias <aliases> deliver to mbox

die Mail zu. Dabei stehen in »aliases.db« analog zu Sendmail-Aliases jeweils eine Mailadresse und der Name eines lokalen Nutzers oder eine Empfänger-Mailadresse. Wer allerdings mehrere Domains besitzt und für die individuelle Mailadressen einrichtet, womöglich sogar mit Weiterleitungen, der muss etwas mehr einstellen:

accept from any for domain 'example.org' virtual <virtusers> deliver to mbox

Hier ist »virtusers« wieder aufgebaut wie eine »aliases« . Allerdings müssen die resultierenden Nutzernamen nicht real im System existieren, sondern können auch durch weitere Regeln aufgelöst werden, Listing 2 zeigt ein Beispiel. Dort löst dann »aliases« die »postmaster« auf, wenn es sonst keine andere Auflösung gibt. Die letzte Zeile demonstriert, wie der Sysadmin alle noch fehlenden Mailadressen auf einen Account umleitet. So ein Sammelaccount zieht allerdings Spam an, denn Spammer raten gerne Mailadressen.

Um die beiden Userlisten einzubinden, bedarf es zweier Schritte: Einmal muss sie der Admin in das schnellere »db« -Format übersetzen, das erledigt er mit:

makemap -t aliases aliases
makemap -t aliases virtusers

Zum anderen hat er die Liste in die »smtpd.conf« einzubinden:

table aliases db:/etc/aliases.db
table virtusers db:/etc/virtusers.db

Wer viele Domains hat, unter denen gleiche Mailadressen existieren, darf die Domainlisten auch in einer Tabelle hinterlegen – und dabei sogar Wildcards nutzen. Listing 3 (»domains« ) demonstriert das für Example.org, Example.net, Example.com und alle Subdomains von ihnen. Weil unter allen diesen Domains die gleichen E-Mail-Accounts existieren sollen, sieht die Datei »users« einfacher aus:

max     max
moritz  moritz@beispiel.de

Während die erste Zeile dafür sorgt, dass Open SMTPD Mails an »max@*.example.*« an den lokalen User Max weiterleitet, gehen Moritz’ Mails alle an »moritz@beispiel.de« . Die Liste lässt sich mit

makemap -t aliases users

in »users.db« überführen und dann in der »smtpd.conf« mit

table users db:/etc/users.db
table domains '/etc/domains'
accept from any for domain <domains> virtual <users> deliver to mbox

einbinden. Die dritte Zeile sorgt für die Zustellung. Das spart jenen Unternehmen Aufwand, die, um Domaingrabbern zuvorzukommen, viele zur eigenen Marke passende Domains registriert haben und unter allen erreichbar sein wollen. Bei Sendmail sind so flexible Wildcards nämlich nicht vorgesehen.

Die Dokumentation von Open SMTPD nennt zwar nur die Wildcard für Subdomains, die Wildcards funktionieren aber überall. Aus Sicherheits-Sicht und in Anbetracht der mittlerweile zahllosen Toplevel-Domains wäre »example.*« jedoch mit Vorsicht zu genießen.

max.muster@example.org        max
max@example.org                max.muster@example.org
mm@example.org                max@example.org
moritz@example.org        moritz@example.net
catchall@example.org        postmaster
@example.org                catchall@example.org

01 example.org
02 *.example.org
03 example.net
04 *.example.net
05 example.com
06 *.example.com

Der Mailversand

Damit die Mails für »moritz@beispiel.de« auch den eigenen MTA verlassen, ist in der »smtpd.conf« eine Zeile nötig:

accept from local for any relay

Ab nun relayt Open SMTPD die Mails über den für die jeweilige Empfängerdomain zuständigen Mailserver. Wer keine feste IP hat, wird an diesem Mechanimus aber wahrscheinlich keine Freude haben: Die meisten Mailempfänger blocken Absender mit dynamischen IPs anhand von Blacklists. Im besten Fall landen die Mails im Spam-Ordner der Empfänger.

Für Abhilfe kann ein vom Provider bereitgestellter Mailserver sorgen, ein SMTP-Smarthost, wie Sendmail ihn nennt. Auch das lässt sich mit Open SMTPD leicht bewerkstelligen:

accept from local for any relay via secure+auth://provider@mail.provider.de:25 auth <authtable>

Damit gehen Mails – wenn möglich – SSL- oder TLS-geschützt via Mail.provider.de raus. Um sich per SMTP-Auth gegenüber dem Server zu identifizieren, gibt es eine weitere Tabelle nach dem Muster:

provider  Username:Passwort

»provider« ist der Platzhalter, der in der Accept-Regel steht. Username und Passwort folgen im Klartext [3]. Das ist aus Sicherheits-Sicht unschön – für die Authentifizierung beim Relayserver sollte der Admin Kennwörter aussuchen, die er nirgendwo sonst benutzt. Zudem sollte er die Rechte der Konfigurationsdateien so gestalten, dass möglichst wenige sie lesen dürfen.

Das heimische LAN

Wer mit seinem Mailserver viele Clients zu versorgen hat, wird in der Regel alle lokalen IPs zum Versand nach außen freigeben wollen. Das kann wieder über Tables geschehen [3], aber auch direkt:

accept from source 10.0.0.0/24 for any relay

Sind mehrere E-Mail-Adressen über den heimischen Server zu verwalten, dann lässt sich das Relaying noch anhand der Absenderadresse variieren:

accept from source 10.0.0.0/24 sender 'max.muster@web.de' for any relay via  tls+auth://web@smtp.web.de
accept from source 10.0.0.0/24 sender 'max.muster@gmail.com' for any relay via  tls+auth://gmail@mail.google.com

Auch hier sind natürlich Platzhalter anwendbar. So würde »’@web.de’« alle Mails, deren Absenderadresse »web.de« enthält, über den Web.de-Server senden. Dabei sollte aber der Quell-IP-Bereich eingeschränkt sein, um kein zum Teil offenes Relay zu schaffen.

Schutz auf mittlerem Niveau

Open SMTPD will mehr Sicherheit bieten als seine Mitbewerber. Eine Maßnahme dafür ist, die Mailwarteschlange auf der Platte zu verschlüsseln, was

queue encryption key Schlüssel

erledigt. Den nötigen 16 Byte langen Key erzeugt zum Beispiel Open SSL:

openssl rand -hex 16

Natürlich ist ein Schlüssel, der in einer von Root zwangsläufig lesbaren Konfigurationsdatei im Klartext steht, nicht der Sicherheit letzter Schluss. Denn jeder Angreifer, der Rootrechte erlangt, kann ihn auslesen. Dennoch erschwert der Key Zufallsfunde von neugierigen Nutzern und schützt bei ungünstig vergebenen Dateirechten. Die Queue lässt sich mit

queue compression

noch komprimieren, was auch die Sicherheit der Verschlüsselung – so lange der Key geschützt ist – erhöht. Der Eintrag

max-message-size 20M

hilft dann noch gegen zu große Mails.

Testen, testen, testen

Hat der Admin seinen neuen Mailserver nach bestem Wissen durchkonfiguriert, geht’s ans Testen. Bewährt hat sich, die SMTP-Dialoge von Hand nachzufahren. Die Simulation des Einlieferns von Mails von außen, bei der TLS erforderlich ist, erweist sich als fummelig – allein die Authentifizierung ist nicht ganz trivial. Das Verschlüsselungsproblem löst:

openssl s_client -starttls smtp -connectmail.example.org:587 -crlf

Jetzt muss der Admin nur noch Passwort und Nutzername Base64-enkodieren, dazu unterstützt der SMTP-Auth-Befehl mehrere Varianten. Am einfachsten dürfte die Übergabe in einem Parameter sein. Die Base64-Codierung übernimmt:

perl -MMIME:Base64 -e 'print encode_base64("\000Username\000Password");'

Nun heißt es nach dem obligatorischen »EHLO« nur: »AUTH PLAIN Ausgabe« , wobei »Ausgabe« das Ergebnis der Base64-Kodierung ist. Anschließend sollten sich Mails von außen versenden lassen.

Schutz gegen Viren

Mit zum Beispiel Amavis (A Mail Virus Scanner, [4]) scannt Open SMTPD die ein- oder ausgehenden Mails auf Viren, gegebenenfalls auch auf Spam. Dass der Server keine extra Mailfilter-Schnittstelle wie Milter besitzt, erweist sich nicht als wirklich nachteilig: Amavis lauscht auf dem Mailserver an einem nicht privilegierten Port, nimmt dort die zu testenden Mails entgegen und liefert sie auf einem anderen Port von Localhost wieder an Open SMTPD zurück. Der nimmt sie entgegen, taggt sie und kann die Mails leicht verspätet in die normale Zustellung zurückpacken.

Das funktioniert natürlich genauso gut mit Clam AV und dem Clam SMTP [5], dem SMTP-Proxy für den Clamd. Gegenüber Amavis genießt er den Vorteil, wesentlich kompakter zu sein, und passt damit besser zur Open-SMTPD-Philosophie. Da die Konfiguration letztlich für Amavis und Clamsmtpd aus Sicht des MTA gleich ist, dient der schlanke Open-Source-Scanner als Beispiel.

Wer eingehende und ausgehende Mails scannen will, lässt zwei Clam-SMTP-Scanner laufen, um im weiteren Verlauf die Mails wieder unterscheiden zu können. Andernfalls entsteht durch die Hintertür womöglich ein offenes Relay. Die Konfiguration von Open SMTPD sieht dann so aus wie in Listing 4: Mails ohne Tag landen beim Virenscanner. Der schickt sie über die Ports 30025 und 40025 wieder zurück, je nachdem, ob es ein- oder ausgehende waren. Dabei erhalten die Nachrichten ein internes Tag, das zu einer besonderen Zustellung führt.

01 listen on all port 25
02 listen on 127.0.0.1 port 30025 tag scanned_out
03 listen on 127.0.0.1 port 40025 tag scanned_in
04
05 table aliases db:/etc/aliases.db
06
07 accept for local alias <aliases> deliver to mbox
08 accept tagged scanned_in for domain "example.com" virtual <users> deliver to mbox
09 accept tagged scanned_out for any relay
10
11 accept from any for domain "example.com" relay via smtp://127.0.0.1:10025
12 accept from source 10.0.0.0/24 for any relay via smtp://127.0.0.1:20025

Clamsmtpd einstellen

Der Clamsmtpd braucht nun zwei Konfigurationsdateien, um die ein- und die ausgehenden Mails zu unterscheiden. In der Ubuntu-Beispielkonfiguration steht das Beispiel-Config-File in »/etc/« , alle weiteren Konfigurationsdateien des Clam AV in »/etc/clamav« . Wen das stört, kann bei der Gelegenheit gleich aufräumen und die »clamsmtpd_out.conf« und »clamsmtpd_in.conf« in das richtige Verzeichnis verschieben.

Im Gegensatz zu [6] bevorzugt der Autor dieses Artikels bei lokaler Kommunikation einen Unix-Socket gegenüber einem TCP-Port auf Localhost, Ubuntu stellt das per se so ein. Damit ergeben sich die Änderungen gegenüber der Standard-»clamdsmtpd.conf« aus Listing 5 und Listing 6. Mit den zwei Befehlen

clamsmtpd -f /etc/clamav/clamsmtpd_in.conf
clamsmtpd -f /etc/clamav/clamsmtpd_out.conf

startet der Proxy. Zum Testen bietet es sich an, den Eicar-Testvirus [7] zu versenden, der keinen Schaden anrichtet, aber erkannt werden muss.

01 OutAddress: 40025
02 Listen: 127.0.0.1:10025
03 PidFile: /var/run/clamsmtp/clamsmtpd_in.pid

01 OutAddress: 30025
02 Listen: 127.0.0.1:20025
03 PidFile: /var/run/clamsmtp/clamsmtpd_out.pid

Header oder nicht?

[4] schlägt noch vor, über die Konfigurationsdatei einen zusätzlichen SMTP-Header einzufügen: »X-AV-Checked: ClamAV using ClamSMTP« . Für Testzwecke ist das durchaus sinnvoll, im Produktivbetrieb spricht zumindest für ausgehende Mails dagegen, dass Angreifer unnötig einfach erfahren, dass und welcher Virenscanner Dienst tut. Auch Virenscanner können Opfer von Angriffen werden – man denke nur an Zip-Bomben. Zwar lässt sich argumentieren, dass das Verschleiern des Scannermodells nur Security by Obscurity sei, andererseits: Eine potenzielle Angriffsfläche zu verbergen verschlechtert das Sicherheitsniveau im Ganzen gewiss nicht.

Wer paranoid genug ist, betreibt sowieso zwei Mailserver: Einer nimmt die Mails von außen nur an, der andere scannt. Wer dann noch Angst vor einem Einbruch über den Scanner hat, hängt noch eine dritte Maschine dahinter, auf der letztlich die Postfächer sind. Damit lassen sich schützenswerte E-Mails in den IMAP-Postfächern ganz gut isolieren.

Gegen den Hinweis-Header spricht auch ein rechtliches Argument: Ein Empfänger könnte ihn als Hinweis verstehen, dass die Mail sicher virenfrei sei, und alle Vorsicht fallen lassen. Doch jeder Virenscanner ist nur so gut wie sein letztes Signatur-Update – bei Clam AV ist dafür übrigens Freshclam per Cronjob zuständig – und birgt damit immer die Gefahr, dass Malware durchschlüpft. Je nach Rechtsauffassung könnte ein Hinweis-Header eine Haftung begründen.

Spamfilter

Wer neben Malware auch noch Spam filtern möchte, für den hält [8] eine Konfigurationsanleitung für den Spamassassin bereit. Dabei ist Vorsicht geboten: Peer Heinlein warnt regelmäßig davor [9], Spam-Mails einfach verschwinden zu lassen. Sinnvoller sei, sie in einen Spam-Ordner zu verschieben, wo der Benutzer bei Bedarf nachschauen könnte. Denn kein Filter ist vollkommen und falsch gefilterte Geschäftsmails könnten eine Haftung auslösen.

Der Autor des Artikels vertritt sogar eine noch engere Rechtsauffassung: Das übertriebene Filtern stellt eine Straftat dar, nämlich die Verletzung des Fernmeldegeheimnisses durch Unterdrückung. Zwar meinen andere, die Nutzer eines Mailservers gäben – stimmen sie der Filterung zu – eine so genannte tatbestandsausschließende Einwilligung. Doch die Versender von Mails, die ein Server ausfiltert, können diese nicht erteilen – und auch die schützt das Fernmeldegeheimnis.

Fazit und ein Blick zu BSD

Die kleine Anleitung zeigt: Open SMTPD ist tatsächlich ein extrem einfach zu konfigurierender und zugleich ausreichend mächtiger Mail Transfer Agent. Er zeigt sich viel übersichtlicher als die etablierten Spieler auf der Linux-Plattform. Wer noch keine jahrelange Erfahrung mit Sendmail hat, kommt mit Open SMTPD wesentlich schneller zum Ziel.

Open-SMTPD-Anwender, die sich gleich auch für das elterliche Betriebssystem Open BSD entscheiden, kommen zur Spambekämpfung noch in den Genuss des – mit der Firewall verwobenen und daher nicht portablen – Spamd, einer geschickten und effizienten Greylisting-Lösung mit Teergrube. (jk)