Aus Linux-Magazin 01/2008

IMAP-Migration mit Imapmigrate, Imapsync und Offlineimap

Foto: Markus Feilner

Wenn Admins angerostete Mailserver austauschen, müssen auch die Postfächer der Benutzer auf die neue Hardware gelangen. Auf Ebene des Filesystems spielen die Server häufig nicht mit, deshalb erweisen sich IMAP-Migrationstools als ideale Helfer.

Irgendwann muss jeder E-Mail-Administrator direkt an die IMAP-Daten ran. Der Server, den er einst so liebevoll und über Jahre hinweg konzipiert, installiert, konfiguriert, verflucht und gepatcht hat, gehört früher oder später doch zum alten Eisen.

Sollen die IMAP-Dienste auf eine neue Maschine umziehen, müssen natürlich auch die Postfächer mitwandern. Spätestens dann, wenn im Zuge solcher Umstellungen auch noch Änderungen an den Mails oder Ordnern stattfinden sollen, wird es Zeit, nach den passenden Werkzeugen Ausschau zu halten.

Problem: E-Mail-Storage

So schön der IMAP-Standard an sich auch ist, die dahinter verborgene Server-Landschaft gestaltet sich kunterbunt, gerade wenn es um die Organisation der Daten geht. Auf der Ebene der implementierten Logik geben halt Systemarchitektur, Prozessorganisation und Funktionen der Serversoftware die Form der Applikation vor.

Den Administrator interessiert das in der Regel wenig, denn diese Uneinheitlichkeit steht der Verwaltung des Servers selten im Wege und wird ja eben durchs IMAP-Protokoll für die Clients wieder aufgelöst. Problematisch wird es erst, wenn er direkt auf die gespeicherten Daten zugreift, zum Beispiel bei einer Migration. Aber auch bei Backups oder Road-Warrior-Setups für mobile Geräte – die IMAP-Synchronisation steht immer wieder auf der Liste.

Auf den einschlägigen Mailinglisten ist bei diesem Stichwort schnell die Rede von Rsync ([1] und [2]). Zu Recht, denn das Werkzeug ist nicht nur vielseitig und verlässlich, es erlaubt während des Datentransports auch die Nutzung von SSH und bringt damit ein hohes Maß an Sicherheit. Das alles hilft aber nichts, wenn die Datenorganisation nicht mitspielt. E-Mails zu synchronisieren heißt in der Regel eben nicht nur, die E-Mail-Daten, also die Nachrichten selbst von A nach B abzugleichen, sondern es bedeutet ebenfalls, die Meta-Informationen wie den Status jeder einzelnen Nachricht (neu, gelesen, beantwortet, gelöscht, …) oder die umfangreichen ACLs zu erfassen und mitzuführen. Und genau an dieser Stelle beginnen sich Schmerzen in den Gesichtern vieler Administratoren abzuzeichnen.

IMAP-Datenabgleich mit Perl und Python

Von allen gebräuchlichen IMAP-Servern kodiert einzig der Courier-IMAP-Server den Status einer Nachricht im Dateinamen. Genau dies rechnen ihm Performance-orientierte Admins aber auch negativ an [3]. Andere, zum Beispiel Cyrus IMAP, Dovecot und Microsofts Exchange, führen eigene Indizes in Form von Datenbanken.

Das erhöht zwar die Performance, die Metadaten lassen sich in der Regel aber nicht auf File-Ebene kopieren, weil der Server sie im normalen Betrieb ja fast permanent benutzt. Den Mailserver für den nächsten Backup-Lauf mal schnell ausschalten, weil “die App dann die DB nicht mehr lockt”, ist auch keine Vorgehensweise, mit der ein Admin beim nächsten Mitarbeiter-Beurteilungsgespräch punktet. Werkzeugen wie Rsync sind an dieser Stelle damit klare und nachvollziehbare Grenzen gesetzt.

