Simon Szustkowski

Ein Blog über alles, was mir gerade so durch den Kopf geht

Jul 9, 2015

OpenSMTPd auf Debian Jessie installieren

Seit jeher läuft auf meinem Webserver auch eine gewisse Mail-Infrastruktur. Ursprünglich eingerichtet, um wirklich alles selbst zu machen, war sie in ihren Hochzeiten eine ziemlich unheilige und gefrickelte Kombination aus Postfix, saslauthd, postgrey, MySQL, Spamassassin, Dovecot, Amavis, Sieve, ClamAV und Roundcube. Da ich das alles bei der Installation nicht wirklich dokumentiert hatte, und daher bei jeder kleinsten Config-Änderung wieder stundenlang debuggen musste, wieso ich jetzt wieder keine Mails bekam, wurde es mir irgendwann zu bunt, und ich lagerte meine Mails wieder an Googlemail aus. (Drin vor: “OMG datenschutz NSA hurr durr”, ich weiß, was ich tue). Doch irgendwie blieb dieses stundenlange debuggen, wieso irgendwas nicht funktionierte, weiter vorhanden. Ich hatte wohl in der Vergangenheit den Postfix und Dovecot derart miteinander verzahnt, dass einer nicht ohne den anderen funktionierte, und ich daher, selbst bei einer simplen Weiterleitung der Mails an meine Domain zu Google, immer noch Dovecot dabei laufen haben musste. Kurz: Es war ein wucherndes Krebsgeschwür, und hochgradig unzufriedenstellend.

Ich entschloss mich dazu, nach dem Einrichten eines Backup-MX, mal alles rauszuwerfen, und von Beginn auf neu hochzuziehen. Ein bisschen schreckte es mich immer noch ab. Ich bräuchte zwar nurmehr einen Postfix, aber auch der ist mittlerweile so unhandlich zu konfigurieren, und in seiner Grundeinstellung inhärent unsicher (sprich: Ein offenes Relay ohne Authentifizierung), dass es mir Bauchschmerzen bereitete.

Enter OpenSMTPd. Ein noch relativ neuer MTA, der ursprünglich für OpenBSD geschrieben wurde, da Postfix aus Lizenzgründen nicht auf OpenBSD lief, und die anderen Alternativen weitaus archaischer und schlimmer waren. Und glücklicherweise waren die Developer von OpenSMTPd offenbar genau so angefressen von der frickeligen Konfiguration aller etablierter MTAs, dass sie großen Wert auf einfache Konfiguration legten. Ich war gespannt, und wollte es mal testen.

Aber ach. Er ist noch nicht in dem Stable Branch von Debian Jessie vorhanden. Man muss also die heiligen Debian-Grundsätze über Bord werfen, und Pakete aus Testing installieren. Es lohnt sich aber. (Fun Fact am Rande: Die User aus dem deutschen Debianforum rieten mir davon ab, Pakete aus Testing zu installieren, und lieber Postfix zu nutzen, da wüsste man ja, was man hat. Nun. OpenSMTPd wäre nicht der neue Default-MTA von OpenBSD geworden, wenn er so instabil wäre. Hinzu kommt, dass ich Postfix aufgrund seiner Frickelconfig auch als relativ instabil erachte).

Aber nun Schritt für Schritt. Ihr fügt zunächst die Testing-, und im gleichen Fall, die Unstable-Repos zu eurer /etc/apt/sources.list hinzu:

## DEBIAN TESTING
deb http://httpredir.debian.org/debian testing main contrib non-free

## DEBIAN UNSTABLE
deb http://httpredir.debian.org/debian unstable main contrib non-free

Damit euer apt jetzt nicht alle Pakete aus Testing zieht, weil sie ja offenbar neuer sind, muss über apt-pinning die Priorität der Repositories festgelegt werden. Hierzu schreibt ihr folgendes in die /etc/apt/preferences:

Package: *
Pin: release a=stable
Pin-Priority: 700

Package: *
Pin: release a=testing
Pin-Priority: 650

Package: *
Pin: release a=unstable
Pin-Priority: 600

Ihr seht, dass die Pakete aus Stable die höchste Priorität haben, aber wir haben nun die Möglichkeit, ausnahmsweise auch Pakete aus Testing oder Unstable zu installieren. Genau dies machen wir jetzt für OpenSMTPd: sudo apt-get -t testing install opensmtpd

UPDATE: Wie mir Martin freundlicherweise per Mail mitgeteilt hat, benötigt OpenSMTPd eine ordentlich ausgefüllte /etc/hosts, in der nicht nur ein Eintrag für localhost drin stehen sollte, sondern auch ein passender FQDN. Ansonsten klappt das Installieren via apt-get nicht.

Nachdem apt-get durchgelaufen ist, geht’s ans Konfigurieren desselben. Die meiste Konfiguration erfolgt in /etc/smtpd.conf. Beachtet: Hier werden diverse Regeln hineingeschrieben, wann und wie OpenSMTPd Mails akzeptieren soll, und wie er mit den Mails verfahren soll. Wie bei solchen Regelwerken üblich greift die von oben gesehen erste Regel, die auf ein bestimmtes Kriterium matcht.

