© goesel, Photocase.com

Er wird wohl der Aufsteiger des Jahres unter den IMAP-Servern: Timo Sirainens Dovecot. Der Einstieg in die ausgereifte Version 2.0 ist simpel, nur manch fehlerhaftes Online-Howto bereitet dem Admin Probleme beim Manövrieren. Eine Anleitung.

Die Luft wird dünn in den Höhen der professionellen Mailserver. Lange Zeit dominierten Courier- und Cyrus-Server die IMAP-Wolken. Doch jetzt schaltet ein Dritter, Dovecot, den Nachbrenner ein. Die Feature-Liste [1] der Version 2.0 (der aktuelle Release Candidate ist auf der DELUG-DVD) hält dem Vergleich mit der Konkurrenz stand [2]. Gleichzeitig punktet der Taubenschlag (auf Englisch Dovecot) durch eine saubere und stabile Implementierung, eine ungewohnte Flexibilität, mächtige Erweiterungs-Plugins und für den Admin wichtige Debug- und Analyse-Möglichkeiten.

Schneller mit Index

Die Speicherung von E-Mails im Standard-Maildir-Format erzeugt erfahrungsgemäß hohe I/O-Lasten. Dovecot [3] setzt dem clevere Index-Strategien entgegen. Anders als Cyrus benötigt der Newcomer keine Datenbank, die im Falle eines Defekts das ganze System lahmlegt. Dovecot nutzt lediglich einen Index zu Caching-Zwecken, der sich im Zweifel jederzeit löschen lässt und den der Server im Fehlerfall auch kurzerhand selbstheilend neu aufbaut. Raffiniert: Den Index eines jeden Postfachs passt Dovecot individuell an die spezifischen Abfragemerkmale des verwendeten Mailclients an.

Die von den Distributionen mitgebrachte »dovecot.conf« ist umfangreich und gut lesbar dokumentiert (Abbildung 1). Bei Änderungen sollte der Admin aber darauf achten, dass er die jeweiligen Parameter stets in die richtige Sektion einträgt. Alle in diesem Artikel gezeigten Parameter sind in »dovecot.conf« bereits enthalten. Wer die Beispiele nachvollziehen will, braucht sie in seinem Editor nur zu suchen und an Ort und Stelle anzupassen, bevor er dem Mailserver einen Reload aufzwingt. Für den Anfang mit Dovecot setzen die folgenden Parameter die vorgegebene Gesprächigkeit hoch und liefern ausführlichere Logfiles:

Abbildung 1: Die Datei »dovecot.conf« ist die zentrale Schaltstelle des Mailservers, in Sektionen gruppieren sich hier die Einstellungen. Etwas ungewohnt spielt die Reihenfolge der Parameter eine wichtige Rolle.

mail_debug = yes
auth_verbose = yes
auth_debug = yes
auth_debug_password = yes

Dovecot verlangt nur wenige Anpassungen der Standardwerte in der Dovecot-Konfiguration, das Ergebnis lässt sich im Logfile verifizieren (Abbildung 2).

Abbildung 2: Mit aktiviertem Debugging ist das Logfile von Dovecot recht gesprächig.

Quick aber dirty

Jeder IMAP-Server braucht seinen SMTP-MTA. Aber wenn es um die Anbindung von Dovecot an Postfix geht, beschreiben leider fast alle Howtos im Netz, selbst das Dovecot-Wiki, nur zwei von drei Möglichkeiten. Ausgerechnet die beiden Varianten, die eher unsauber sind und zahlreiche Folgeprobleme mit sich bringen, stehen hoch im Kurs.

Der ersten Variante nach soll der Admin die Maildomain bei Postfix in »$mydestination« eintragen, damit sich dieser lokal dafür zuständig fühlt; später hat er das »mailbox_command« so zu setzen, dass Postfix die aus seiner Sicht lokale Zustellung dem »deliver«-Programm von Dovecot überlässt.

Diesen Weg sollten Admins aber nur wählen, wenn alle Nutzer tatsächlich in »/etc/passwd« eingetragen sind und es sich um lokale Mails handelt. In diesen Fällen ist die Konfiguration denkbar einfach. Per Default verifiziert Dovecot die POP3- oder IMAP-Logins via PAM gegen »/etc/passwd« und »/etc/shadow«, sodass keine weiteren Arbeiten nötig sind.