Schmerzärmer und eleganter ist es – an allen Datei- und Server-spezifischen Süppchen vorbei – auf Protokollebene anzusetzen und IMAP selbst für die Synchronisation zu nutzen. Server und Client übergeben die Daten als Kopie und tauschen dazu auch die Zugriffsberechtigungen und Status-Flags aus.

Dementsprechend arbeiten die drei getesteten Tools Imapsync [4], Imapmigrate [5] und Offlineimap [6] im Wesentlichen als IMAP-Clients, wobei aber erhebliche Unterschiede im Funktionsumfang bestehen. Weil die Programme mit ganz unterschiedlichen Zielsetzungen antreten, sei das auch gestattet. Und unabhängig davon, was sie sich auf die Fahnen geschrieben haben, bieten alle drei vollständige IMAP-Synchronisierung.

Imapsync und Imapmigrate basieren auf einer Perl-Library und nutzen das IMAP-Protokoll, um die Datenbestände ganzer Mailserver zu synchronisieren oder zu migrieren. Das Skript Offlineimap dagegen ist in Python implementiert und setzt sich zum Ziel, Programme ohne Offline-IMAP-Fähigkeiten mit eben solchen auszustatten. Unter den Offlineimap-Benutzern finden sich daher viele eingefleischte Mutt-User mit Laptops. Eher nebenbei bringt das Tool auch einige Funktionen mit, die Admins bei einer IMAP-Migration unterstützen.

Das ideale Migrationstool

Zeit zum Träumen: Welche Features sollte ein perfektes IMAP-Synchronisationswerkzeug überhaupt beherrschen?

Anmeldung und Authentifizierung: Am Anfang steht immer die Anmeldung am Server. Daten synchronisieren erfordert bei IMAP nahezu ausnahmslos zunächst ein Login, bevor der Zugriff auf die Daten selbst stattfindet. Dafür sollte das Skript mehrere Authentifizierungsmethoden beherrschen.

Automatisierung und Flexibilität: Ein brauchbares Skript muss mindestens ein Paar Authentifizierungsdaten mit Benutzernamen und Kennwort verwerten können. Noch besser wäre natürlich, wenn es zwei Paare einlesen und getrennt nutzen kann, um unterschiedliche Authentifizierungsdaten an den Quellserver und den Zielserver zu senden. Idealerweise nimmt das Skript derartige Daten aus einer Liste und automatisiert so die Server-Migration.

IMAP-Separatoren: In der Regel weisen das Quell- und das Zielsystem Unterschiede in der Ordnerstruktur und bei der Konfiguration des IMAP-Store auf. Ein Klassiker findet sich typischerweise in den unterschiedlichen Unterordner-Separatoren auf den Servern. Gebräuchlich sind hier vor allem »/« und ».«, manche Mailserver erlauben hier sogar freie Auswahl. Auch wenn es grundsätzlich keine von Weitblick geprägte Idee ist, den Separator zu ändern, könnte ein Admin diesen einmal begangenen Fehler mit einem geschickten Migrationstool wenigstens wieder ausbügeln. Dafür muss das ideale Programm aber unterschiedliche, am besten sogar beliebige Separatoren auf den zu synchronisierenden Servern beherrschen.

Verschlüsselung: TLS [7] ist unvermeidbar, auch wenn viele Admins ihren geliebten IMAP-Server im lokalen Netz “immer ohne Probleme” ohne die Verschlüsselung betreiben. Trotzdem: Transport Layer Security ist der am weitesten verbreiteten Standard, die Synchronisation könnte also scheitern, wenn der eine oder andere sicherheitsbewusste Server die Verschlüsselung um jeden Preis verlangt.

Ausschlussmechanismen: Das Tool muss über einen Mechanismus verfügen, der Ordner von der Synchronisation ausschließt. Das verhindert Ärger, beispielsweise wenn der angemeldete Nutzer nicht über die nötigen Zugriffsrechte für einen Mailordner verfügt, und spart Ressourcen, wenn bestimmte IMAP-Ordner wie Trash, Junk oder Spam nicht repliziert werden sollen.

