====== Migration von IMAP-Konten ====== Je nach invis-Server Setup können sich die beiden folgenden Szenarien ergeben: - **Beliebiger IMAP-Server zu Dovecot** - **Beliebiger IMAP-Server zu Kopano** In beiden Fällen erfolgt die Migration unter Verwendung des IMAP-Protokolls, lediglich das Migrationswerkzeug unterscheidet sich. ===== Beliebiger IMAP-Server zu Dovecot ===== 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: ^Umlaut^Code^ |ä| &AOQ-| |ö| &APY-| |ü| &APw-| |Ä| &AMQ-| |Ö| &ARN-| |Ü| &ANw-| |ß| &AN8-| 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. ===== Beliebiger IMAP-Server zu Kopano ===== 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.