Bevor wir jetzt aber mit der Konfiguration beginnen können, sollten wir uns um die relevanten Dateien kümmern, damit OpenSMTPd ordentliches TLS handlen kann, sprich, damit seine Verbindungen verschlüsselt sind. Achtung: Hiermit verschlüsselt ihr nicht eure Mails an sich (das ist die Aufgabe von PGP/GPG oder S/MIME), sondern lediglich die protokollarische Kommunikation mit dem Mailserver, also Passwörter und sowas.

Hierfür benötigt ihr einen private key, sowie ein Zertifikat. Ihr könnt sie mit diesen Befehlen generieren:

openssl genrsa -out /etc/ssl/private/mail.key 4096
openssl req -new -x509 -key /etc/ssl/private/mail.key -out /etc/ssl/certs/mail.crt -days 730
chmod 700 /etc/ssl/private/mail.key
chmod 700 /etc/ssl/certs/mail.crt

Nun kommen wir zur eigentlichen Konfiguration. OpenSMTPd basiert, was Benutzerauthentifizierung angeht, auf den Benutzerkonten eures Systems (so wie fast jeder andere MTA auch), und verarbeitet Mail-Aliase aus der seit sendmail bekannten Datei /etc/aliases. Da die /etc/aliases aber so nette Features wie Catchall-Adressen nicht unterstützt, und immer mit dem newaliases Befehl neu eingelesen werden muss, hat OpenSMTPd da auch eine gepimpte Lösung am Start, so genannte Virtual Aliases. Diese werden einfach in eine Plaintext Datei geschrieben, und der MTA liest sie dann aus. Meine Aliase stehen z.B. in /etc/mail/valiases und sehen so aus:

mailer-daemon   postmaster
postmaster      root
nobody          root
hostmaster      root
usenet          root
news            root
webmaster       root
www             root
ftp             root
abuse           root
noc             root
security        root
root            simonszu
simonszu        XXXXXXX@gmail.com
@               simonszu

Beachtet das @ in der letzten Zeile. Es ist eine Catchall-Direktive, die auf einen beliebigen Wert vor oder nach dem @ matcht. Nach dem @ deswegen, weil ein OpenSMTPd natürlich auch auf Virtual Domains konfiguriert werden kann, sodass ihr ihn als MX für mehrere Domains einrichten könnt. Hierzu habe ich beispielsweise die /etc/mail/vdomains verwendet:

simonszu.de
*.simonszu.de

Mehr zu diesen sogenannten Tabellen steht übrigens hier.

Nun zur Hauptkonfiguration in /etc/smtpd.conf: Zunächst sollen der Key und das Zertifikat für TLS geladen werden.

pki simonszu.de key "/etc/ssl/private/mail.key"
pki simonszu.de certificate "/etc/ssl/certs/mail.crt"

Sollte selbsterklärend sein. Die beiden Dateien werden geladen, und in der Variable simonszu.de für die weitere Benutzung gespeichert. Wie man sie dann einsetzt, ist im nächsten Absatz ersichtlich:

listen on localhost
listen on eth0 port 25 hostname simonszu.de tls pki simonszu.de
listen on eth0 port 587 hostname simonszu.de tls-require pki simonszu.de auth mask-source

Hier wird definiert, auf welchen Interfaces und Ports der MTA lauscht, und vor allem, mit welchen Mechanismen er neue Sessions annimmt. Er lauscht ohne Einschränkungen auf Localhost für Mails, die lokal generiert werden. Auf Port 25 ist er bereit, Mails anzunehmen, die von anderen SMTP-Servern zugestellt werden. Er bietet hierbei TLS mit dem vorhin geladenen Key-Zertifikat-Paar an. Auf Port 587 ist er bereit, Mails anzunehmen, die wir geschrieben haben, und die unser Mailclient nun bei ihm zur weiteren Auslieferung abliefert. TLS ist hierbei eine notwendige Voraussetzung, ebenfalls mit dem vorher generierten Set. Auch ist hier eine Authentifizierung notwendig, hierbei benötigt ihr den Usernamen und das Passwort eures Systemaccounts. mask-source sorgt dafür, dass der MTA die User-Hostname-Konfiguration eures lokalen Rechners entfernt, und stattdessen seine eigene in den Mailheader schreibt. Sprich: Anstatt simon@desktop steht dann simon@simonszu.de im Mailheader.

table valiases file:/etc/mail/valiases
table vdomains file:/etc/mail/vdomains

Hiermit werden die beiden Dateien, die ich oben erwähnt habe, eingelesen, und in den Variablen valiases und vdomains gespeichert.

Nun kommen wir zum Regelwerk, was bestimmt, was mit den Mails passieren soll, die der Server abarbeitet.

accept from any for domain <vdomains> virtual <valiases> deliver to mbox