Destination Rewrite: Richtig schick wird es, wenn ein Skript in der Lage ist, Mails aus Ordnerpfad A zu lesen und sie in Ordnerpfad B abzulegen. Derartiges Umschreiben des Speicherpfads ist eine gern genutzte Methode, um bei einer Migration den Usern auf dem neuen System zu zeigen, wo die alten Mails liegen. Auf diese Weise lassen sich ebenfalls unterschiedliche Systemmetaphern überbrücken, wenn zum Beispiel gleichzeitig mit der Migration die Mailclients wechseln und diese ihre Mail zukünftig nicht mehr in »Entwürfe«, sondern in »Drafts« zwischenspeichern wollen. Das gilt auch für »Gesendete Objekte« und »Sent« oder »Sent-Mail« und natürlich auch für »sent-mail«. Nirgends sind die Namenskonventionen systemübergreifend 1:1 anwend- oder umsetzbar. Der kleinste gemeinsame Nenner wäre das IMAP-RFC, aber das gibt keine Ordnernamen für diese Standardordner vor. Wie die Praxis zeigt, sind derartige Anpassungen fast immer notwendig.

Imapmigrate

Zu den Kandidaten: Imapmigrate ist ein Mitglied der schon etwas betagten Familie der Cyrus-Imapd-Utils [5], einer Sammlung von Werkzeugen rund um den Cyrus-IMAP-Server. Im Gegensatz zu den älteren, kaum noch gepflegten Geschwistern wie Saslpoppasswd, dem Quota Script, Imapcreate und Easysieve, die wohl allesamt auf dem Stand von 2001 stehen geblieben sind, zeigt Imapmigrates letzte öffentliche Release »imapmigrate-0.51« immerhin als Datum den 27.11.2004.

IMAP-Synchronisation nur für Cyrus

Im Test erweist es sich nicht gerade als das Tool, mit dem ein Admin allein auf einer Serverfarm eingesperrt sein will, aus der er nur wieder raus darf, wenn alle IMAP-Server migriert sind. Es gehört zwar auch nicht in die Kategorie “Es war so schlecht, dass ich es umschreiben musste, bevor ich es wegwarf”, aber die Beschreibung, es sollte “Mailboxen von jedem beliebigen IMAP-Server zu jedem anderen IMAP-Server” kopieren, ist gelinde gesagt übertrieben.

Hauptziel von Imapmigrate bleibt es eben doch, Daten von einem beliebigen IMAP-Server auf einen Cyrus-IMAP-Server zu migrieren, aber selbst die Entwickler bezeichnen den aktuellen Stand in den Release Notes als Alpha Code. Schön ist dagegen, dass Imapmigrate auf Wunsch für Quell- und Zielserver unterschiedliche Authentifizierungsdaten aus einer Datei einliest. Die Datensätze müssen dafür zeilenweise und nebeneinander durch Whitespaces getrennt sein. Steht nur ein Benutzername-Kennwort-Paar in einer Zeile, verwendet das Tool dieses für beide Server.

Probleme mit Trennzeichen für Unterordner

Das alles funktioniert mit Cyrus gut, auch in größeren Szenarien [8], scheitert aber spätestens dann, wenn der Zielserver als Unterordner-Separator kein »/« mag, denn das ist der einzige Dialekt, den Imapmigrate im Test sprechen wollte. Das Perl-Skript versucht zwar den »folder delimiter« zu erkennen, aber geklappt hat das im Test nur mit Cyrus IMAP. Imapmigrate erfüllt damit seine Zielvorgabe, scheitert aber als Server-unabhängiges Werkzeug. Die Fehlermeldungen zu verstehen, ist ebenfalls nicht jedermanns Sache. (Abbildung 1). Einer der Klassiker ist »NO Mailbox doesn\’t allow inferior mailboxes«. Alles klar?

Abbildung 1: Imapmigrate aus den Cyrus-Imapd-Tools leistet gute Dienste, solange nur der Cyrus-Server im Spiel ist. Mit einem Courier-IMAP-Server beispielsweise scheitern viele Aufrufe mit Fehlermeldungen.

