Änderungen mit Unterbrechungen

Zusammenfassung

Letzte Woche bin ich bei einer routinemäßigen Wartung der E-Mail-Infrastruktur meiner Firma unerwartet in Schwierigkeiten geraten. Wir verarbeiten jeden Tag Tausende von E-Mails und nutzen Dovecot, damit unsere Kunden auf ihre Nachrichten zugreifen können. Damit war schlagartig Schluss, als ich auf Version 2.4 aktualisiert habe, die Breaking Changes mitbringt... oh je!

Volltext

⚠️ TL;DR: Dovecot 2.3 → 2.4 auf Debian aktualisieren

• Dovecot 2.4 bringt Breaking Changes mit: Konfigurationsdateien von 2.3 sind nicht kompatibel. Die Software startet nicht, solange du sie nicht umschreibst.
• Neue Konfigurationssyntax und neues Variablensystem: Parameter wie `ssl_cert`, `mail_location` und `%d` haben Format und Bedeutung geändert.
• Kein automatischer Migrationspfad: Du musst die Konfiguration von Hand prüfen und umschreiben, vor allem bei SQL-Backends, Sieve oder eigener Authentifizierung.
• Empfehlung: Lies die offizielle Upgrade-Anleitung gründlich durch, bevor du aktualisierst, und teste deine Konfiguration isoliert.

Ein Spaziergang im Park

Wegen einiger Sicherheitsupdates und um ein paar Kompatibilitätsprobleme zu beheben, habe ich beschlossen, auf einem Debian-GNU/Linux-Server einige Pakete zu aktualisieren. Auf diesem Server laufen die E-Mail-Dienste meiner Firma. Diese Distribution von GNU/Linux ist für ihre Stabilität und Zuverlässigkeit bekannt. Es gab keinen Grund, mit Ärger zu rechnen, und ich startete das Upgrade in der Erwartung, in wenigen Minuten fertig zu sein. Nur "ein Spaziergang im Park", was kann da schon schiefgehen..?

'dovecot_config_version' ist Pflicht

Fast der ganze Server war wie erwartet sofort wieder online. Die Dienste waren so kurz unterbrochen, dass nicht einmal der Uptime Monitor Alarm einen Ausfall bemerkte. Nur Dovecot nicht. Diese Software ist für den IMAP- und POP3-Zugriff auf Postfächer zuständig. Sie sitzt wie ein fein abgestimmtes Zahnrad in einem größeren Gefüge, in dem andere Programme wie Postfix darauf angewiesen sind, dass sie läuft, um eingehende E-Mails anzunehmen. Dass Dovecot nicht startete, löste eine ganze Reihe von Problemen aus.

Als Serveradministrator prüfst du als Erstes die Server-Daemons ('systemctl status dovecot') und danach die Logs, zum Beispiel mit 'journalctl -u dovecot'. Das zeigte schnell, dass Dovecot nicht starten wollte, weil ein Konfigurationsparameter fehlte: 'dovecot_config_version'.

Einfach den Parameter in '/etc/dovecot/dovecot.conf' ergänzen, denkst du jetzt vielleicht? Tja... NEIN. Die Dovecot-Entwickler haben den Fehler aus gutem Grund eingebaut: Die neue Version 2.4 ist nicht mit den alten 2.3-Konfigurationsdateien kompatibel, also musst du viele Parameter umschreiben. Es geht nicht nur um die Namen der Konfigurationsvariablen, es gibt auch eine völlig neue Syntax für die Expansion von Einstellungsvariablen. Aus einem alten Variablenwert wie '%d' wird jetzt '%{user | domain}'. Die Liste der Änderungen ist lang, und einen automatischen Weg, die Konfiguration zu migrieren, gibt es nicht. Du kannst dir mein Gesicht vorstellen, als mir das Ausmaß meines Problems klar wurde.

Verzahnte Komplexität: Zahnräder in einer Maschine

Das Problem mit E-Mail-Diensten: Sie sind schwer. Nicht, weil eine einzelne Komponente schwierig wäre, sondern weil für einen vollständigen E-Mail-Stack viele verschiedene Teile nahtlos zusammenarbeiten müssen. Das sind einige der Teile, aus denen der Mail-Dienst meiner Firma besteht:

