Dovecot

Wenn ein E-Mail-Programm Nachrichten vom Server abruft, braucht es auf der Gegenseite eine Software, die den Zugriff auf das Postfach regelt. Dovecot übernimmt genau diese Aufgabe: Es stellt Mailboxen über standardisierte Protokolle bereit und verwaltet, wer auf welche Nachrichten zugreifen darf.

Was Dovecot in einer Mail-Infrastruktur leistet

Ein Mailserver besteht aus mehreren Komponenten. Der MTA (Mail Transfer Agent, etwa Postfix) nimmt eingehende Nachrichten entgegen und leitet sie weiter. Dovecot übernimmt die Rolle des MDA (Mail Delivery Agent) und des IMAP/POP3-Servers: Es legt eingehende Mails in die richtige Mailbox ab und stellt sie Clients zum Abruf bereit.

Beispiel: Ein Unternehmen betreibt Postfix als MTA. Postfix nimmt eine eingehende Nachricht an und übergibt sie über LMTP an Dovecot. Dovecot legt die Nachricht in der Mailbox des Empfängers ab. Thunderbird verbindet sich per IMAP mit Dovecot und zeigt die Nachricht an.

Beispiel: Ein Smartphone ruft alle fünf Minuten neue Mails per IMAP IDLE ab. Dovecot hält die Verbindung offen und sendet eine Benachrichtigung, sobald eine neue Nachricht eintrifft. Der Client muss nicht wiederholt den Server abfragen.

Dovecot ist unter einer permissiven Open-Source-Lizenz (MIT/X11 sowie LGPL für Teile) verfügbar und läuft auf allen gängigen Unix-Systemen (Linux, FreeBSD, Solaris). Die Software wird seit 2002 von Timo Sirainen entwickelt und gilt als einer der am weitesten verbreiteten IMAP-Server weltweit.

IMAP und POP3: Zwei Wege zum Postfach

Dovecot unterstützt zwei Protokolle für den Zugriff auf Mailboxen: IMAP und POP3. Beide haben unterschiedliche Einsatzbereiche.

IMAP (Internet Message Access Protocol) speichert Nachrichten auf dem Server. Mehrere Geräte können gleichzeitig auf dasselbe Postfach zugreifen. Ordnerstrukturen, Lesestatus und Flags werden serverseitig synchronisiert.

POP3 (Post Office Protocol Version 3) lädt Nachrichten herunter und löscht sie auf dem Server. Dieses Protokoll eignet sich, wenn Mails nur auf einem Gerät gelesen werden und der Serverplatz begrenzt ist.

Beispiel: Ein Redaktionsteam nutzt IMAP, damit alle Mitglieder gemeinsam auf das Postfach redaktion@firma.de zugreifen. Gelesene Nachrichten erscheinen auf allen Geräten als gelesen. POP3 wäre hier ungeeignet, weil heruntergeladene Mails auf anderen Geräten nicht mehr sichtbar wären.

Beispiel: Ein Monitoring-System ruft Statusmails per POP3 ab, verarbeitet sie und löscht sie. Da kein zweiter Client auf diese Mails zugreifen muss, reicht POP3 vollständig aus.

Dovecot unterstützt zusätzlich LMTP (Local Mail Transfer Protocol) als Schnittstelle zum MTA. LMTP erlaubt es dem MTA, Nachrichten direkt an Dovecot zur Zustellung zu übergeben, ohne den Umweg über eine lokale Mailbox-Datei.

Mailbox-Formate und Speicherarchitektur

Dovecot unterstützt mehrere Mailbox-Formate. Die Wahl des Formats beeinflusst Leistung, Zuverlässigkeit und Skalierbarkeit.

Maildir speichert jede Nachricht als einzelne Datei in einem Verzeichnis. Dieses Format ist robust gegenüber Abstürzen, da keine Datei nachträglich verändert wird. Gleichzeitige Zugriffe mehrerer Prozesse sind sicher.

mbox speichert alle Nachrichten eines Ordners in einer einzigen Datei. Das Format ist platzsparend, aber anfällig für Korruption bei gleichzeitigem Schreibzugriff.

