Ein redundanter Mailserver ohne klassische HA-Software

Grundgedanken

Möchte man sicherstellen, dass der eigene Mailserver (Postfix, Dovecot, Rspamd) hochverfügbar ist, dann wird meistens der Weg Hochverfügbarkeitssysteme wie Pacemaker oder Corosync gewählt. Damit verbunden sind komplexe Cluster-Setups und spezielle Cluster-Mechanismen (STONITH, DRBD), aber auch die Intensität der Clusterwartung steigt an. Das rentiert erst im großen Stil, für kleine Unternehmen, Organisationen oder Einzelpersonen wäre das überdiemsioniert.

Die Herausforderung eines hochverfügbaren Mailservers besteht aber auch bei eben bei diesen Zielgruppen. Der Weg dorthin ist ein DNS-basiertes Failover des Mailservers.

Unser Mailserver besteht aus Postfix für den MTA und als MDA dient uns Dovecot. Zusätzlich schützen wir uns vor Spammails mittels Rspamd. Des Weiteren brauchen wir für sowohl zur Administration der Mailaccounts mit PostfixAdmin als auch für den webbasierten Zugang zu den Mailaccounts (zum Beispiel mit Roundcube) sowohl einen Webserver (Apache2) und einen Datenbank-Server (MariaDB). Für den verschlüsselten Mailversand und Zugriff auf die Weboberflächen verwenden wir das freie LetsEncrypt zur Erstellung der SSL/TLS-Zertifikate für den Server.
Ausfallsicherheit und Redudanz des Mailservers bedeutet, dass ein zweiter Mailserver, der bis auf die IP-Adresse und den Hostnamen identisch ist. Das bedeutet, dass auf beiden Mailservern stets die gleiche Postfix-Konfiguration - bis auf Hostname und IP-Adresse - existieren. Das Gleiche gilt für die Konfiguration des Dovecot-Services, selbst die MariaDB-Datenbank muss auf Beiden identisch sein. Bis hin zu den Rspamd-Regeln, die ebenfalls identisch sein müssen.
Zu erwähnen ist auch, dass aus Gründen der Redundanz, die beiden Mail-Server - bei uns VMs auf je einem KVM-Host - auf unterschiedlicher Server-Hardware liegen.

Redundanz der SSL/TSL-Zertifikate

Eine weitere Herausforderung sind die Zertifikate von Let'sEncrypt, die ja komplett identisch auf beiden Servern sein müssen. Angenommen unser Mailserver lauscht auf smtp.example.com, imap.example.cpm, pop3.example.com, mail.example.com, sowie auf smtp.example2.com, imap.example2.cpm, pop3.example2.com, mail.example2.com und mx1.example.com und der Failover-Mailserver lauscht zunächst nur auf mx2.example.com. Wenn mx1.example.com ausfällt, muss aber mx2.example.com alle so eben gelisteten Domains und Subdomians sofort übernehmen können. Mit dem herkömlichen HTTP-Challenge von Let'sEncrypt, das den Webspace auf einem ipbasierten Host testet funktioniert das nicht, aber eben mit der DNS-Challenge wird genau das erfüllt. Wichtig ist es hierbei auch, dass die TTL (Time To Live) auf 60 Sekunden eingestellt wird.
Warum das? Bedeuten doch "TTL=60" eine höhere DNS-Last, da die Clients, Resolver der ISPs nur 60 Sekunden lang den DNS-Eintrag im Cache halten werden. Eine TTL von 60 Sekunden bedeutet zwar mehr Flexibilität, aber eben auf Kosten von Performance, Stabilität und Serverlast. Unser Ziel ist in diesem Fall aber ein redudantes Mailserver-System. Viel kritischer ist der Ausfall des Mailservers ohne jeglichen Ersatz. Da tut das nicht so weh.
Nebenbei erwähnt sei auch, dass so einfache Ideen wie zwei Mailserver-Adressen für den Mailversand und Mailempfang in den Mailclients als Mailaccount-Benutzer einzutragen und einfach beides zu nutzen. Das ist leider - obwohl die einfachste Lösung - viel zu kompliziert für den Großteil der Benutzer. Deswegen verfolgen wir diese geniale Lösung einer Redudanz des Mailservers.