Postfix könnte die Mails zwar auch ohne Weiteres selbst im Maildir-Format in den Homeverzeichnissen der Nutzer ablegen. Etwas vorteilhafter ist es jedoch, das dafür von Dovecot mitgebrachte »deliver« zu nutzen. Wer diesem die Speicherung der E-Mails überlässt, kann später auch Quotas, Sieve-Regeln oder das neue Mdbox-Format [4] nutzen.

Dessen Einrichtung gestaltet sich simpel, es reicht, in der Datei »main.cf« von Postfix den für die jeweilige Distribution passenden Deliver-Aufruf zu nennen:

mailbox_command=/usr/lib/dovecot/deliver

Doch wer mit virtuellen Accounts arbeitet, die nicht in »/etc/passwd« angelegt sind, sollte die Maildomain folgerichtig auch nicht in »$mydestination« hinterlegen – auch wenn sehr viele Anleitungen genau das vorschlagen.

Virtuelle User

In diesem Fall wird Postfix die E-Mails folgerichtig zunächst als »user unknown in local recipient table« ablehnen. Die Anleitungen lösen das, indem sie kurzerhand »$local_recipient_maps« als leer definieren. Doch das hebelt die Empfängerprüfung von Postfix vollständig aus. Die Konfiguration bringt neben Backscatter-Problemen auch eine Vielzahl weiterer Komplikationen mit sich, beispielsweise wenn in Status- oder Warnmails die System-User wie »root«, »wwwrun« oder »cron« ins Spiel kommen. Die sind häufig unter der Maildomain nicht angelegt und funktionieren lokal eventuell gar nicht mehr, da die Mailserver die Datei »/etc/passwd« nicht mehr auswerten.

Wer weder Datenbank noch LDAP-Verzeichnis mit Nutzerdaten betreiben möchte, wird noch lange nicht genötigt, deswegen gleich alle Accounts als echte User in »/etc/passwd« anzulegen. Stattdessen ist er mit dem Authentifizierungsbackend »passwd-file« gut beraten, das alle Accountdaten in einer Dovecot-eigenen Ascii-Datei pflegt, deren Syntax exakt der »/etc/passwd« nachempfunden ist. Die lässt sich leicht manuell pflegen oder skriptgesteuert erzeugen.

So bleiben Mailaccounts und Login-User sauber getrennt, auch größte Setups haben damit kein Problem. Dank der eingebauten Caching-Mechanismen kann das Password-File problemlos auch sechsstellige Accountzahlen robust und zuverlässig vorhalten [5].

Mailbox-Relay

Betreibt der Admin Dovecot mit einer vom System getrennten Userdatenbank (wie MySQL, LDAP, Passwd-File), dann sollte er entgegen den meisten Anleitungen die für Dovecot genutzte Maildomain weder über »$mydestination« noch über »$virtual_alias_domains« in Postfix einbinden. Besser ist, Dovecot als nachgeordnetes Mailrelay hinter Postfix zu verstehen, wie in den klassischen Relay-Setups, in denen Postfix die Mails beispielsweise an ein Groupware-System durchreicht. In diesen Fällen steht Postfix vor einer Black Box mit eigener Userdatenbank.

Dafür muss die Dovecot-Maildomain folgerichtig bei Postfix in »$relay_domains« eingetragen sein. Später wird sie per »$transport_maps« an den Deliver-Prozess geroutet, der nun als Transportmethode mit dem Namen »dovecot:« in der »master.cf« hinterlegt ist. Das hat den bedenkenswerten Vorteil, dass in allen Fällen das gleiche Setup zum Zuge kommt, egal ob der Server Dovecot oder ein anderes Mailsystem nutzt.

Wer Version 2.0 einsetzt, schaltet mit dem eingebauten LMTP-Socket sogar noch leichter um, ohne sein System umzubauen. In der »master.cf« lautet ein passender Eintrag einfach:

dovecot unix - n n - - pipe
 flags=DRhu user=vmail:vmail argv=/usr/lib/
