Dovecot Update: Neuerungen in CE 2.4 und Stand zu Dovecot 3

Dovecot 3: Versionsstand und Roadmap einordnen

Wer ein Dovecot-Update plant, sollte Versionsbezeichnungen nicht als Zusage für eine kommende Hauptversion lesen. Zum Recherchezeitpunkt 21. Oktober 2026 ist Dovecot CE 2.4.5 der veröffentlichte stabile Stand im offiziellen Core-Repository. Eine veröffentlichte Dovecot-CE-Version 3.0 oder eine offizielle CE-3.0-Roadmap ist dort hingegen nicht belegt.

Insbesondere eine Überschrift wie „v2.4.5 to v2.4.6“ in der Dokumentation beschreibt keinen veröffentlichten 2.4.6-Stand. Solche Inhalte können helfen, Änderungen im Entwicklungszweig früh zu erkennen. Sie erlauben aber keine Aussage darüber, wann, ob oder in welcher Form sie in ein stabiles Paket gelangen. Das gilt erst recht für Ableitungen zu Dovecot 3.

Für Entscheidungen im Hosting av e-post müssen außerdem Produktzweige getrennt bleiben. Dovecot CE bezeichnet die Community-Edition, während Dovecot Pro ein separates kommerzielles Angebot ist. Eine Funktion, ein Betriebsmodell oder eine Dokumentationsaussage lässt sich daher nicht automatisch zwischen beiden übertragen. Auch Inhalte aus main sind von veröffentlichten CE-Releases zu unterscheiden; maßgeblich für ein Upgrade sind die Version und Dokumentation, die tatsächlich eingesetzt werden sollen.

Was das Dovecot-2.4-Versionsmodell verändert

Dovecot 2.4 trennt drei Ebenen, die bei einem Update oft fälschlich gleichgesetzt werden: die installierte Programmversion, dovecot_config_version och dovecot_storage_version. Das installierte Paket bestimmt, welchen Code der IMAP-Server ausführen kann. Die beiden Einstellungen steuern dagegen bewusst, ab welchem Stand geänderte Standardwerte beziehungsweise neue Speicherformate verwendet werden.

Die Konfigurationsversion verhindert damit, dass ein Paketwechsel stillschweigend alle neuen Defaults aktiviert. Betreiber können Dovecot zunächst auf 2.4 aktualisieren und die Konfigurationssemantik anschließend gezielt anheben, nachdem sie Anmeldung, TLS, Plugins und die vorhandenen Einstellungen geprüft haben. Das reduziert Überraschungen durch veränderte Vorgabewerte, ersetzt aber nicht die erforderliche Migration einer 2.3-Konfiguration.

Die Speicherversion betrifft dagegen Datenformate, die Dovecot in seinen Indizes oder anderen Speicherbereichen anlegt. Ein höherer Wert kann Formate aktivieren, die ältere Dovecot-Versionen nicht verstehen. Deshalb sollte er erst gesetzt werden, wenn ein Rückschritt auf einen älteren Programmstand nicht mehr Teil des Wiederherstellungsplans ist. Ein Paket-Rollback allein stellt zuvor verwendete Indexformate nicht automatisch wieder her.

Für eine 2.3-zu-2.4-Migration müssen beide Einstellungen in der Hauptkonfiguration vorhanden sein; dovecot_config_version muss dabei die erste Einstellung in dovecot.conf sein. Setze die Konfigurationsversion erst nach der Anpassung und Prüfung der 2.4-Syntax auf den vorgesehenen Zielstand. Die Speicherversion bleibt zunächst auf dem bislang erforderlichen kompatiblen Stand und wird nicht automatisch auf den Paketstand angehoben.