Redundanz des Mailservers

Das hier zum Einsatz kommende System des Mailservers läuft auf einem aktuellem Debian Linux und beinhaltet diese Serverkomponenten respektive Software.

Server, Software	Zweck und Beschreibung
Postfix	MTA zum Mailversand und Mailempfang mittels SMTPs
Dovecot	MDA zur Speicherung und Bereitstellung der Mails mittels IMAPs
MariaDB	MySQL-Server zur Verwaltung der Maildomains des Mail-Systems und Mailaccounts sowie der Webmailer-DB
Rspamd	Mailfiltersystem zum Blockieren von SPAM
Apache2	Webserver für die Adminstrations-GUI, dem Webmailer
Let's Encrypt	Freies Zertifizierungstool für SSL-/TSL-Zertifikate
PostfixAdmin	Administrations-GUI zur benutzerfreundlichen Administration der Mailaccounts
Roundcube	Webmailer für die Mailaccounts

Wie zu sehen ist, haben wir hier jede Menge an Server- und Softwarekomponenten, die absolut identisch auf beiden Mailservern (Hauptserver und Failover-Server) sein müssen. Egal von welchem der Beiden eine Mail versendet wird oder eingeht, sie muss innerhalb kürzester Zeit (wenige Minuten) auf dem jeweils anderen Dovecot-Server (MDA) zur Verfügung stehen. Die Mails sind sowohl über Mailclients (Regelfall) als auch über beide Webmailer auf mx1 und mx2 erreichbar.
Während sich an der Konfiguration der beiden Postfix-Server so gut wie gar nichts ändert (beide sind identisch bis auf den Hostnamen), sieht das bei Dovecot, den Mysql-Datenbanken, den Rspamd-Rules und dem Let's Encrypt-Zertifikat anders aus. Letzteres wird einmal pro Woche auf einen Renew gegen die Zertifizierungsstelle geprüft und wird bei erfolgreichen Renew in Richtung des Failover-Mailservers mx2 synchronisiert.

Synchronen Zustand auf beiden Mailserver gewährleisten

Die Herausforderung wird es also sein, zu gewährleisten, dass sich die beteiligten Datenbanken und die ganzen Mails regelmässig und sicher synchronisieren, so dass bei Mail-Server synchron sind für die Benutzer.
Hier bieten sowohl der Dovecot-Server als auch der MariaDB-Server geniale Funktionalitäten an, die genau das umsetzen können, nämlich die Replikation der Mailaccounts respektive der Datenbanken in eindeutig definierten Zeitintervallen.
Wir sollten auch beachten, dass wir eventuell über keine Direktverbindung zwischen den beiden Root-Servern verfügen (CrossOver-Kabel), sondern vielleicht der zweite KVM-Server mit den beteiligten redudanten VMs in einem anderen Netzwerk liegt. Dann sollte auf jeden Fall zwischen den beteiligten Servern jeweils ein VPN (Virtual Private Network) aufgesetzt werden, über das die Daten in beide Richtungen synchronisiert werden können.
Wichtig neben dem identischen Let's Encrypt-Zertifikat, dass der Haupt-Mailserver regelmässig aktualisiert, sind auch die Rspamd-Rules. Diese können sowohl auf dem Haupt- wie auch auf dem Failover-Server gepflegt werden. Hier denkt man sofort Synchronisation-Tools wie Rsync, aber wesentlich praktischer erweist sich in diesem Szenario das Programm Unison. Denn Rsync ist primär für unidirektionale Synchronisation konzeptioniert, eine bidirektionale Synchronisation mit Rsync ist möglich, aber nicht trivial:

• Man müsste zwei Rsync-Läufe in beide Richtungen durchführen.
• Es gibt kein Konfliktmanagement: 
  Bei gleichzeitiger Änderung derselben Datei gewinnt die zuletzt synchronisierte Version, somit wäre ein Datenverlust vorprogrammiert.

Dagegen wurde Unison wurde von Grund auf für bidirektionale Synchronisation konzipiert. 

• Es erkennt Dateiänderungen auf beiden Seiten.
• Es vergleicht die Dateien beider Seiten, erkennt Konflikte, wenn beispielsweise dieselbe Datei auf beiden Seiten verändert wurde.
• Es speichert einen Zustands-Snapshot (Archiv), um Veränderungen zwischen den Synchronisationsläufen zu erkennen.