dovecot/deliver -f ${sender} -d ${recipient}

Da E-Mails mehr Empfänger im Envelope enthalten können, als die Shell Aufrufparameter zur Verfügung stellt, braucht es für jeden Empfänger einen Deliver-Aufruf. Das erledigt in der »main.cf«:

dovecot_destination_recipient_limit = 1

Für das Mailrouting in Postfix reicht es, »$relay_domains« und »$transport_maps« in »main.cf« auf dieselbe Datei zeigen zu lassen:

relay_domains=hash:/etc/postfix/relay_
domains
transport_maps=hash:/etc/postfix/transport_
maps,hash:/etc/postfix/relay_domains

So klärt ein Eintrag alle wesentlichen Informationen zum Mailrouting, was Fehler vermeidet und das Setup schlank und übersichtlich macht. Jetzt trägt der Admin die Dovecot-Maildomain in die Datei »relay_domains« ein und routet die Mails damit an den Deliver-Aufruf in der »master.cf« von Postfix:

example.org  dovecot:

Der Vorteil: Alle lokalen Systemmails, etwa an »root@localhost« oder »wwwrun @$myhostname«, betrachtet Postfix weiterhin als lokal, prüft sie gegen »/etc/passwd« und stellt sie lokal im System zu. Die Userbestände sind sauber voneinander getrennt ansprechbar.

Wer Dovecot mit anderen Authentifizierungsquellen betreiben will, findet in den flexiblen Backends breite Unterstützung. Dovecot trennt dabei zwischen den Lookups, die die Existenz eines Users und die Gültigkeit eines Passworts verifizieren (»passdb«), und denen, die die weichen Daten eines Users wie seine User- oder Group-ID, den Pfad zu seinem Mailverzeichnis, seine Quota-Regeln oder andere Besonderheiten ergeben (»userdb«).

Im Normalfall zeigen Passdb- und Userdb-Abfrage auf dieselbe Datenquelle, andererseits lassen sich auf diese Art und Weise auch besonders trickreiche Abfragen aus verschiedenen Datenquellen zusammenbauen.

LDAP-Tricks

Ein Admin, der mit virtuellen Nutzern arbeitet, die keine echte Entsprechung in »/etc/passwd« haben, sollte versuchen möglichst viele Informationen zum Nutzer statisch berechnen zu lassen. Erfreulicherweise kann er in diesen Fällen alle Daten der Nutzer unter ein und derselben User- undGroup-ID ablegen (beispielsweise »vmail:vmail«), wenn er diese Accounts in »/etc/passwd« beziehungsweise »/etc/groups« einträgt

groupadd -r -g 10000 vmail
useradd -r -s /bin/false -u 10000 -g 10000
 vmail

und sie dann systemweit in der »dovecot.conf« festlegt:

mail_uid = vmail
mail_gid = vmail

Auch individuelle Angaben wie beispielsweise der Speicherpfad der E-Mails lassen sich leicht aus der E-Mail-Adresse berechnen. Dovecot stellt dafür Platzhalter wie »%u« (Mailadresse), »%d« (Domain) und »%n« (Userpart der Mailadresse) bereit. Manche Anleitungen schlagen vor die Pfade an verschiedenen Stellen dann direkt auf das Zielverzeichnis zeigen zu lassen

maildir_location = maildir:/var/vmail/%d/%n
/Maildir
sieve = /var/vmail/%d/%n/.dovecot.sieve
sieve_dir = /var/vmail/%d/%n/sieve

um auf die Definition eines Homeverzeichnisses zu verzichten:

Doch spätestens mit Dovecot 2.0 wirft ein fehlendes Homeverzeichnis bei den Tools Doveadm und Dsync (siehe weiter unten) Probleme auf. Besser ist es, in der globalen Konfiguration die Defaultwerte zu belassen und an anderer Stelle dafür zu sorgen, dass »~« auf die richtigen Pfade verweist:

mail_location = ~/Maildir
sieve = ~/.dovecot.sieve
sieve_dir = ~/sieve