Der ausdrückliche zweite Schritt ist die rollbackkritische Freigabe neuer Speicherformate. Erst wenn alle Instanzen den neuen Stand verwenden, der Rückfall auf ältere Dovecot-Versionen nicht mehr vorgesehen ist und ein beobachtetes Wartungsfenster bereitsteht, kann dovecot_storage_version auf den gewählten Zielstand erhöht werden, etwa auf 2.4.5 für das dort dokumentierte Thread-Indexformat. Ältere Versionen können diesen Index erneut in ihrem Format aufbauen; dabei entstehen jedoch zusätzliche Arbeit und ein Wechsel zwischen nicht gegenseitig verstandenen Indexformaten. Die Angabe ist deshalb keine kopierfertige Standardkonfiguration: Ausgangs- und Zielwert hängen von der betriebenen Version und dem Rückfallplan ab.

Dieses gestufte Vorgehen ähnelt dem Grundsatz, Programmstand und aktivierte Verhaltensänderungen getrennt zu bewerten. Auch bei anderen Serverkomponenten genügt eine hohe Versionsnummer nicht als Kompatibilitätsnachweis; der Beitrag zu Upgrade-Entscheidungen bei Redis 8 erläutert diese Unterscheidung für einen anderen Dienst. Bei Dovecot sind zusätzlich Mailbox-Formate, Indexdaten und die Rückfallstrategie relevant.

Neue Funktionen und ihr Reifegrad

Eine relevante Neuerung in Dovecot 2.4 ist fts-flatcurve als lokales Volltextsuch-Backend auf Xapian-Basis. Der Treiber speichert Suchdaten je Mailbox im Dovecot-Indexpfad und benötigt Xapian ab Version 1.4. Er unterstützt Relevanzbewertung und kann auch Substring-Suchen ermöglichen, bietet aber keine unscharfe Suche. Ohne Volltextindex muss Dovecot Nachrichtendaten für entsprechende Suchen sequenziell durchsuchen.

Substring-Suche ist bei Flatcurve nicht automatisch aktiv: Die dokumentierte Voreinstellung von fts_flatcurve_substring_search lautet no. Wird sie für passende IMAP-Suchanforderungen bewusst eingeschaltet, ist zusätzlicher Speicherplatz für den Index einzuplanen. Flatcurve bleibt damit eine Option für IMAP-Server mit regelmäßig genutzter Nachrichtensuche, aber kein voraussetzungsloses Pflicht-Upgrade. Indexwachstum, Überwachung und Reindexierung gehören zur Betriebsplanung.

Anders einzuordnen sind SMTPUTF8, IMAP UTF8=ACCEPT und IMAP4rev2. Die Release-Informationen kennzeichnen diese Möglichkeiten als experimentell. SMTPUTF8 und UTF8=ACCEPT setzen einen Build mit --enable-experimental-mail-utf8 und anschließend mail_utf8_extensions = yes in der Konfiguration voraus. IMAP4rev2 verwendet davon getrennte Schalter: Beim Build ist --enable-experimental-imap4rev2 erforderlich, danach muss imap4rev2_enabled = yes konfiguriert werden.

Experimentell bedeutet hier nicht, dass die Funktion generell ungeeignet wäre. Sie ist vielmehr kein pauschaler Standard für jedes Hosting-Angebot. Vor einer Aktivierung sollten Betreiber prüfen, ob eingesetzte Mailclients, die vollständige Zustellkette und verbundene Systeme die gewünschte UTF-8-Verarbeitung oder IMAP4rev2 tatsächlich benötigen und verarbeiten können. Tests gehören in eine Umgebung, die reale Authentifizierung, Mailbox-Namen und Clientprofile ausreichend abbildet.

Auch SCRAM-Mechanismen, TLS Channel Binding sowie erweiterte TLS-SNI- und ALPN-Verarbeitung verdienen eine getrennte Bewertung. Sie betreffen nicht nur den Dovecot-Prozess, sondern das Zusammenspiel mit Clients, Zertifikaten, Proxies und Authentifizierungsquellen. Der sinnvolle Maßstab ist ein klarer Bedarf mit überprüfbarer Kompatibilität, nicht die bloße Verfügbarkeit einer neuen Option in einem Dovecot-Release.