Abbildung 1: Imapmigrate aus den Cyrus-Imapd-Tools leistet gute Dienste, solange nur der Cyrus-Server im Spiel ist. Mit einem Courier-IMAP-Server beispielsweise scheitern viele Aufrufe mit Fehlermeldungen.

Imapsync

Ganz anders hingegen Imapsync [4], das sein Autor Gilles Lamiral aktiv betreut. Die letzte Release ist gerade erst am 30. Oktober 2007 erschienen und hat einige Bugfixes mitgebracht. Als Grund, Imapsync zu schreiben, gibt Lamiral an, dass er einfach kein für seine Zwecke geeignetes Skript finden konnte.

Lamiral muss Großes vorgehabt haben, denn das Tool lässt so gut wie keinen Wunsch offen [9]. Das Umschreiben von Ordnern setzt es auf Basis vorgegebener Strings oder mit Regular Expressions um, es kann ACLs synchronisieren oder nur Ordnerstrukturen abgleichen, TLS verwenden und vieles mehr. Die Liste der Optionen scrollt schier endlos, wenn Imapsync ohne Parameter startet. Im Test funktionierten alle Optionen problemlos mit verschiedensten Servern (Abbildung 2).

Abbildung 2: Imapsync ist das Schweizer Taschenmesser für die IMAP-Migration. Zahlreiche Optionen lassen keinen Wunsch offen. Die Abbildung zeigt einen Umzug von Courier IMAP auf Dovecot.

Abbildung 2: Imapsync ist das Schweizer Taschenmesser für die IMAP-Migration. Zahlreiche Optionen lassen keinen Wunsch offen. Die Abbildung zeigt einen Umzug von Courier IMAP auf Dovecot.

Imapsync unterstützt heute laut Readme 34 IMAP-Server, dem stehen nur vier bekannte Probleme mit Exoten wie DBMail, Dkimap, Imail und Mailenable gegenüber. Ein echter Allrounder also. Darüber hinaus liegt der Unterschied zu Imapmigrate in der Arbeit und Sorgfalt, die in die Umsetzung geflossen ist, denn im Grunde beruhen beide auf demselben Perl-CPAN-Modul »Mail::IMAPClient«, das im Oktober 2007 gerade in Version 2.99.02 erschienen ist [10].

Mail::IMAPClient

Sehr zur Freude von Lamiral hat dieses Modul gerade den Maintainer gewechselt. Die letzten Bugfixes an Imapsync galten nämlich nicht mehr dem Skript selbst, sondern mussten Probleme des Perl-Moduls abfangen. Damit war Lamiral nicht allein, auch die Entwickler von Imapmigrate berichten von diversen Patches am CPAN-Modul und fehlenden Antworten vom Maintainer. Im Gespräch mit dem Linux-Magazin hofft Lamiral: “Das soll mit dem neuen Maintainer der Vergangenheit angehören.”

Wie bei jeder Software gibt es aber auch bei Imapsync Unzulänglichkeiten. Das Tool kann zum Beispiel Authentifizierungsdaten nicht automatisch einlesen, dafür ist ein Wrapper-Skript notwendig. Die Readme enthält die wohl einfachste Variante dafür in Form eines Bash-Einzeilers, der die Benutzerdaten aus einer CSV-Datei namens »file.csv« einliest.

Trotzdem erweist sich Imapsync bereits heute als zuverlässiges Werkzeug auch für größere Umzüge. Bei einer IMAP-Migration in einem größeren Rechenzentrum in Baden-Württemberg, wo etwas mehr als 15000 Mailkonten unterbrechungsfrei von einem altgedienten Exchange-Server auf einen neuen, performanteren und vor allem günstigeren Postfix-Dovecot-Performancecluster umziehen sollten, erwies sich allerdings die fehlende Protokollierung als ziemlich problematisch.

Alles außer Logging