Nicht nur SQL-Statements können so für »home« den richtigen Wert hartkodiert behalten oder als Ergebnis einer Concat-Abfrage ergeben. Auch das LDAP-Backend von Dovecot bietet die Möglichkeit, die entsprechenden Attribute mit den gewünschten Werten zu füllen, ohne dass die Werte im Verzeichnisdienst vorliegen müssen.

Ist LDAP für die Userdb- und Passdb-Abfrage aktiviert

auth default {
 userdb ldap {
  args = /etc/dovecot/dovecot-ldap.conf
 }
 passdb ldap {
  args = /etc/dovecot/dovecot-ldap.conf
 }
[...]
}

dann lässt sich in »/etc/dovecot/dovecot-ldap.conf« leicht das Homeverzeichnis des eingeloggten Users setzen. Per Default beinhaltet »user_attrs« mit:

user_attrs = homeDirectory=home, uidNumber
=uid, gidNumber=gid

Mappings auf LDAP-Attribute. Alternativ stellt der Admin diese Werte über Platzhalter fest ein, indem er deren Reihenfolge vertauscht und vorangestellte Gleichheitszeichen verwendet:

user_attr = =home=/var/mail/%d/%n,=uid=
10000,=gid=10000

Am Ende muss die benutzte User-DB die Mailadresse, einen Login-Namen und das Passwort enthalten. Auf diesem Weg lässt sich ohne Schema-Erweiterung auch Active Directory anbinden.

Zwei SASL-Lügen

Wer SMTP-Clients wie üblich per Passwort authentifizieren will, kommt um eine SASL-Bibliothek nicht herum. Über Jahre hinweg hatte Cyrus-SASL hier quasi eine Monopolstellung. Kenner des Cyrus-Programmcode unkten aber, die Bedeutung der Abkürzung “Simple Authentication and Security Layer” beinhalte mindestens zwei Lügen [6].

Da Dovecot ohnehin über umfangreiche und ausgefeilte Authentifizierungs-Backends verfügt und kaum jemand parallel zu Dovecot noch Cyrus installieren möchte, bot Timo Sirainen kurzerhand Dovecot-SASL an, das alle Postfix-Versionen (ab 2.3) unterstützen und über ein einfaches Protokoll an einem Unix-Socket ansprechen. Seitdem genügt ein Dreizeiler in Postfix, und alle Probleme mit SMTP-Auth sind Geschichte, CRAM-Verfahren inklusive.

Dafür muss zunächst in Dovecot in der Section »auth« neben dem üblicherweise schon vorhandenen Socket »master« noch ein Socket »client« eingerichtet sein, damit auch externe Programme wie Postfix ihre Authentifizierungsanfragen an Dovecot übergeben. Dieser Socket zeigt am besten direkt zu Postfix, damit dieser auch aus einer Chroot-Umgebung heraus darauf zugreifen kann. User-/Gruppenrechte »postfix« und Dateirechte »660« schützen den Socket vor unbefugtem Zugriff. Abbildung 3 zeigt die passenden Werte für die Master-Client-Sektion.Auf Postfix-Seite genügen wenige Zeilen Konfiguration in der »main.cf«

Abbildung 3: Gerade im Vergleich zu anderen IMAP-Servern funktioniert die SASL-Authentifizierung einfach.

smtpd_sasl_auth_enable=yes
smtpd_sasl_type=dovecot
smtpd_sasl_path=private/auth

damit der Server den Socket richtig anspricht und SMTP-Auth anbietet.

Mails filtern mit Sieve

Wer Dovecot nutzt, will in aller Regel auch von den umfangreichen Möglichkeiten Gebrauch machen, mit der Filtersprache Sieve E-Mails direkt auf dem Server zu filtern, umzuleiten, in Unterordner einzusortieren oder per Urlaubs-Autoresponder zu beantworten.

Dazu öffnet der Server auf Port 2000 einen kleinen Sieve-Manager, über den die User mit ihrem Mailclient ihre Filterskripte hochladen und aktivieren. In Dovecot muss dafür lediglich das Protokoll »managesieve« aktiviert sein:

protocols=pop3 pop3s imap imaps managesieve

Damit die eigentliche Filterarbeit beim Einsortieren durch das Deliver-Programm erfolgen kann, aktiviert der Admin mit

protocol lda {
  [...]
  mail_plugins = cmusieve
  [...]
}