Upgrade auf 2.4 systematisch vorbereiten

Ein Upgrade von Dovecot 2.3 auf 2.4 beginnt mit einer Bestandsaufnahme, nicht mit dem Paketmanager. Erfasse den installierten Programmstand, die wirksame Konfiguration und das Mailbox-Format, etwa Maildir oder mdbox. Dokumentiere außerdem Authentifizierungsquellen, Sieve-Regeln, Quota, Volltextsuche, Replikation sowie vorgeschaltete Proxies. Nur so wird sichtbar, welche Dienste und Datenpfade von der Migration tatsächlich betroffen sind.

Für eine lesende Inventur eignen sich die folgenden Befehle. Sie ändern weder Konfiguration noch Maildaten; ihre Ausgabe gehört dennoch in einen geschützten Arbeitsbereich, weil sie Rückschlüsse auf die Serverumgebung zulassen kann.

dovecot --version
doveconf -n

dovecot --version zeigt den Programmstand. Mit doveconf -n prüfst du die von Standardwerten abweichende, wirksame Konfiguration. Die Option -v Från doveadm ist dagegen keine Versionsabfrage, sondern aktiviert ausführlichere Ausgabe einschließlich Fortschrittsanzeige und gehört nur zu einem passenden Unterbefehl. Behandle die Konfigurationsausgabe vertraulich: Sie kann Hostnamen, Verzeichnisstrukturen, Backend-Adressen oder andere Infrastrukturdetails enthalten. Für Fehleranalysen empfiehlt die Dovecot-Dokumentation eine minimierte Konfiguration statt eines ungekürzten öffentlichen Dumps.

Prüfe zusätzlich, ob der laufende Stand bereits der letzte verfügbare 2.3-Release ist. Der dokumentierte Migrationsweg führt zunächst auf diesen Stand und erst anschließend zu 2.4. Übertrage die Konfiguration nicht direkt auf ein Produktionssystem, sondern in ein Testsystem mit repräsentativen Konten, Berechtigungen und Mailboxgrößen. Wie bei einem Kernel-Update für Hosting-Server reicht auch hier die Versionsnummer allein nicht aus: Paketierung, aktivierte Module und Architektur bestimmen die praktische Wirkung.

Migration von 2.3 auf 2.4 planen

Die Migration nach 2.4 ist ein eigener Konfigurationsschritt. Dovecot 2.4 verlangt eine angepasste Syntax sowie dovecot_config_version och dovecot_storage_version; die Konfigurationsversion muss die erste Einstellung in dovecot.conf sein. Übernimm alte Dateien daher nicht unverändert. Vergleiche jede verwendete Einstellung mit der versionsgebundenen Migrationsdokumentation und validiere sie im Testsystem, bevor ein Wartungsfenster geplant wird.

Die Tabelle nennt keine Austauschrezepte. Der entfernte Director und der entfernte Replicator betreffen unterschiedliche Aufgaben: Lua Director ist laut Dokumentation nur eine nicht unterstützte Lösung für kleine Deployments, während für Replicator ein Shared Filesystem als Ansatz genannt wird. doveadm sync ist dagegen der Nachfolger des entfernten dsync-Symlinks und kann für bewusst geplante Synchronisations- oder Migrationsabläufe eingesetzt werden; daraus folgt kein dokumentierter Drop-in-Ersatz für Director oder Replicator.

Auch bei Quota und Suche entscheidet der vorhandene Datenbestand. Kompatibilitet bedeutet hier nicht nur, dass Dovecot startet: Quota-Warnungen, Sieve-Aktionen, IMAP-Suchen und Zugriffe mehrerer Clients müssen mit realistischen Testkonten funktionieren. Halte für jede entfernte Komponente fest, wo sie konfiguriert ist, welche Daten sie nutzt und wie ein Rückweg aussieht. Erst danach lässt sich die Paketumstellung sinnvoll terminieren.

Suche und Speicherformate gezielt abwägen