Deshalb kommt Unison für beide Fälle Synchronisation der Rspamd-Rules und der SSL-/TSL-Zertifikate zum Einsatz, gesteuert durch jeweilige Cronjobs.

Somit haben wir jederzeit zwei nahezu identische Mail-Server-Systeme - mal abgesehen von den IP-Adressen und Hostnamen.

Warum ein dynamischer DNS-Failover (CNAME-gesteuert) dem SMTP-Proxy überlegen ist

In dieser Architektur wird auf herkömmliche MX-Prioritäten verzichtet. Stattdessen sorgt das Failover-Programm “DNS_Failover” dafür, dass relevante DNS-CNAME-Einträge bei Ausfall eines Mailservers dynamisch aktualisiert werden, sodass der Mailverkehr nahtlos auf den verfügbaren Server umgeleitet wird. Das ist ein idealer Ansatz für kleine Infrastrukturen, bei denen die Ausfallsicherheit genauso überlebenswichtig ist wie bei den Großen.

1. Automatisches Failover über DNS – in Echtzeit

Durch das Failover-Programm “DNS_Failover”, das direkt auf dem autoritativen DNS-Server installiert ist, werden die CNAME-Einträge für den Mail-Empfang und  -Versand automatisch aktualisiert, sobald ein Mailserver oder KVM-Host nicht mehr erreichbar ist.

Damit wird eine nahezu sofortige Umschaltung auf den funktionierenden Server erreicht – ohne Wartezeiten durch MX-Retries oder DNS-Caching-Probleme wie bei klassischen Setups.

2. Zusätzliche Middleware oder Reverse-Proxy entfallen komplett

Ein SMTP-Proxy, wie der HAProxy, bringt zwangsläufig zusätzliche Abhängigkeiten, Konfigurationsaufwand, potenzielle Fehlerquellen und gegebenfalls einen eigenen Failover-Mechanismus mit sich.
Der DNS-basierte Ansatz dagegen verzichtet vollständig auf einen zentralen SMTP-Eingangspunkt, wodurch sich das System einfacher, schlanker und wartungsärmer gestaltet – ganz im Sinne kleiner IT-Teams.

3. Dezentrale Redundanz – ohne Single Point of Failure

Während ein Proxy immer einen potenziellen Single Point of Failure darstellt - es sei denn, man baut ihn auch wieder redundant mit Keepalived oder Loadbalancer auf - basiert dieser Ansatz auf DNS-gestützter Umleitung, die direkt auf Infrastruktur-Ebene reagiert.

Es gibt keinen zentralen Engpass, sondern die Steuerung erfolgt durch die DNS-Logik selbst.

4. Kosteneffizient und ressourcenschonend

Insbesondere in kleinen Unternehmen ist die Minimierung von Infrastruktur entscheidend. Der hier verfolgte Ansatz erfordert keine zusätzliche Hardware oder VMs, sondern nutzt den ohnehin vorhandenen DNS-Server als Steuerzentrale.

Somit ist diese Lösung vollständig softwarebasiert und ressourcenschonend, ideal für schlanke IT-Setups.

5. Schnell, sicher, individuell anpassbar – dank Open-Source

Die dynamische Umschaltung der DNS-CNAME-Einträge erfolgt über das eigens entwickelte Open-Source-Tool „DNS_Failover“, das als transparentes und leichtgewichtiges Failover-Management für Mailserver dient.

Da es sich um freie und offen einsehbare Software handelt, lässt sich DNS_Failover problemlos:

• an die spezifischen Anforderungen kleiner Unternehmen anpassen,
• mit bestehenden Systemen integrieren (z. B. Monitoring, Alerting),
• und bei Bedarf erweitern oder automatisieren – ohne Lizenzbindung oder Abhängigkeit von Drittanbietern.

Die Lösung bleibt vollständig unter eigener Kontrolle, ist auditierbar und kann flexibel an technische und organisatorische Gegebenheiten angepasst werden – ein entscheidender Vorteil gegenüber kommerziellen „Black-Box“-Failover-Systemen.