bei diesem noch das Sieve-Plugin. Zwar weiß nur eine Minderheit der Mailclients gar nichts mit Sieve anzufangen, aber selbst Kmail und Thunderbird bringen für Sieve zunächst nur einfache Ascii-Editoren mit und überlassen es dem User, seine Skripte per Hand in der richtigen Syntax zu programmieren, undenkbar im Unternehmenseinsatz. Netter sind hier schon Webmailer wie Squirrelmail oder Roundcube [7], die gut funktionierende Web-GUIs mitbringen, in denen sich der User seine Filterregeln zusammenklickt (Abbildung 4).

Abbildung 4: Das Sieve-Plugin von Roundcube ist beinahe fertig, am ACL-Support arbeiten die Entwickler.

Shared Folders und Access Control Lists

Die wenigsten Admins wissen, dass über das IMAP-Protokoll sogar Zugriff auf das Dateisystem des Servers möglich ist. Bekannter ist da die Bedeutung der Shared Folder, also einzelner, gemeinsam genutzter IMAP-Verzeichnisse, die sich Nutzer untereinander mit verschiedenen Rechten freigeben können. Sobald neben dem Namespace »private« (dem eigentlichen IMAP-Postfach des Nutzers) noch ein Namespace »shared« konfiguriert ist, blenden Mailclients hier die Freigaben ein (Listing 1).

01 namespace private {
02   separator = /
03   inbox = yes
04   subscriptions = yes
05 }
06 namespace shared {
07   separator = /
08   prefix = shared/%%u/
09   location = maildir:%%h/Maildir:INDEX=~/Maildir/shared/%%u
10   subscriptions = no
11   list = children
12 }

Diese erfolgen über ACLs, die die Mailclients über das IMAP-Protokoll selbst auf dem Server hinterlegen. Der Administrator hat dann mit der Rechteverwaltung nichts mehr zu tun, das erledigt der Mailer, zum Beispiel Kmail in Abbildung 5. Damit die Access Control Lists funktionieren, braucht der Server in seiner Konfigurationsdatei noch die beiden Plugins »acl« und »imap_acl«, zum Beispiel mit dem Eintrag:

Abbildung 5: KDE-Benutzer setzen ACLs an einem IMAP-Ordner in Kmail.

protocol imap {
  [...]
  mail_plugins = acl imap_acl
  [...]
}

Anschließend benötigt Dovecot noch eine kleine Hilfsdatei »sharedmailboxes«, in der er verzeichnet, welcher Nutzer Freigaben für andere erteilt hat:

plugin {
  [...]
  acl = vfile:
  acl_shared_dict = file:/var/lib/dovecot/
sharedmailboxes
  [...]
}

Achtung: Die Datei »sharedmailboxes« muss für Dovecot schreibbar sein, damit er sie im laufenden Betrieb aktualisieren kann. Wer – wie oben gezeigt – Dovecot pauschal auf die User- und Gruppen-ID »vmail« umgestellt hat, muss dann hier »chown vmail:vmail /var/lib/dovecot« aufrufen.

Ähnlich wie bei Sieve-Regeln ist die ACL-Unterstützung bei vielen Mailclients jedoch noch sehr unterschiedlich. Wie so häufig geht Kmail schon lange mit mustergültiger Implementation voran. Auch Thunderbird beherrscht mittlerweile ACLs, wenn das passende Plugin [8] dafür aktiviert ist. Dass da weder Evolution noch Outlook mithalten können, ist ein Armutszeugnis.

Hier hilft ein separates Web-GUI, über das sich die Anwender entsprechende Freigaben erteilen. Für Squirrelmail gibt es ein Plugin, für Roundcube ist es geplant. Admins anderer Produkte müssen sich mit einer eigenständigen Lösung wie dem CGI-Skript »imapacl.pl« helfen [9].

Neben den vorgestellten Plugins erfreut Dovecot den Admin noch mit weiteren Details, die sein Leben leichter machen. So kann das Plugin »autocreate« bei jedem IMAP-Login eines Nutzers dafür sorgen, dass bestimmte IMAP-Folder definitiv vorhanden sind, oder sie anlegen lassen (Listing 2).

