Heute las ich einen Artikel über das Aufsetzen eines eigenen Mailservers und ob dies eine gute Idee wäre? – Letztendlich riet der Autor mehr oder weniger vom Betrieb eines eigenen Mailservers mehr oder weniger ab.

Es ist dabei erst einmal gar nicht so schwierig einen eigenen Mailserver aufzusetzen und Emails zu versenden und zu empfangen.

Für welche Mailserver-Software man sich da entscheidet, bleibt eigentlich nur dem persönlichen Geschmack überlassen, denn vom Funktionsumfang her ist die gängige Serversoftware ähnlich ausgestattet.

Ich habe mich für sendmail in Kombination mit procmail entschieden, da ich bereits mehrere Jahre Erfahrung im Betrieb und der Konfiguration eines Email-Servers habe. Gerade sendmail scheint für den Anfänger nicht einfach zu konfigurieren zu sein und es geht immer noch folgender Mythos herum:

Man ist erst ein echter UNIX-Admin, wenn man eine sendmail.cf editiert hat!

Dabei ist die Notwendigkeit eine sendmail.cf-Konfigurationsdatei zu editieren sogar recht klein! Sendmail bringt leistungsfähige Makros mit, welche mit Hilfe des m4-Makropräprozessors eine angepasste sendmail.cf-Konfigurationsdatei erzeugen. Wie das genau funktioniert, kann man in der sendmail Dokumentation nachlesen oder sich Bücher wie zum Beispiel „sendmail“ vom O’Reilly-Verlag zulegen. Auch verraten einige klassische Linux-/UNIX-Administratorenhandbücher grundlegende Informationen zum Aufsetzen von sendmail.

Damit haben wir erst einmal eine grundsätzliche Konfiguration, welcher in einer perfekten Welt auch perfekt funktionieren würde. – Es ist aber nun leider so, dass die Welt eben nicht perfekt ist und wir uns mit ihren kleinen Unschönheiten herumschlagen müssen:

  • Spam
  • Domain Abuse
  • Mailserver, die als Open Relays konfiguriert sind

Gegen Spam gibt es bereits seit einigen Jahren etablierte Lösungen. Ein Projekt läuft bereits seit Jahren unauffällig und glänzt durch erneuerbare Filterregeln: Spamassassin ist das Mittel der Wahl, wenn es darum geht eingehenden Spam zu bekämpfen, der nicht bereits schon von den DNS-Blacklist-Filtern unseres MTA ausgefiltert worden ist. Ich bevorzuge dabei die Per-User-Konfiguration, weil dann für jeden User individuell die Bayes-Filter trainiert werden können und sich vor allen Dingen alle User ihre eigenen Procmail-Rezepte erstellen können, um den Spam passend zu selektieren und zu filtern.

Damit wir den Missbrauch unserer Domain in den Griff bekommen, müssen wir neben der grundsätzlichen Konfiguration noch viele kleine Dinge einrichten und zusätzliche Softwarepakete einsetzen, damit wir uns vor diesen Unannehmlichkeiten schützen und wir auch den Rest der Welt vor dem Missbrauch unserer Systeme und/oder Domains schützen:

  • STARTTLS und entsprechende Zertifikate
  • SPF (Sender policy framework)
  • DKIM (Domain keys identified mail)
  • DMARC

Wir sollten unseren Mailserver auf jeden Fall STARTTLS-fähig machen. Das heißt, dass jeder andere Mailserver (oder User) eine verschlüsselte Sitzung innerhalb des SMTP-Dialogs aufbauen kann. Damit das vernünftig funktioniert, brauchen wir ein paar Zertifikate, die unseren Server mit seinem FQDN (full qualified domain name) ausweisen. Let’s encrypt ist eine Zertifizierungsstelle, die uns die benötigten Zertifikate kostenfrei ausstellt. Ist alles korrekt konfiguriert, wird unser Mailserver ab sofort mit allen anderen Mailservern versuchen verschlüsselt zu kommunizieren. Man kann natürlich auch Millionen in Fernsehwerbung stecken und es Email made in Germany nennen! 😉

SPF legt über einen DNS-Eintrag in der Zonendatei unserer Domain fest, welcher Host unserer Domain überhaupt Emails versenden darf. Dort sind im Falle von ladegast.net folgende Werte hinterlegt:

@       IN A 94.130.75.205
halley  IN A 94.130.75.205
mail    IN A 94.130.75.205
@       IN AAAA 2a01:4f8:c0c:2dfa::2
halley  IN AAAA 2a01:4f8:c0c:2dfa::2
mail    IN AAAA 2a01:4f8:c0c:2dfa::2
@       IN MX 10 mail
@       IN TXT "v=spf1 a mx -all"

Dabei ist es grundsätzlich wichtig, dass für den MX-Eintrag keine direkte IP festgelegt wird, sondern ein Name. Dieser Name darf aber kein CNAME auf einen anderen Namen sein, sondern muss zwingend als A-Eintrag hinterlegt sein. Der TXT-Eintrag macht unsere Domain SPF-fähig, nämlich dass wir SPF in der Version 1 verwenden (v=spf1), dass ein Absender mit unserem Domainnamen einen validen A-Eintrag oder MX-Eintrag unserer Domain haben muss (a mx) und dass alle anderen Absender-Hosts nicht erlaubt sind (-all). Damit legen wir den Grundstein, dass ein anderer Mailserver überprüfen kann, ob ein Host, welcher Emails in unseren Domainnamen einsenden will, auch wirklich von dem Domaininhaber autorisiert ist.

DKIM funktioniert im wesentlichen mit einer serverseitigen Signatur aller ausgehenden Emails. Der öffentliche Schlüssel zum Überprüfen dieser Signatur, ist ebenfalls in der Zonendatei unseres DNS-Servers hinterlegt:

default._domainkey       IN TXT     "v=DKIM1; h=sha256; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0V67I2HwYTlEsHktxFcS8Up4BO441qeXO6s3J5SzOXaRHRHVp5c41t28aVqfyrbJremHLVlz2BdhMs9jlVzkiS/pSZVJ8o91MAP8U1t50HExML8CRxcMCqnPZvn6VF3+1BRHbEMPFpoNJ/pcvquSbbmT/pqPVYAc2Ef6mcF5w60iEwxugXkMNv/BGsEdfqL/T3orzWi+v9ib4bsKGriMG2PmxDgiFWjPBTlwZ8oV2TpwgDpqcuIxOoFVkrcOakhgmJDeEferUXArDypO62rQayvs5phLOl8cZA2PMd41bCNDbB34kJR1iko/LsMBKj9FWCMrKMQ6LGwBcKqMdQsMjwIDAQAB"

Mit Hilfe dieses öffentlichen Schlüssels kann jeder Mailserver, der Emails von uns empfängt, die Authentizität dieser Emails feststellen, indem er die kryptografische Signatur der Email mit Hilfe dieses Public-Keys überprüft. Ein Softwarepaket, welches DKIM für verschiedene Mailserver umsetzt und alle ausgehenden Mails signiert, ist OpenDKIM.

Bleibt nun noch DMARC. – DMARC ist die Festlegung einer Policy (Richtlinie), wie mit Emails von unserer Domain umgegangen wird, wenn diese nicht gewissen Kriterien entsprechen. Man kann einen einfachen „Beobachtungsmodus“ aktivieren, bei welchem andere Mailserver regelmäßig Reports zu den empfangen Emails zusenden oder auch eine entsprechende Policy festlegen, dass andere Mailserver Emails auch verwerfen können (reject).

Damit DMARC überhaupt funktioniert, müssen bereits SPF und DKIM für die Domain erfolgreich eingerichtet werden sein! Ansonsten finden sich im Internet eine ganze Reihe guter Artikel zum Thema DMAC-Einrichtung.

Fazit

Ist es nun eine gute Idee einen Mailserver zu betrieben? – Ich finde: Ja!

Es zwingt auf jeden Fall dazu sich mit den Techniken für einen sicheren Emailversand und -Empfang auseinander zu setzen und das eigene Wissen zu erweitern. Beim Aufsetzen eines eigenen Mailservers werden einem selbst die Probleme beim Emailversand und -Empfang bewusst und man muss die Risiken abschätzen und ggf. Maßnahmen ergreifen.

Die oben genannten Maßnahmen sehe ich derzeit als absoluten Mindeststandard an, wenn es darum geht das Problem von Spam und Reverse-Spam (über Domain Abuse) einzudämmen. STARTTLS bietet zumindest grundsätzliche Sicherheit für die Übertragungswege einer Email, ersetzt aber nach wie vor nicht eine sichere Ende-zu-Ende-Verschlüsselung.