Den Synchronisierungslauf von 15000 Mailkonten persönlich mitzuverfolgen und dabei Fehler bei der Migration zu erfassen, verstößt gegen die Genfer Konvention für Administratoren. Deshalb sollte das Wrapper-Skript, das ohnehin nötig war, um die Authentifizierungsdaten einzulesen und an Imapsync durchzureichen, auch die Aufgabe der Erfolgskontrolle wahrnehmen.

Das Skript liefert auch brav nach jedem Aufruf einen Exit-Status zurück. Admins erweiterten den Wrapper deshalb um die Prüfung des Status und die Ausgabe von Log-Meldungen. Das Ergebnis des ersten Testlaufs war jedoch enttäuschend. Der Exit-Status gab einfach in allen Fällen »1«, also “gescheitert”, zurück.

Eine Telnet-Session mit dem Exchange-Server offenbarte das Problem: Auf dem Server existierte ein Ordner, den alle User zwar sehen konnten, aber nicht lesen durften. Darüber stolperte Imapsync. Beim nächsten Aufruf klammerte die Imapsync-Option »–exclude« diesen Shared Folder namens »Öffentliche Ordner« von der Synchronisierung aus, und schon lief der Testlauf ohne Unterbrechung 27 Stunden durch und wurde damit bereits zur ersten vollständigen Synchronisierung.

Im darauf folgenden Schritt werteten die Admins das Log aus und kümmerten sich um die verbleibenden Fehler, in der Regel handelte es sich um fehlgeschlagene Logins aufgrund falscher Kennwörter. Acht Stunden später waren der zweite Synchronisierungslauf beendet und das mittlerweile entstandene Delta abgeglichen.

Das Team wiederholte die Delta-Synchronisierungen noch einige Male und schaltete das Exchange-System kurz darauf nachts unbemerkt um. Alle Versuche, den Zeitbedarf für die Synchronisationsläufe weiter zu verkürzen, indem beispielsweise mehrere Instanzen des Skripts gleichzeitig liefen, waren dagegen erfolglos. Als Engpass erwies sich das Altsystem, das schon nicht mehr in der Lage war, einen einzelnen Imapsync-Client auszulasten.

Generell sind 27 Stunden bei dieser hohen Anzahl von Mailboxen ein überraschend guter Wert, Synchronisierungsläufe dieser Größenordnung können durchaus auch mal mehrere Tage dauern. Im vorliegenden Fall verkürzt sich die Zeit dadurch, dass viele User ihre Mails auf dem alten Server eher mit POP als mit IMAP abholten und die Mailboxen deshalb nicht übermäßig viele zu migrierende Daten enthielten.

Offlineimap

Ein ganz anderes Ziel hat sich Offlineimap [3] gesetzt. Nicht der unterbrechungsfreie Wechsel des Servers im Rahmen einer Migration steht im Vordergrund, Offlineimap will Usern einen lokalen IMAP-Cache ermöglichen, deren Mailprogramme den dafür vorgesehenen Offline-IMAP-Modus nicht beherrschen. Ein guter Kandidat dafür ist der Befehlszeilenmailer Mutt mit seiner großen Fangemeinde.

Offlineimaps Ansatz ist also etwas anders: Es greift mit den Zugangsdaten eines Users auf dessen Mailbox zu und schreibt die Daten lokal in ein Maildir-Mailboxtyp-Verzeichnissystem.

Das Tool ist in Python geschrieben und dementsprechend schnell installiert. Standardmäßig liest es seine Konfiguration über die Datei »~/.offlineimaprc« ein. Diese ist, dank mitgelieferter Beispiele, schnell erstellt und gut dokumentiert. Listing 1 zeigt eine sinnvolle Beispielkonfiguration.

Listing 1:
».offlineimaprc«

01 [general]
02 accounts = Test
03 
04 [Account Test]
05 localrepository = Local
06 remoterepository = Remote
07 
08 [Repository Local]
09 type = Maildir
10 localfolders = ~/Test
11 
12 [Repository Remote]
13 type = IMAP
14 remotehost = mail.example.com
15 remoteuser = john
16 remotepass = postel
17 
18 [mbnames]
19 enabled = yes
20 filename = ~/Mutt/muttrc.mailboxes
21 header = "mailboxes "
22 peritem = "+%(accountname)s.%(foldername)s"
23 sep = " "
24 footer = "n"