• Postfix: Der wichtigste SMTP Mail Transfer Agent (MTA). Er spricht mit anderen Mailservern, um E-Mails zu empfangen und zu senden. Er muss wissen, welche E-Mail-Adressen Mails empfangen dürfen und wer neue Nachrichten senden darf.
• Amavis-Filter: Alle Mails, die der Server verarbeitet, laufen durch den Amavis-Filter, der jede Nachricht mit SpamAssassin und ClamAV prüft.
• SpamAssassin: Mit einem komplexen Regelwerk und Bayes-Analysen wird jede Nachricht automatisch darauf untersucht, wie wahrscheinlich sie Spam ist.
• ClamAV: Nachrichten werden auf Viren gescannt. Anhänge werden extrahiert und Datei für Datei analysiert.
• Reverse-DNS-Blacklists: Neben den Nachrichten selbst prüft der Mailserver im Hintergrund auch die externen Server, mit denen er spricht. Die Mail-Header werden ausgewertet und jeder einzelne Hop wird auf seinen Ruf geprüft.
• OpenDKIM: Manche Nachrichten tragen eine 'Domain Key'-Signatur, die belegt, dass der Absender berechtigt ist. Nachrichten mit einer solchen Signatur werden geprüft, alle anderen werden über einen Milter-Dienst signiert, der in Postfix eingebunden ist.
• Sieve: Eingehende Nachrichten werden automatisch nach Regeln des jeweiligen Benutzers sortiert, zum Beispiel in bestimmte Ordner. Sieve muss wissen, welche Regeln für welche Adressen gelten.
• MariaDB / MySQL: E-Mail-Adressen, gültige Logins, Benutzernamen, Passwort-Hashes und Aliase liegen in einer zentralen Datenbank. Bestimmte SQL-Abfragen sind so konfiguriert, dass sie Dinge prüfen wie "Ist dieses Passwort gültig?"
• Nginx: Auf dem E-Mail-Server läuft auch ein Webserver, über den man Konten verwalten und per Webmail auf E-Mails zugreifen kann.
• NodeJS: Die Verwaltungskonsole nutzt ein NodeJS-Backend, mit dem Serveradministratoren und Kunden ihre Adressen und Passwörter einrichten.
• Roundcube: Der Server nutzt ein weit verbreitetes Webmail-Programm, damit Kunden im Browser auf ihre E-Mails zugreifen können.
• PHP: Das Webmail braucht PHP, samt einiger Abhängigkeiten, damit es mit Dovecot (per IMAP) und MariaDB (per SQL) sprechen kann.
• Dovecot: Und dann ist da noch Dovecot, die eigentliche Software, über die Endnutzer an ihre E-Mails kommen. Sie gibt angemeldeten Nutzern Zugriff auf die E-Mails, die auf den Festplatten der Infrastruktur liegen, über Protokolle wie IMAP oder POP3.

All diese Teile sind genau aufeinander abgestimmt und greifen wie die Zahnräder einer komplexen Maschine ineinander. Ihre Konfiguration ist auf ihre jeweilige Rolle zugeschnitten und hängt oft an mehreren anderen Teilen. Du kannst dir vorstellen, wie sehr eine unerwartete Änderung an einem dieser Zahnräder (wie Dovecot) alles durcheinanderbringen kann!

Eine schnelle Lösung gab es nicht, auch kein automatisches Upgrade der Konfiguration. Weil dieses Update noch relativ neu ist, hatten auch die meisten großen Sprachmodelle (KI) keine Antwort. ChatGPT erzeugte einfach Vorschläge auf Basis der alten 2.3-Dokumentation. Um das Problem zu lösen, brauchte ich 'Linux-Server-Handwerk der alten Schule': von Hand eine neue, maßgeschneiderte Konfiguration für Dovecot 2.4 schreiben.

Anhalten, um Datenverlust zu vermeiden