Diese Regel ist für alle Mails, die über den Port 25 von anderen Mailservern eingereicht werden. Es darf jeder Mailserver Mails einreichen (from any), theoretisch könnte man hier bestimmte IPs oder Hostnamen black- oder whitelisten. Eine Einschränkung erfährt der Server aber über die for domain Direktive. Nur Mails an Domains, die in vdomains stehen, werden akzeptiert. Dies ist dann auch eure Absicherung, dass der Server nicht als Spam-Relay missbraucht wird. Sämtliche Mails, die nicht an die angegebenen Domains gehen, werden abgewiesen, und nur die Mails “eurer” Domains werden bearbeitet. Über die virtual Direktive wird spezifiziert, wohin die Mails intern geroutet werden. Sollte man hier keine Virtual Aliases nutzen, sondern die /etc/aliases, so heißt die Direktive übrigens aliases und nicht virtual. Der letzte Teil besagt dann lediglich, dass die Mails im mbox-Format auf dem Server gespeichert werden, und ihr euren IMAP- oder POP3(als ob)-Server darauf konfigurieren könnt. Da ich aber über die Catchall-Adresse und Weiterleitung auf Gmail die Mails gar nicht lokal speichere, entfällt dieser Schritt bei mir, die Syntax erwartet die Angabe dennoch.

accept for local virtual <valiases> deliver to mbox

Dies ist die Regel für Mails, die lokal entstehen, und zugestellt werden müssen. Auch hier werden die Aliase abgearbeitet, und letztendlich Mails, die nicht weitergeleitet werden, in der mbox gespeichert.

accept for any relay

Diese Regel matcht durch das relay-Statement auf die Mails, die von eurem Mailclient auf Port 587 zur Weiterleitung eingereicht werden. Sie werden einfach an den Zielserver weitergeleitet, der bestimmt wird, indem OpenSMTPd den MX-Record der Zieldomain abruft. Hier erfolgt die Absicherung gegen den Missbrauch als SPAM-Relay durch die Authentifizierung. Solltet ihr euren Mailserver als Satelliteserver einrichten, so ist hier der passende Ort, um den “echten” MX zu konfigurieren, der die Mails ins Internet raustragen soll. Dank dieser minimalen Config kann OpenSMTPd auch ohne Probleme Tools wie SSMTP ablösen.

Hierbei ist vielleicht interessant, dass OpenSMTPd ausschließlich den Relay von lokalen Usern erlaubt. Da euer Mailclient ja nicht lokal ist, gibt’s die auth-Direktive auf dem oben genannten Listen-Statement. Damit authentifizierte Clients werden behandelt als wären sie lokal. Dies beudeutet, dass auch Regeln, die auf lokale Mails beschränkt sind, auf diese Mails matchen. Dies hat unter anderem den Effekt, dass, sollte die auth-Direktive auf Port 587 weggelassen werden, der Server zwar auf dem Port auf ankommende Verbindungen lauscht, aber sämtliche Mails, die versucht werden, einzureichen, ablehnt. Um dieses Verhalten abzulehnen, und den Server wirklich promiskuitiv offen zu konfigurieren, kann mit auth-optional die Authentifizierung abgeschaltet werden. Ob das empfehlenswert ist?

Zur weiteren Info könntet ihr dann die manpages konsultieren, die komplett online abrufbar sind.

Generell kann ich euch den OpenSMTPd aber nur nahelegen. Er ist extrem einfach und idiotensicher zu konfigurieren, kann aber durch die verschiedenen Regeln genau so machtvoll eingerichtet werden wie z.B. der Postfix. So lässt sich z.B. ein Spamassassin oder ein komplettes Amavis-Framework in das interne Routing zwischenschalten. Es gefiel mir auch von Anfang an sehr, dass der Server inhärent sicher ist, und man ein unsicheres Verhalten explizit einkonfigurieren muss, während man z.B. beim Postfix erst umständlich mit saslauthd herumspielen muss. Ein Nachteil ist allerdings, dass die Software noch relativ jung ist, und es noch gar nicht so viele Tutorials oder Beispielconfigs im Netz gibt. So wird in den Manpages z.B. erwähnt, dass man die Tables auch aus einer Datenbank einlesen kann, und wie man sich auf diese Datenbank verbindet. Allerdings ist es dann wieder sehr schwer, Infos über die Struktur der Tabellen in der Datenbank zusammenzusuchen. Intuitiv lässt sich da die Struktur bestimmt aus der Manpage ableiten, aber eine explizite Angabe hat noch keinem geschadet.

Wie auch immer. Ich bin ziemlich froh, endlich einen MTA gefunden zu haben, der mit einer sehr einfachen, minimalen Config sehr schnell konfiguriert werden kann. Wie einfach diese Config ist? Nun, vor 24 Stunden wusste ich noch so gut wie gar nichts über den OpenSMTPd, und jetzt schreibe ich Blogposts über ihn. Noch Fragen? ;)