Programmstand, Konfigurationsstand und Speicherstand lassen sich in Dovecot 2.4 bewusst getrennt entwickeln. Erhöhe dovecot_storage_version erst, wenn ein Rückschritt auf eine ältere Dovecot-Version nicht mehr vorgesehen ist. Mit dem Storage-Level 2.4.5 verwendet der Thread-Index für den IMAP-Befehl THREAD ein neues v2-Format. Bestehende Thread-Indizes werden beim nächsten Threading neu aufgebaut; gerade bei großen Mailboxen kann die erste Abfrage dadurch zusätzlichen Aufwand verursachen.

Ein älterer Dovecot-Stand versteht dieses Thread-Indexformat nicht und erzeugt den Index wieder im alten Format. Der Storage-Level ist deshalb eine betriebliche Festlegung, keine bloße Versionsdekoration. Plane mögliche Index-Neuaufbauten in ein beobachtetes Zeitfenster ein und erhöhe ihn nicht gleichzeitig mit weiteren schwer rückgängig zu machenden Änderungen an Suche, Speicher oder Proxy-Topologie.

Für lokale Suchindizes ist fts-flatcurve eine Option, wenn die Umgebung Xapian 1.4 oder neuer bereitstellt. Der Treiber speichert Indexdaten pro Mailbox im Dovecot-Indexpfad und unterstützt Relevanzbewertung. Substring-Suchen lassen sich aktivieren, sind mit fts_flatcurve_substring_search = no jedoch standardmäßig ausgeschaltet und benötigen bei Aktivierung deutlich zusätzlichen Indexspeicher. Unscharfe Suche unterstützt Flatcurve nicht.

Bewerte daher die Sucharchitektur anhand von Mailboxgrößen, Speicherart und Betriebsmodell statt nach einer pauschalen Rangfolge. doveadm fts flatcurve stats liefert gespeicherte Statusdaten zu den Flatcurve-Indizes. Davon zu trennen ist doveadm fts flatcurve check: Dieser Befehl prüft Xapian-Datenbanken und versucht grundlegende Fehler zu beheben, kann den Zustand also verändern. Rotation und Entfernen von Indizes sind ebenfalls gezielte Wartungsmaßnahmen. Plane vor solchen Eingriffen Umfang, betroffene Mailboxen und den möglichen erneuten Indexaufbau.

Sieve, Proxies und Sicherheitsgrenzen prüfen

Sieve-Filter sind beim Dovecot-Update ein eigener Prüfpunkt, weil die Erweiterung nicht im Dovecot-Kern aufgeht: Sieve und ManageSieve stellt das separate Projekt Pigeonhole bereit. Bei selbst kompilierten Installationen muss Pigeonhole zusammen mit der neuen Dovecot-Version neu kompiliert werden. Andernfalls kann das Interpreter-Plugin wegen eines Versionskonflikts nicht laden.

Bei distributionsbasierten Installationen ist stattdessen entscheidend, dass Dovecot- und Pigeonhole-Pakete aus zueinander passenden Paketquellen stammen. Prüfe vor dem Wartungsfenster, welche aktiven Benutzerskripte, globalen Skripte und ManageSieve-Zugänge vorhanden sind. Nach dem Update sollten Zustellung, Umleitung, Vacation-Antworten und eine Änderung über ManageSieve mit einem dafür vorgesehenen Testkonto nachvollzogen werden; produktive Filter sind kein Ersatz für diesen Test.

In Proxy-Architekturen verdient die IMAP-Kompression besondere Aufmerksamkeit. Wenn die Konfigurationsversion auf 2.4.5 angehoben wird, lautet der Standard für imap_compress_on_proxy yes. Die Verarbeitung der Kompression verlagert sich damit auf den Proxy; die Einstellung gehört laut Dokumentation auf das Backend. Voraussetzung sind korrekt definierte login_trusted_networks sowie nachvollziehbare Vertrauensgrenzen zwischen Proxy und Backend.