Als ich begriffen hatte, was los war, habe ich sofort die meisten E-Mail-Dienste gestoppt (den Motor also komplett abgestellt). Das verhindert Datenverlust, weil keine E-Mails mehr verarbeitet werden. Andere Mailserver stellen ihre E-Mails dann in die Warteschlange und geben manchmal 4xx-SMTP-Fehler aus (wie 421, 451, 454 oder 455). Das weltweite E-Mail-Protokoll ist auf vorübergehende Ausfälle ausgelegt, und andere Server versuchen es später einfach noch einmal.

Die Konfiguration umschreiben mit RTFM

Die Fehlermeldung in den Logs führte mich zu den offiziellen Dovecot-Dokumenten, und da war sie: eine gelblich hervorgehobene WARNUNG, die die Änderungen an der Konfiguration beschrieb. Das Dokument ist lang: als PDF sind es 18 Seiten. An einem normalen Tag kostet es schon Mühe, sich da durchzuarbeiten. Stell dir vor, du musst das tun, während das sprichwörtliche Haus brennt!

Die Konfiguration von Dovecot besteht aus verschiedenen Dateien, die jeweils einen Teil des Verhaltens der Software festlegen. Etwa wie die Authentifizierung läuft, wie Sieve eingebunden wird oder woher die Benutzernamen und Passwort-Hashes für den Login kommen. Die Änderungen in Dovecot 2.4 betreffen fast alle Parameter, denn die Entwickler haben eine neue Syntax für Servervariablen eingeführt.

Syntax der Variablen

Früher nutzte die Konfiguration Variablen wie '%u' als Platzhalter für einen Benutzernamen. Die neue Syntax erlaubt es, Variablen an einen Modifikator weiterzureichen, für Normalisierung oder etwa die Auswahl von Teilstrings. Ein Beispiel: Um die E-Mail-Domain aus einem Benutzernamen zu holen, nimmst du nicht mehr '%d', sondern die Variable 'user' als Basis und reichst sie mit dieser Syntax an den Modifikator domain weiter: '%{user | domain}'.

Als ich diese neue Sprache verstanden hatte, wusste ich das Kunstwerk dahinter wirklich zu schätzen. Es ist eine Verbesserung gegenüber den alten, abgekürzten Variablennamen, denn du brauchst kein Wörterbuch mehr zum Nachschlagen: Statt etwas Kryptischem wie '%r' liest du jetzt '%{remove_ip}'. Das ist von Haus aus lesbarer, und genau das schätze ich sehr.

Verschlüsselung: aus 'ssl_cert' wird 'ssl_server_cert_file'

Weitere Änderungen betreffen die Art, wie die Konfiguration auf externe Dateien für die Verschlüsselung verweist. Früher gab es die Einstellung 'ssl_cert', die das eigentliche SSL/TLS-Zertifikat als String enthalten konnte. In Version 2.4 gibt es stattdessen die Variable 'ssl_server_cert_file', die einen Pfad zum Zertifikat im Dateisystem erwartet. Das ist nicht nur eine Umbenennung, auch die Art des Werts ist neu! Um die Konfiguration zu reparieren, musst du jeden dieser geänderten Parameter durchgehen und prüfen, was er für dein Setup bedeutet. Das kostet Zeit und ist fehleranfällig.

Die Einstellung 'mail_location' wird aufgeteilt

Neu in 2.4 ist, dass 'mail_location' in mehrere kleinere Variablen aufgeteilt wird. Früher legte eine einzige Variable fest, wo E-Mails auf der Festplatte gespeichert werden. Jetzt musst du sie in die zwei Variablen 'mail_driver' und 'mail_path' aufteilen UND die neue Syntax für Servervariablen verwenden. Wenn du dabei etwas falsch machst, verschwinden alle E-Mails (glaub mir!). Je nach Speicherkonfiguration solltest du den Teil mit dem Benutzernamen noch einmal prüfen (zum Beispiel: nimmst du die komplette E-Mail-Adresse oder nur den Teil vor dem @, ohne Domainnamen?).

Dovecot mit SQL-Backend: passdb und userdb