Wie immer nimmt je nach Größe der Mailbox der erste Synchronisationslauf einige Zeit in Anspruch, aber schon beim zweiten Mal schrumpft auch hier die Gesamtdauer auf ein erträgliches Maß. Noch angenehmer wird es, wenn der Abgleich per Aufruf als Cronjob oder mit der Option »autorefresh=5« in »~/.offlineimaprc« alle paar Minuten automatisch im Hintergrund startet. Für mobile Nutzer empfiehlt sich die Integration in geeignete If-up-Skripte. Native Windows-Clients, die Maildir direkt lesen können, scheinen übrigens nicht zu existieren.

Trotz der unterschiedlichen Zielsetzung sprechen einige Fähigkeiten von Offlineimap auch für seine Eignung als Migrationstool:

  • Offlineimap synchronisiert mehrere Mailboxen gleichzeitig.
  • Nach getaner Arbeit bietet es an, eine Liste dieser Mailboxen
    samt ihren Unterordnern zu generieren und als Datei abzulegen.
  • Format-Optionen gestalten diese Liste so, dass Mutt sie als
    Mailbox-Liste einliest und verwendet.
  • Offlineimap leitet auf Wunsch Mails während der
    Synchronisierung durch externe Programme.
  • Während des Abgleichs vermag Offlineimap Ordner
    umzubenennen.
  • Der Benutzer spezifiziert Filter für Ordnernamen. Nur jene
    Folder, auf die der Filter zutrifft, werden dann abgeglichen.

Mit Offlineimap kann ein Admin on the fly und gezielt einzelne Mails und Ordner bearbeiten, verändern und beliebige Inhalte umschreiben.

Standardmäßig bietet Offlineimap eine auskunftsfreudige Oberfläche (Abbildung 3), die deutlich zeigt, woran das Programm gerade arbeitet. Wer Vertrauen in die Zuverlässigkeit des Programms gefasst hat, schätzt es aber bestimmt weniger ausführlich. Dann betreibt er Offlineimap mit dem Kommandozeilen-Parameter »-u« und der Option »Noninteractive.Quiet«. Es rattert kurz auf der Platte und dann ist Ruhe.

Abbildung 3: Obwohl eigentlich nicht für die IMAP-Migration entwickelt, leistet Offlineimap dank einiger Features aber auch dabei gute Dienste. Die Oberfläche ist klar und ausführlich, ein Quiet-Modus verfügbar.

Abbildung 3: Obwohl eigentlich nicht für die IMAP-Migration entwickelt, leistet Offlineimap dank einiger Features aber auch dabei gute Dienste. Die Oberfläche ist klar und ausführlich, ein Quiet-Modus verfügbar.

Migration in drei Zügen

Trägt der Admin in der Datei »~/.offlineimaprc« sowohl im Abschnitt »[Repository Local]« als auch in »[Repository Remote]« einen IMAP-Server ein, dann synchronisiert Offlineimap die angegebenen Accounts auf den beiden Maschinen. Vorher sollte er aber auf jeden Fall das lokale Verzeichnis » ~/.offlineimap« löschen, damit das Tool keine fehlerhaften Statusinformationen verwendet.

Auch dieses Setup war ursprünglich gar nicht für die Migration eines IMAP-Servers gedacht, sondern folgt einem anderen Ansatz: Mit einem lokalen Maildir-Storage arbeiten die meisten Mailclients eher langsam und zäh, es dauert vergleichsweise lange, bis die Nachrichten auf der Anzeige erscheinen. Ein IMAP-Server auf dem Client, der sich mit dem primären Server synchronisiert, ist da deutlich schneller.

Leider unterstützt Offlineimap in diesem Szenario noch nicht alle Funktionen. Unter anderem fällt die Option »Folderfilter« weg, mit deren Hilfe der User die Mailordner auswählt, die er abgleichen möchte. Das Gleiche gilt für das Rewrite von Namen der E-Mail-Ordner. Doch auf einem Umweg kann der Admin auch diese Funktionen bei einer Migration nutzen, er braucht dafür aber einen Schritt mehr als die anderen Tools und eventuell einen Rechner mehr.