Kläre deshalb vor einer Übernahme des neuen Defaults: Welche Verbindungen enden am Proxy, welche IP-Adressen darf das Backend als vertrauenswürdig behandeln, und auf welchem System sollen CPU-Last und Datenverkehr der Kompression entstehen? Eine Änderung ist nur dann sinnvoll beurteilbar, wenn diese Fragen zur tatsächlichen Netzarchitektur passen. Sie ersetzt weder eine TLS-Prüfung noch eine belastbare Zugangskontrolle zwischen den beteiligten Systemen.

Auch neue Authentifizierungs- und experimentelle Protokollfähigkeiten sollten nicht pauschal aktiviert werden. Die Release-Informationen nennen SCRAM-Mechanismen einschließlich TLS Channel Binding sowie SMTPUTF8, IMAP UTF8=ACCEPT und IMAP4rev2. SMTPUTF8 und UTF8=ACCEPT benötigen beim Build --enable-experimental-mail-utf8 und in der Konfiguration mail_utf8_extensions = yes. Davon getrennt setzt IMAP4rev2 den Build-Schalter --enable-experimental-imap4rev2 och imap4rev2_enabled = yes voraus. Prüfe Client-Unterstützung, Zustellkette und Rückfallverhalten für jede Funktion einzeln, bevor du sie im Hosting av e-post anbietest.

Nach dem Update sicher betreiben

Ein Update ist erst nach fachlichen Prüfungen abgeschlossen, nicht bereits nach einem erfolgreichen Paketlauf. Kontrolliere im Wartungsfenster zunächst, ob der Dienst startet und ob die Protokolle Konfigurations-, Plugin- oder Berechtigungsfehler zeigen. Danach folgen Anmeldung und Mailboxzugriff mit einem Testkonto. Prüfe dabei mindestens Ordnerliste, Nachrichtenauswahl, Lesen und eine kontrollierte Zustellung, damit der IMAP-Server nicht nur erreichbar, sondern nutzbar ist.

Validiere Sieve und Quota als getrennte Funktionen. Eine erfolgreiche IMAP-Anmeldung belegt weder, dass Pigeonhole geladen wurde, noch dass Quota-Grenzen korrekt ermittelt werden. Teste deshalb eine harmlose Filterregel und eine Zustellung nahe einer vorgesehenen Quotagrenze in einer isolierten Testmailbox. So lassen sich Fehler in Plugins, Berechtigungen und der Anbindung an das jeweilige Quota-Backend erkennen, ohne Kundenpostfächer absichtlich zu belasten.

Bei aktivierter Volltextsuche gehört die Beobachtung von Indexzustand und Suchanfragen in den Nachlauf. Für einen lesenden Überblick über vorhandene Flatcurve-Indexdaten dient doveadm fts flatcurve stats. Der Unterbefehl check ist davon klar zu trennen: Er prüft Xapian-Datenbanken und versucht grundlegende Fehler zu beheben, ist also keine garantiert rein lesende Diagnose. Setze ihn ebenso wie Rotation oder Entfernen von Indizes nur als geplante Wartungsmaßnahme für festgelegte Mailboxen ein und berücksichtige mögliche Zustandsänderungen sowie einen erneuten Indexaufbau.

Bei vorgeschalteten Proxies kontrollierst du zusätzlich den gesamten Verkehrsweg: Kommt die Anmeldung am erwarteten Backend an, werden Client-IP und Vertrauensnetz korrekt behandelt, und entstehen keine unerwarteten Kompressions- oder TLS-Probleme? Vergleiche dafür Protokolle der beteiligten Komponenten zeitlich miteinander. Einzelne erfolgreiche Logins reichen nicht aus, wenn mehrere Backends, unterschiedliche Clientnetze oder getrennte TLS-Terminierung beteiligt sind.