Wenn deine Dovecot-Installation Benutzernamen und Passwörter über eine externe Datenbank (oder einen anderen Speicher) prüft, musst du die Datei 'auth-sql.conf.ext' in '/etc/dovecot/conf.d/' umschreiben, die von 10-auth.conf aufgerufen bzw. eingebunden wird. Dovecot 2.4 gliedert die Einstellungen für passdb und userdb auf neue Weise. Im Dovecot-2.3-Setup habe ich eine externe Datei für die Datenbankabfragen und den Verbindungsstring genutzt. Bei der Authentifizierung werden mehrere Abfragen verwendet, um 1) Benutzer zu authentifizieren und 2) benutzerspezifische Einstellungen wie den Pfad des E-Mail-Speichers zu laden.

In der neuen Version 2.4 musst du die Parameter so umbauen, dass sie in Abschnitten stehen, die direkt hinter den Schlüsselwörtern 'userdb' und 'passdb' einen Hinweis auf den Backend-Typ tragen. Wenn du also eine MySQL-Datenbank als Backend nutzt, wird aus 'userdb' jetzt 'userdb sql'. Die Parameter für den Verbindungsstring kannst du direkt in die Datei 'auth-sql.conf.ext' schreiben, sodass alle relevanten Parameter in einer Konfigurationsdatei stehen. Um die Komplexität zu verringern, habe ich den userdb-Abschnitt so umgeschrieben, dass er den Datenbanktreiber 'static' nutzt: Konfigurationsvariablen wie der Mail-Pfad des Benutzers werden aus dem Benutzernamen erzeugt. Siehe die passenden Dokumente.

Das Sieve-Plugin

Wenn dein Setup Sieve nutzt, um eingehende E-Mails zu sortieren, musst du Speicherort, Standardwerte und Verhalten der Skripte anpassen. Dovecot 2.4 führt das Konzept "Script Storage" ein, mit dem dynamisch geladene Skripte für verschiedene Benutzer bei unterschiedlichen Ereignissen ausgeführt werden können. In unserem Setup gibt es ein einfaches Standard-Sieve-Skript, das als Spam markierte E-Mails automatisch in einen Ordner namens Spam sortiert. Die neue Syntax macht die Konfiguration kompakter:

Die neue Konfiguration testen

Nach dem Umschreiben der 2.4-Konfiguration bist du vielleicht versucht, den Server einfach wieder zu starten. Sei dabei sehr vorsichtig: Eine falsche Konfiguration kann dazu führen, dass Kunden den Zugriff auf alle E-Mails verlieren und/oder ihre kompletten Postfächer neu herunterladen müssen. Ich habe mich deshalb für einen schrittweisen Ansatz entschieden und die IMAP- (und POP3-) Portnummern auf beliebige Werte geändert. So konnte ich das neue Setup ganz allein testen, ohne dass sich echte Kunden mit dem Server verbinden konnten. Dabei habe ich einige Tippfehler behoben, die neue Syntax der Servervariablen verfeinert und mich mit ein paar merkwürdigen Log-Meldungen herumgeschlagen. Die Portnummern des Servers steuerst du in der Datei '10-master.conf'.

Fazit

Solche Ausfälle sind dank der Stabilität von Debian GNU/Linux selten, aber nicht unmöglich. Für den E-Mail-Dienst Lemmid Online meiner Firma gibt es tägliche Backups und einen getesteten Notfallplan. Ein vollständiges Failover war diesmal nicht nötig, aber frühere Übungen waren entscheidend, um die Konfiguration schnell anzupassen.

Dieser Vorfall war eine Erinnerung daran, dass selbst mit Automatisierung und KI tiefes Systemwissen, gute Vorbereitung und Debugging von Hand unverzichtbar bleiben, wenn sich kritische Komponenten der Infrastruktur unerwartet und ohne automatische Migrationspfade ändern.

Dovecot 2.4 Beispielkonfiguration

Wenn du diesen Beitrag auf der Suche nach einer Lösung für deinen eigenen kaputten Mailserver gefunden hast, helfen dir vielleicht diese Beispielkonfigurationsdateien für Dovecot 2.4. Ich habe sie bei meiner eigenen Reparatur gefunden, und sie ersparen dir womöglich etwas Zeit beim Entschlüsseln der neuen Syntax: https://source.willem.com/dovecot-2.4-sample-config/