01 protocol imap {
02   mail_plugins = [...] autocreate
03 }
04 
05 plugin {
06   [...]
07   autocreate = Trash
08   autocreate2 = Drafts
09   autosubscribe = Trash
10   autosubscribe2 = Drafts
11 }

Wer Spam in Spamverdacht-Ordnern verwaltet, wird diese von Zeit zu Zeit aufräumen müssen. Hier hilft das Expire-Plugin weiter. Wer sich dafür interessiert, konsultiert am besten [10], die Vorgehensweise unterscheidet sich je nach Version und DB-Backend sehr.

Dovecot 2.0

All das funktioniert schon mit den Dovecot-Versionen aus gängigen Repositories. Anfang Juli ist aber schon der zweite Release-Kandidat erschienen, die Freigabe von Dovecot 2.0 steht also unmittelbar bevor. “Sobald ich zwei Wochen keine relevanten Bugreports mehr sehe, erscheint Version 2.0.0”, erklärt Chefentwickler Timo Sirainen.

Das größte Highlight im Neuling ist der nun endlich vorhandene LMTP-Socket, der den oben gezeigten »deliver«-Prozess überflüssig macht und so auch dynamische Empfängerprüfungen über die Postfix-Option »reject_unverified_recipient« ermöglicht. Mit

service lmtp {
 unix_listener /var/spool/postfix/private/
dovecot-lmtp {
   group = postfix
   mode = 0660
   user = postfix
  }
}

lässt sich bei Postfix der oben gezeigte Eintrag in »relay_domains« und »transport_maps« mit einem Handgriff umstellen. Aus »example.org dovecot:« wird

example.org lmtp:unix:private/dovecot-lmtp

und der bislang notwendige Eintrag in der »master.cf« von Postfix entfällt. Wer Plugins wie Sieve oder Quota nutzt, muss über

protocol lmtp {
  mail_plugins = quota cmusieve
}

diese auch in der neuen Lmtp-Sektion aktivieren.

Admintool: Doveadm

Dovecot 2.0 bringt ein eigenes Utility »doveadm« [11] mit, das neben Möglichkeiten zum Debuggen der User-Authentifizierung auch vielfältige Operationen an den Mailverzeichnissen der Nutzer erlaubt. Wer sich auskannte, konnte das auch bislang schon direkt im Dateisystem erledigen, aber das neue »doveadm« ermöglicht diese Operationen nun ohne Detailkenntnis. Damit begegnet der Admin diversen Standardsituationen deutlich sicherer als vorher in Shellskripten und Cronjobs.

Da »doveadm« als interner Dovecot-Prozess auf die Daten zugreift, der auch Daten wie »mail_location« eines jeden Users einzeln setzt, darf es dem aufrufenden Admin nun egal sein, wo und in welchem Format die E-Mails eines Nutzers tatsächlich gespeichert sind. Fast alle Operationen am Mailbestand eines Benutzers lassen sich damit ausführen.

Über Doveadm kann der Admin beispielsweise alte Mails automatisch löschen, Mailboxen erzeugen oder umbenennen. Wer über das Mdbox-Format unterschiedlich schnelle Speichermedien für verschiedene Bereiche des Postfachs benutzt, verschiebt mit Doveadm Mails nach bestimmten Kriterien zwischen den verschiedenen Platten. Dabei kann er auch einzelne E-Mails aus dem Postfach des Accounts nach vielfältigen Kriterien (Alter, Größe, Flags) auswählen.

Darüber hinaus aktualisiert Doveadm Quota-Informationen, sieht Rate-Limits ein oder wirft Nutzer anhand ihrer IP-Adresse oder ihrer Login-Kennung aus dem System. Die noch nicht fertiggestellte neue Wiki-Seite zu Doveadm verschafft schon jetzt einen guten Überblick über die wichtigsten Fähigkeiten [11].

Mdbox schont I/O