Für die Fehlersuche empfiehlt die Dovecot-Dokumentation eine minimierte Konfiguration. Reduziere dazu in einer abgesicherten Umgebung schrittweise auf die Komponenten, die den Fehler reproduzieren, statt die gesamte produktive Konfiguration zu veröffentlichen. Varning: Ausgaben wie die wirksame Konfiguration können Infrastrukturdetails oder sensible Angaben enthalten. Teile sie daher weder ungekürzt in Tickets noch in Foren oder öffentliche Dokumente, sondern bereinige sie gezielt.

Wann sich ein Dovecot-Update lohnt

Ein Dovecot-Update auf CE 2.4.5 ist nicht nur eine Funktions- und Architekturentscheidung. Die Release Notes führen zahlreiche kritische Sicherheitskorrekturen auf, die unter anderem IMAP-Befehle, Submission, OAuth-Prüfungen, dsync, Authentifizierung und Kompression betreffen. Betreiber sollten deshalb zeitnah prüfen, ob ihre Installation betroffen ist und über welchen Paket- oder Backportstand die verwendete Distribution die Korrekturen bereitstellt. Aus der Upstream-Version allein folgt weder, dass ein Distributionspaket ungepatcht ist, noch dass ein generisches Sofort-Upgrade ohne Migrationsprüfung sicher wäre.

Neben dieser Sicherheitsbewertung ist ein Update begründbar, wenn eine benötigte Kompatibilität, eine konkrete Betriebsanforderung oder eine nachvollziehbar testbare Modernisierung dahintersteht. Dazu können die kontrollierbaren Versionsschalter für Konfiguration und Speicher gehören. Ein Paketstand allein ist jedoch keine ausreichende Entscheidung: Mailbox-Format, Authentifizierung, Quota, Sieve, Suche und Proxy-Topologie bestimmen, wie groß der Migrationsaufwand tatsächlich ist.

Für Installationen auf 2.3 spricht eine Priorisierung besonders dann, wenn die Sicherheitslage und der verfügbare Distributionsstand eine Aktualisierung nahelegen und die Migration in einem Testsystem nachvollzogen werden kann. Dabei bleibt der Storage-Level bewusst zurückhaltend: Neue Speicherformate sollten erst aktiviert werden, wenn ein Rückweg auf ältere Dovecot-Versionen nicht mehr vorgesehen ist. Das betrifft unter anderem den in 2.4.5 geänderten Thread-Index, dessen Neuaufbau bei der nächsten Threading-Abfrage erfolgt.

Zusatzfunktionen sind getrennte Architekturentscheidungen. Flatcurve ist sinnvoll zu bewerten, wenn Nachrichtensuche regelmäßig genutzt wird und lokaler Indexspeicher, Xapian-Abhängigkeit, Überwachung sowie Reindexierung zum Betriebsmodell passen. Die Dokumentation ordnet den Treiber als lokalen, auf Xapian basierenden Volltextsuchindex ein; daraus folgt keine pauschale Empfehlung gegenüber Solr oder dem Verzicht auf FTS.

Experimentelle UTF8- und IMAP4rev2-Optionen rechtfertigen sich nur bei einem belegten Bedarf entlang der vollständigen Kette aus Mailclient, Submission beziehungsweise Zustellung und IMAP-Zugriff. Ohne diese Voraussetzung erhöht eine Aktivierung vor allem den Prüfaufwand. Gleiches gilt für neue Authentifizierungsmechanismen: Eine vorhandene Fähigkeit im Release ersetzt nicht die Prüfung der eingesetzten Clients, TLS-Konfiguration und der Authentifizierungsquelle.

Für Dovecot 3 lässt sich auf Basis der veröffentlichten CE-Informationen weder ein Termin noch ein Funktionsumfang oder ein Migrationspfad zusagen. Der belegte stabile Release ist CE 2.4.5; Hinweise in Entwicklungsdokumentation oder im Zweig main sind kein veröffentlichter Produktstand und keine Roadmap. Plane daher mit der konkret verfügbaren 2.4-Linie, trenne sie von Dovecot Pro und bewerte spätere Ankündigungen erst, wenn sie offiziell veröffentlicht sind.