Im ersten Schritt synchronisiert er den Mailstore in einem lokalen Verzeichnis mit den Inhalten des IMAP-Servers. Hier stehen ihm die umfangreichen Möglichkeiten zur Verfügung, die Offlineimap mitbringt. Im zweiten Schritt synchronisiert er den lokalen Store mit dem zweiten IMAP-Server. Vorher muss er aber unbedingt »~/.offlineimap« löschen, sonst ist nachher einfach das lokale Maildir leer, weil Offlineimap konsequent den leeren Account vom Server heruntersynchronisiert hat. Ein wenig Testen ist hier sicherlich hilfreich.

Fazit: Reif für die Insel

Soll auf der Liste jener Dinge, die ein Admin auf eine einsame Insel mitnehmen möchte, auch ein IMAP-Synchronisierungstool stehen, dann taucht Imapsync sicher ganz oben auf. Es ist einfach das Schweizer Taschenmesser unter seinesgleichen, unterstützt fast jeden beliebigen IMAP-Server und bietet viel mehr Optionen, als in den meisten Migrationen gebraucht werden.

Die wenigen Unzulänglichkeiten gleicht der Admin mit etwas Shell-Know-how aus. Für Fälle, in denen ein Cyrus-Server zum Einsatz kommt, greifen schmerzunempfindliche Administratoren wohl eher auf Imapmigrate zurück. Aber wenn die Mails während der Migration überarbeitet werden sollen und die Rechtsabteilung genau dagegen überraschend kein Veto einlegt, dann ist Offlineimap die richtige Wahl.

Für jeden ist also etwas dabei. Alle drei Tools haben übrigens eines gemeinsam: Sie laufen auf allen Maschinen, auf denen Perl beziehungsweise Python eingerichtet ist. Windows-Admins brauchen allerdings zusätzlich die Cygwin-Tools, weil das MS-Standarddateisystem nicht alle Eigenschaften des Maildir-Formats abbilden kann.

Infos

[1] Hans-Georg Eßer und Heike Jurzik, “Garantiert gleich”: Linux-Magazin 08/07, S. 42

[2] Achim Leitner, “Recycling-Meister”: Linux-Magazin 08/07, S. 46

[3] Patrick Ben Koetter, “Auf der Teststrecke”: Linux-Magazin 06/07, S. 36

[4] Imapsync: [http://www.linux-france.org/prj/imapsync]

[5] Cyrus-Imapd-Utils mit Imapmigrate: [http://sourceforge.net/projects/cyrus-utils]

[6] Offlineimap: [http://software.complete.org/offlineimap]

[7] Wikipedia zu TLS: [http://de.wikipedia.org/wiki/Transport_Layer_Security]

[8] Jack Chongjie Xue und Markus Feilner, “Unterbrechungsfreie E-Mail-Migration”: Linux Technical Review 04, “High Availability”, S. 130

[9] Charly Kühnast, “Umzugshelfer”: Linux-Magazin 10/04, S. 69

[10]Perl-CPAN-Modul Mail::IMAPClient:[http://search.cpan.org/~markov/Mail-IMAPClient-2.99_02]

Der Autor


Patrick Ben Koetter ist Gründer von State of Mind [http://www.state-of-mind.de], Experte für Mailserver und Co-Autor des Buches “Postfix – Einrichtung, Betrieb und Wartung”. Er spricht regelmäßig auf Konferenzen im In- und Ausland über die Themen Dovecot, Postfix, Cyrus SASL und Spam-Bekämpfung und gibt sein Wissen im Linuxhotel weiter.

DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 5 HeftseitenPreis €0,99
(inkl. 19% MwSt.)
LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
0 Kommentare
Älteste
Neuste Beste Bewertung
Inline Feedbacks
Alle Kommentare anzeigen
Nach oben