dbox ist Dovecots eigenes Hochleistungsformat. Es gibt zwei Varianten: sdbox (single-dbox, eine Datei pro Nachricht) und mdbox (multi-dbox, mehrere Nachrichten pro Datei). mdbox reduziert die Anzahl der Dateisystem-Operationen und eignet sich für große Mailboxen.

Beispiel: Ein Hosting-Anbieter migriert von mbox auf mdbox. Vorher führte das Löschen einer einzelnen Nachricht in einem 2-GB-Ordner zu einer vollständigen Neuerstellung der mbox-Datei. Nach der Migration auf mdbox entfällt diese Operation, da Nachrichten individuell adressierbar sind.

Beispiel: Ein Systemadministrator wählt Maildir für einen Server, auf dem Backup-Software einzelne Dateien inkrementell sichert. Da Maildir jede Nachricht als separate Datei speichert, müssen bei einem Backup nur neue Dateien übertragen werden.

Dovecot indiziert Mailbox-Inhalte in eigenen Cache-Dateien (dovecot.index.*). Diese Indizes beschleunigen Operationen wie das Auflisten von Nachrichtenheadern oder die Suche nach Flags. Bei Beschädigung regeneriert Dovecot die Indizes automatisch aus den Originaldaten.

Authentifizierung und virtuelle Benutzer

Dovecots Authentifizierungssystem ist modular aufgebaut. Es unterstützt verschiedene Backends, über die Benutzerdaten abgefragt werden. Die wichtigsten sind:

passwd-file: Eine Textdatei im Format user:password:uid:gid:gecos:home:shell. Geeignet für kleine Installationen mit wenigen Benutzern.

SQL: Benutzer werden in einer SQL-Datenbank (MySQL, PostgreSQL, SQLite) gespeichert. Flexible Abfragen erlauben beliebige Datenbankstrukturen.

LDAP: Integration in vorhandene Verzeichnisdienste (Active Directory, OpenLDAP). Sinnvoll in Unternehmensumgebungen mit zentraler Benutzerverwaltung.

Beispiel: Ein Hosting-Provider verwaltet 50.000 Mailboxen. Jede Mailbox ist ein virtueller Benutzer in einer MariaDB-Tabelle. Die SQL-Abfrage prüft Benutzername und Passwort-Hash. Kein einziger dieser Benutzer existiert als Systemuser auf dem Linux-Host.

Das Konzept der virtuellen Benutzer ist zentral: Dovecot trennt Mailbox-Identitäten von Betriebssystem-Benutzern. Alle virtuellen Mailboxen laufen unter einem gemeinsamen Systembenutzer (typisch: vmail). Das vereinfacht die Verwaltung und reduziert die Angriffsfläche.

Beispiel: Ein Systemadministrator migriert von einem Setup mit einem Linux-User pro Mailbox zu virtuellen Benutzern. Vorher erforderte jede neue Mailbox einen useradd-Befehl. Nach der Migration genügt ein INSERT in die Datenbank.

Fachliche Einordnung: Dovecots Authentifizierungsframework implementiert das SASL-Protokoll (Simple Authentication and Security Layer, RFC 4422). Es stellt diesen Dienst auch externen Programmen bereit. Postfix kann Dovecot-SASL nutzen, um SMTP-Clients zu authentifizieren. Damit existiert eine einzige Quelle für Zugangsdaten im gesamten Mailsystem.

Sieve: Serverseitige Filterregeln

Sieve ist eine Skriptsprache für serverseitige Mailfilterung (RFC 5228). Dovecot implementiert Sieve über das Plugin pigeonhole. Filterregeln werden auf dem Server ausgeführt, unabhängig davon, welcher Client die Mails abruft.

Ein Sieve-Skript besteht aus Bedingungen und Aktionen. Typische Aktionen sind: Nachricht in einen Ordner verschieben (fileinto), weiterleiten (redirect), verwerfen (discard) oder mit einem Flag versehen (addflag).

Beispiel: Ein Sieve-Skript sortiert eingehende Rechnungen automatisch:

