Migration von IMAP-Konten

Je nach invis-Server Setup können sich die beiden folgenden Szenarien ergeben:

1. Beliebiger IMAP-Server zu Dovecot
2. Beliebiger IMAP-Server zu Kopano

In beiden Fällen erfolgt die Migration unter Verwendung des IMAP-Protokolls, lediglich das Migrationswerkzeug unterscheidet sich.

In diesem Fall ist die Software offlineimap das Mittel der Wahl, es ist in vermutlich jeder Linux-Distribution enthalten.

offlineimap benötigt eine Konfigurationsdatei namens

.offlineimaprc

. Diese muss im Home-Verzeichnis des Users angelegt werden, der die Migration durchführt. In aller Regel dürfte dies der Benutzer root sein. Hier ein Beispiel:

[general]
accounts = privat
maxsyncaccounts = 1
[Account privat]
remoterepository = Quelle
localrepository = Ziel
[Repository Quelle]
type = IMAP
remotehost = localhost
remoteuser = heinzb
remotepass = password
ssl = no
maxconnections = 1
readonly = true

[Repository Ziel]
type = IMAP
remotehost = 192.168.42.10
remoteuser = heinzb
remotepass = p@ssw0rd
ssl = no
maxconnections = 1

Gegebenenfalls müssen zwischen Quelle und Ziel Übersetzungen von Ordnernamen stattfinden. Weiterhin können sich die IMAP-Namensräume sowie die unterstützten Zeichensätze beider IMAP-server voneinander unterscheiden. Nachfolgend ein altes Beispiel einer Übersetzungskonfiguration, die Notwendig war um von einem Dovecot-IMAP-Server hin zu einem (alten) Zarafa Server zu migrieren:

...
nametrans = lambda foldername: re.sub('^INBOX.Sent$' ,'Gesendete Objekte',
        re.sub('^INBOX.Trash$' ,'Gel&APY-schte Objekte',
        re.sub('^INBOX.Drafts$', 'Entw&APw-rfe',
        re.sub('^INBOX.Junk$', 'Junk E-Mail',
        foldername))))
...

Eingefügt war die Direktive nametrans in der Konfiguration des Quell-Servers.

Erläuterung

Zarafa, wie auch Kopano verwendet lokalisierte Ordnernamen in der Sprache des jeweiligen Postfachs. Weiterhin unterstützte Zarafa kein UTF-8. Innerhalb des IMAP-Setups auf Dovecot-Seite wurden die Standard-Ordner für Entfürfe, Spam und der Papierkorb als Unterordner der Inbox geführt und der Verzeichnistrenner des IMAP-Namensraums ist der Punkt. Auf Zarafa-Seite hingegen liegen die genannten Standardordner parallel zur Inbox auf der gleichen Verzeichnisebene. Alle genannten Unterschiede werden mit der nametrans Direktive übersetzt.

Letztlich werden ein paar Synchronisationsversuche notwendig sein, bis es reibungslos läuft. Im Idealfall ist keine Übersetzung erforderlich.

Hier noch eine Übersetzungstabelle:

Auf Quellseite muss die Direktive:

readonly = true

gesetzt werden, da offlineimap ansonsten eine bidirektionale Synchronisation durchführt.

Es kann nicht schaden, vor der Synchronisation leere IMAP-Ordner zu entfernen. Im Falle von „Maildirs“ auf der Quell-Seite kann das einfach im Dateimanager erfolgen. Im Falle von Cyrus ist ein angeschlossener Mail-Client zum Aufräumen erforderlich.

Gestartet wird die Synchronisation einfach durch den Aufruf des Kommandos oflineimap ohne weitere Optionen und Parameter. offlineimap führt Buch über die Synchronisation und ist daher in der Lage auch unterbrochene Synchronisationen wieder aufzunehmen.

Soll die Synchronisation im Hintergrund ablaufen, können Sie das mit dem Kommando nohup erreichen:

invis:~ # nohup offlineimap &

Ziel der Buchführung ist ein Verzeichnis unter dem Namcen

.offlineimap

welches direkt im Home-Verzeichnis des Users angelegt wird, der die Synchronisation durchführt.

Es ist möglich in einem Durchlauf gleich eine Reihe von Postfächern zu synchronisieren. Wenn Sie (so wie ich) lieber Schritt für Schritt vorgehen, empfiehlt es sich nach jeder Synchronisation das Kontrollverzeichnis umzubenennen.

Kopano bringt mit kopano-migration-imap ein eigenes Migrationswerkzeug mit.

invis:~ # nohup kopano-migration-imap  --automap --host1 mailserver212.example.de --tls1 --user1 info@ffirma.org --password1 supergeheim --delete --host2 localhost --tls2 --user2 info --password2 'p@$$w0rd' --logfile ./info-migration.log &

Die Option delete sorgt dafür, dass alle erfolgreich migrierten Mails auf dem Quellserver gelöscht werden. Sie sollte erst gesetzt werden, wenn der eine oder andere Migrationstest erfolgreich verlaufen ist.

Etwas komplizierter wird es, wenn die automap Option nicht genügt um die Namen der Quell-Ordner den Namen der Zielordner zuzuordnen. Dafür kennt kopano-migrate-imap unter anderem die Option f1f2, die in einer Befehlszeile mehrfach vorkommen darf:

invis:~ # kopano-migration-imap  --automap --f1f2 "INBOX.Papierkorb"="Gel&APY-schte Objekte" --f1f2 "INBOX.Ausgang"="Gesendete Objekte" --f1f2 "INBOX.Entwurf"="Entw&APw-rfe" --host1 host1.mailserver212.example.de --tls1 --user1 user1 --password1 'supergeheim' --host2 localhost --user2 hbecker --password2 'p@$$w0rd' --logfile ./hbecker-migration.log

Im Beispiel zu sehen ist einerseits das Inbox-Unterordner der Quellseite, in Stammordner der Zielseite übersetzt werden und, dass Umlaute nicht als solche geschrieben werden dürfen. Übersetzungstabelle siehe oben.

Sollen nur einzelne Mailordner synchronisiert werden, ist dies auch möglich:

invis:~ # kopano-migration-imap --folder HE-Reports --host1 host1.mailserver212.example.de --tls1 --user1 username --password1 'supergeheim' --host2 localhost --user2 hbecker --password2 'superheinz' --logfile ./hbecker-folder-migration.log

Das Kopano IMAP-Migrationswerkzeug kennt noch einige recht nützliche Optionen:

• addheader - Fügt zu migrierenden Mails einen intakten Mailheader hinzu, so deren Header so unvollständig oder „bad“ (also kaputt) ist, dass dieser eine Migration der Mail verhindern würde.
• skipemptyfolder - Schließt leere Mailordner auf der Quellseite von der Migration aus.
• f1f2 - Wie bereits erwähnt lassen sich damit Ordnernamen auf der Quellseite in Ordnernamen auf der Zielseite übersetzen. Diese Option kann beliebig oft in einer Befehlszeile verwendet werden.
• delete - Löscht erfolgreich migrierte Mails auf der Quellseite. Der Verwendung dieser Option sollten ein paar erfolgreiche Migrationstests voraus gehen. Speiziell, wenn Mails von einem externen IMAP-Server auf einen invis-Server migriert werden sollen, ist diese Option unabdingbar. Ohne delete würde ein im Anschluß an die Migration aktiviertes Fetchmail zumindest die Mails aus der Inbox erneut abrufen. D.h. der Posteingang wäre voll mit doppelten Mails.