Bei der Performance haben die Entwickler noch einmal draufgelegt. Das tat not, ganz egal wie intelligent Dovecot per Cache- und Index-Dateien die Speicherung der E-Mails im alten Maildir-Format beschleunigt. Allein die Tatsache, dass Millionen von E-Mails weiterhin in ebenso vielen einzelnen Dateien gespeichert sind, bringt aufgrund der enormen I/O-Zugriffslast beim Anfassen jedes File den Dateisystem-basierten Backup-Prozess an den Rand der Möglichkeiten: Bei einem Mailbestand um 2 TByte sind mehrtägige Backups keine Seltenheit.

Mit dem Mbox-Format hingegen, das alle Mails in einer großen Datei speichert, treten im Produktivbetrieb ebenso große Nachteile zu Tage. Admins kennen die Performanceprobleme, wenn der Benutzer Mails aus der Mbox-Datei löscht, oder File-Locking-Probleme beim gleichzeitigen Zugriff auf ein Postfach.

Mit Version 1.2 führte Dovecot darum das Mdbox-Format ein, das die Vorteile beider Varianten kombiniert und alle Nachteile eliminiert und das jetzt mit Version 2.0 und Doveadm erstmals auch produktiv nutzbar ist.

Aus der bisherigen Maildir-Einstellung »mail_location = maildir:~/Maildir« macht der Admin in der Dovecot-Konfiguration nun »mail_location = mdbox:~/mdbox«. Zur weiteren Verwaltung dienen bei Mdbox dann aber Indexdateien, die Flags und Speicherort der jeweiligen E-Mail festlegen und deren Information für den Betrieb deshalb zwingend erforderlich ist.

Die E-Mails eines Users sind in seinen zentralen Mdbox-Dateien gespeichert, egal in welchem IMAP-Ordner die E-Mail tatsächlich abgelegt ist. Auch diese Information steht nur in den Indexdateien, was das Verschieben oder Löschen von E-Mails vereinfacht und das mittelfristig geplante Feature der Single-Instance-Speicherung ermöglicht, falls eine Mail in einem Postfach oder auf dem System mehrfach vorhanden ist.

Die Vorteile von Mdbox büßt der Admin, weil er nicht mehr so leicht und direkt Manipulationen im Dateisystem vornehmen kann. Er ist nun auf eine konsequente Arbeit mit den dafür nun geschaffenen Kommandos des »doveadm«-Tools angewiesen.

Das mit Version 2.0 eingeführte Utility »dsync« konvertiert bequem und sicher Mails zwischen den verschiedenen Formaten Mbox, Maildir und Mdbox, beispielsweise um ein Upgrade von Maildir auf Mdbox durchzuführen. Ist in Dovecot bereits »mail_location« auf das neue Format »mdbox« gesetzt, lässt sich ein vorhandener Maildir-Bestand aber auch einlesen und konvertieren:

dsync -u username mirror maildir:~/Maildir

Dsync bestimmt dann durch den normalen Authentifizierungsprozess das Homeverzeichnis und die Einstellung von »username« und konvertiert die Daten. Nach erfolgreichen Tests braucht der Admin jetzt nur noch von Hand den nicht mehr benötigten Maildir-Bestand zu löschen, um den Platz auf der Festplatte freizugeben.

Formationsflug: Dsync

Im »mirror«-Modus erkennt und berücksichtigt »dsync« Änderungen auf beiden Seiten. Damit können Admins zwei unterschiedliche Postfächer bidirektional synchron halten, mit SSH-Tunneln auch zwischen zwei verschiedenen Servern. Der Aufruf von

dsync -u username mirror ssh root@Zweiter_
Server.example.com dsync -u username

sorgt dafür, dass Dovecot Änderungen im Postfach des Users »username« zwischen beiden Servern abgleicht. Wer statt »mirror« das Dsync-Kommando »backup« benutzt

dsync -u username backup mdbox:
/var/backup/~/mdbox

bringt Dovecot dazu, alle Änderungen am zweiten Speicherort zu verwerfen. So lassen sich per Cronjob Backups der Postfächer in anderen Verzeichnissen oder per SSH-Tunnel auf einem Standby-Server mitführen.

Gleichzeitig sorgen eine übersichtliche Konfigurationssyntax und ein gut gepflegtes Dokumentationswiki dafür, dass sich der Administrator des Taubenschlags auch im unübersichtlichsten Luftkampf noch zurechtfindet. (mfe)