require ["fileinto", "imap4flags"];
if header :contains "Subject" "Rechnung" {
  addflag "\Flagged";
  fileinto "Buchhaltung";
}

Beispiel: Eine KI-gestützte Mailverarbeitung nutzt Sieve als Vorfilter. Nachrichten bestimmter Absender werden per redirect an einen Verarbeitungsdienst weitergeleitet. Der Dienst analysiert den Inhalt und legt eine strukturierte Zusammenfassung in einem separaten Ordner ab.

Sieve-Skripte lassen sich über das ManageSieve-Protokoll (RFC 5804) hochladen und verwalten. Clients wie Thunderbird (mit Plugin) oder Roundcube können Filterregeln direkt auf dem Server bearbeiten, ohne dass ein Administrator eingreifen muss.

Prozessarchitektur und Sicherheitsmodell

Dovecot folgt einem Multiprocess-Design mit strikter Aufgabentrennung. Jede Funktion läuft in einem eigenen Prozess mit minimalen Rechten.

Master-ProzessRoot-Rechte, startet Kindprozesse
Auth-ProzessBenutzerdaten prüfen
Login-ProzessVerbindungsannahme
IMAP-ProzessPro Verbindung
LMTP-ProzessNachrichtenzustellung
Sieve-ProzessFilterausführung
Dict-ProzessQuota, Shared State

Der Master-Prozess läuft als Root und startet Kindprozesse. Login-Prozesse nehmen eingehende Verbindungen an und kommunizieren mit dem Auth-Prozess. Nach erfolgreicher Authentifizierung wird die Verbindung an einen dedizierten IMAP-Prozess übergeben, der mit den Rechten des jeweiligen Benutzers läuft.

Beispiel: Ein Angreifer findet eine Schwachstelle im IMAP-Protokollparser. Da der IMAP-Prozess mit den Rechten des Benutzers vmail läuft und keinen Zugriff auf andere Mailboxen hat, bleibt der Schaden auf die betroffene Mailbox begrenzt.

Dovecot unterstützt TLS-Verschlüsselung für alle Protokolle. Die Konfiguration erlaubt die Angabe von Mindest-Protokollversionen (ssl_min_protocol = TLSv1.2) und Cipher-Suites. STARTTLS für opportunistische Verschlüsselung und direktes TLS (IMAPS auf Port 993, POP3S auf Port 995) werden beide unterstützt.

Zusammenspiel mit Postfix

Dovecot und Postfix bilden eine der verbreitetsten Kombinationen im Mail-Bereich. Ihre Zusammenarbeit erfolgt über definierte Schnittstellen.

LMTP-Zustellung: Postfix übergibt eingehende Nachrichten per LMTP an Dovecot. In der Postfix-Konfiguration wird virtual_transport = lmtp:unix:private/dovecot-lmtp gesetzt. Dovecot nimmt die Nachricht entgegen, führt Sieve-Filter aus und legt sie in der Mailbox ab.

SASL-Authentifizierung: Postfix nutzt Dovecots Auth-Service, um SMTP-Clients zu authentifizieren. Konfiguriert wird dies über smtpd_sasl_type = dovecot in Postfix und einen passenden Auth-Socket in Dovecot.

Beispiel: Ein Benutzer sendet eine Nachricht über Thunderbird per SMTP an Postfix. Postfix fragt bei Dovecot nach, ob die Zugangsdaten stimmen. Dovecot prüft gegen die SQL-Datenbank und bestätigt. Postfix nimmt die Nachricht an und stellt sie zu.

Beispiel: Eine eingehende Nachricht durchläuft folgende Kette: Der externe MTA liefert per SMTP an Postfix. Postfix prüft SPF und DKIM. Postfix übergibt per LMTP an Dovecot. Dovecot führt ein Sieve-Skript aus und legt die Nachricht im Ordner "Eingang" ab. Der Client ruft sie per IMAP ab.

Skalierung und Hochverfügbarkeit

Für kleine Installationen (bis einige tausend Mailboxen) reicht ein einzelner Dovecot-Server. Bei steigenden Anforderungen bietet Dovecot mehrere Skalierungsoptionen.

Director: Dovecots Director-Komponente verteilt Benutzer auf mehrere Backend-Server. Der Director stellt sicher, dass ein Benutzer immer zum selben Backend geleitet wird (Session Stickiness). Das vermeidet Konflikte bei gleichzeitigem Zugriff auf Mailbox-Indizes.

Shared Storage: Mehrere Dovecot-Instanzen greifen auf ein gemeinsames NFS- oder Cluster-Dateisystem zu. Dovecots Lock-Mechanismen koordinieren den Zugriff. Diese Architektur erfordert ein zuverlässiges Netzwerk-Dateisystem.

Beispiel: Ein E-Mail-Anbieter mit 500.000 Mailboxen verteilt die Last auf zehn Backend-Server. Der Director ordnet jedem Benutzer anhand eines Hashes einen Server zu. Fällt ein Backend aus, werden dessen Benutzer auf die verbleibenden Server umverteilt.

Dovecots Replikations-Plugin synchronisiert Mailboxen zwischen zwei Servern in Echtzeit. Bei Ausfall eines Servers übernimmt der andere. Die Replikation arbeitet auf Mailbox-Ebene und überträgt nur geänderte Nachrichten.

Fachliche Einordnung: Dovecots Director implementiert ein Consistent-Hashing-Verfahren zur Benutzerverteilung. Die Architektur ähnelt dem Proxy-Layer in anderen verteilten Systemen (etwa Redis Cluster oder Cassandras Partitioner). Die Herausforderung liegt im Failover: Wenn ein Backend ausfällt, müssen laufende IMAP-Sessions sauber migriert werden. Dovecot löst das über einen konfigurierbaren Timeout und automatische Session-Umleitung.

Grenzen und Einordnung

Dovecot deckt einen spezifischen Bereich der Mail-Infrastruktur ab. Es ist kein vollständiger Mailserver im Sinne einer All-in-One-Lösung. Für den Nachrichtenversand wird ein MTA (wie Postfix oder Exim) benötigt. Für Webmail ist ein separater Client (wie Roundcube oder SOGo) erforderlich.

Die Konfiguration ist mächtig, aber komplex. Dovecots Konfigurationssystem arbeitet mit bedingten Blöcken (protocol imap { }, local 192.168.1.0/24 { }) und Vererbung. Bei großen Installationen mit vielen Sonderfällen kann die Konfiguration unübersichtlich werden.

Beispiel: Ein Administrator will unterschiedliche TLS-Zertifikate für verschiedene Domains einsetzen. Er nutzt Dovecots local_name-Direktive mit SNI (Server Name Indication). Die Konfiguration erfordert verschachtelte Blöcke und genaue Kenntnis der Reihenfolge, in der Dovecot Konfigurationsblöcke auswertet.

Dovecots Volltextsuche (FTS) unterstützt verschiedene Backends (Solr, Lucene, Flatcurve). Die Indexierung großer Mailboxen benötigt Rechenzeit und Speicher. Ohne FTS-Plugin durchsucht Dovecot Nachrichten sequentiell, was bei großen Mailboxen mehrere Sekunden dauern kann.

Beispiel: Ein Unternehmen mit gesetzlichen Aufbewahrungspflichten archiviert zehn Jahre E-Mail-Verkehr. Die Mailboxen umfassen mehrere hunderttausend Nachrichten. Ohne FTS-Index dauert eine Suche nach einem bestimmten Stichwort bis zu 30 Sekunden. Mit aktiviertem Flatcurve-Plugin sinkt die Suchzeit auf unter eine Sekunde.

Im Vergleich zu kommerziellen Groupware-Lösungen (Microsoft Exchange, Zimbra) fehlen Dovecot Kalender-, Kontakt- und Aufgabenverwaltung. Dovecot konzentriert sich auf eine Aufgabe: den Zugriff auf E-Mail-Postfächer. Diese Fokussierung ist gleichzeitig seine größte Stärke und seine Begrenzung.


Karl Kratz · 29.01.2026

Technologie E-Mail Server