Migration IMAP2IMAP

Umzüge von Postfächern sind irgendwie immer wieder gefordert. Zwischen Exchange Servern und zur Cloud geht das alles ganz einfach mit Bordmitteln aber wenn Sie zwischen Providern oder Fremdsystemen einen Umzug planen, und sei es nur der kleine Domain-Umzug von einem Provider zu einem anderen, lassen Sie die meisten Provider im Stich oder wollen Geld dafür. Dumm nur, wenn der abgebende Provider mit dem Umzug der Domain auch das Postfach löscht aber der neue Provider das Postfach erst nach der Freischaltung der Domain bereitstellt. Dann müssen die Mails "irgendwo" zwischengelagert werden.

Firmen wünschen sich natürlich eine serverseitige Migration, die ein Admin kontrollieren und steuern kann. Privatanwender suchen dann eher eine Freeware für ihr Postfach. In der Zwickmühle sind Familien, wenn Papa oder Mama die Domain umziehen und die Postfächer der Kinder, Großeltern u.a. berücksichtigen müssen. Dabei dürfen Sie natürlich auch keine Adresse vergessen, die weitergeleitet wird.

Domainumzug und MX-Record

Wenn Sie ihre DNS-Domäne mit den Postfächern zu einem anderen Mailserver oder Provider umziehen, dann gibt es eine knifflige Situation: Im Internet finden die anderen Absender ihr Postfach per DNS-Anfrage nach dem "MX-Record". Leider ist DNS nicht "Echtzeit" und nicht sofort sondern hat einen mehr oder minder lange gültigen Cache Es kann und wird also passieren, dass sie den MX-Eintrag auf den neuen Provider umstellen, aber immer noch an den alten Provider laufen. Wenn der dann keine Weiterleitung anbietet oder das Postfach "deprovisioniert" ist, dann sind die Mails unzustellbar.

Sie können diese Zeit bei einer geplanten Umstellung durch eine frühzeitige Reduzierung des "Time to Live (TTL)" reduzieren. Das gleiche vorgehen gilt übrigens auch für die A-Records ihrer Webseite, wenn Sie diese gleich mit umziehen. Allerdings muss der abgebende Provider dann auch zulassen, dass Sie an diesem Parameter rumdrehen.

Es ist also generell interessant, wie ein abgebender Provider mit einer Mailbox verfährt, deren Domain übertragen wird oder vor kurzen übertragen wurde. Einige Provider lassen die Mailbox durchaus noch einige Zeit bestehen, bis die DNS-Server und Mail-Server der Welt gelernt haben, das es neue Server gibt. Der DNS-Umzug ist technisch ja losgelöst von der Mailbox zu betrachten. Da aber die "Mail-Adresse" oftmals auch der Anmeldename ist, kann eine spätere Anmeldung erschwert oder blockiert sein. Der abgebende Provider ist ja nicht mehr "zuständig". Auf der andren Seite schaltet der aufnehmende Provider den Empfang für eine Domain erst dann frei, wenn er auch die DNS-Delegierung bekommen hat.

Prüfen Sie vielleicht, ob sie die Domain eines Postfachs temporär auf eine andere Domain ändern können, die ihnen noch verbleibt. so könnten die Mails noch erhalten bleiben, auch wenn der Empfang vermutlich unterbunden ist. Eine "Weiterleitung" wie es die klassische Briefpost anbietet, habe ich bislang bei keinem anderen Provider gesehen. Technisch wäre es aber auch nicht einfach, wenn eine Mail, die noch an den alten Provider gesendet wird, von diesem dann zum neuen Provider weitergeleitet wird. Das kann schon ein SPF-Eintrag des Absenders den Versuch verteilen, dass der alte Provider die Mail sendet.

Cutover zu Beginn - Copy/Move

Der Idealfall ist, dass das Postfach auf der alten Seiten noch mindestens einige Tage bestehen bleibt und auch Mails annimmt, während das neue Postfach im Ziel schon vorhanden ist. Sie haben in dem Moment aber zwei Postfächer und je nach Absender und MX-Record können auch in beide Postfächer neue Mails ankommen. In dem Fall wäre ein Programm oder ein Prozess ideal, der alle Elemente aus der Quelle in das Ziel kopiert und später in der Quelle eintreffende Mails immer wieder nachholt. Die Elemente könnten dabei in der Quelle auch gelöscht werden, da der Anwender mit dem neuen Zielpostfach arbeitet.

Die vier Schritte im Detail:

  1. Start
    Der Anwender nutzt sein bisheriges Postfach und neue Mails landen per MX-Record auch dort drin
  2. Cutover am Beginn
    Sobald das neue Postfach bereitgestellt wurde, nutzt er einfach das neue Postfach. Es ist anfangs noch leer, bis der "Copy-Process" im Hintergrund alle Mails in das neue Postfach übertragen hat.
    Wenn man den Anwender informiert, könnte man auch schon vorab alle Inhalte einmal kopieren. Es besteht aber das Risiko, dass dann der Anwender mit dem Umstieg wieder alte Mails sieht, die er danach in der Quelle verarbeitet hat. Nur ein "richtiger Sync" von der Quelle zum Ziel könnte das entschärfen.
  3. Koexistenz
    Solange der neue MX-Record noch nicht überall bekannt ist, kommen neue Mails schon im neuen System aber auch im alten System an. Der Copy-Prozess muss also "nachmigrieren". Die Zustellung neuer Mails kann sich etwas verzögern. Eine Umleitung ist nicht ratsam, da die Quell wegen SPF und Spamfilter in der Regel nicht als Vertrauenswürdig für die Absender beim Zielpostfach zählt. Eine Umleitung kann aber sinnvoll sein, wenn die Mail von anderen Kollegen in der Quelle selbst kommen.
  4. MX-Änderung abgeschlossen
    Irgendwann hat auch der letzte Mailserver verstanden, das die Mails nicht mehr an das alte System kommen. Damit ändert sich nichts mehr und der "Copy/Move"-Job hat nichts mehr zu tun.

Der große Vorteil bei dieser Methode besteht darin, dass der Anwender in der Quelle selbst nichts mehr ändert und daher der Copy/Move die Elemente ins Ziel übertragen und der Quelle löschen kann. Der Nachteil besteht natürlich darin, dass der Anwender beim frühen Zugriff noch nicht alle Mails vorliegen hat. Das gilt insbesondere bei vielen Anwendern im Batch. Einige Werkzeuge kaschieren diesen Nachteil, indem z.B. vorab schon sehr alte Mails übertragen werden und nach dem Schwenk zuerst die letzten Tage aller Postfächer übertragen werden. Die meisten Anwender merken es maximal an der "Anzahl der Mails" und unvollständigen Suchergebnissen, dass noch nicht alles da ist.

Cutover nach der Umstellung - Replikation

Etwas anders sieht es aus, wenn der Anwender möglichst lange noch an der Quelle arbeitet und Sie im Ziel die Datenmenge erst einmal aufbauen wollen. Das ist durchaus gewünscht, um die Qualität der Migration prüfen zu können und die Datenmenge nicht in kurzer Zeit übertragen werden müssen. Das größere Problem dabei ist, dass die Anwender weiter in der Quelle arbeiten und Mails lesen, einsortieren, löschen etc. Der Migrationsprozess sollte diese Fälle erkennen und nachhalten. Ansonsten wird ein umbenannter Ordner erneut kopiert und ist im Ziel dann doppelt. Auch in der Quelle gelöschte Elemente würde der Anwender im Ziel dann wieder finden.

Auch hier wieder die einzelnen Schritte:

  1. Start unverändert
    Der Anwender nutzt sein bisheriges Postfach und neue Mails landen per MX-Record auch dort drin
  2. Synchronisation
    Während der Anwender weiter auf dem Quellpostfach arbeitet, werden alle Elemente im Hintergrund schon in das Ziel übertragen. Der Anwender merkt davon nicht
  3. MX-Record anpassung
    Wenn die Umstellung ansteht, dann werden sowohl MX-Record als auch Anwender auf die neue Umgebung umgestellt. Der Anwender kann weiter arbeiten und bekommt sehr bald auch neue Mails. Es können aber immer noch einige Mails in der Quelle eingehen. Daher sind auch hier weitere Sync-Läufe wichtig, um diese Mails noch zu übertragen. Der Sync darf nun natürlich die neuen Mails im Ziel nicht entfernen, nur weil diese in der Quelle nicht mehr angekommen sind.
  4. Alte Postfach entfällt
    Wenn alle Mailserver der Welt den alten Server "vergessen" haben und die Sync-Läufe alle Änderungen nachgezogen haben, kann das alte Postfach entfernt werden

Diese Lösung ist aufwändiger, da insbesondere die Synchronisation nicht immer einfache und fehlerfrei ist. Allerdings können Sie schon vor der ersten Umstellung vielleicht 99% aller Mails ins Ziel übertragen und die Qualitt prüfen. Das Restrisiko sind also nur Mails, die nach dem Switch noch in der Quelle ankommen und ins Ziel übertragen werden müssen.

Client Export/Import

Leider hat man nicht immer die Möglichkeit, zwei Postfächer parallel nebeneinander zu betreiben. Gerade im Consumer-Bereich mit klassischen Webhostern wird beim Umzug einer Domain von einem Hoster zum anderen das neue Postfach erst eingerichtet wenn die Domain angekommen ist und in der Quelle sehr schnell gelöscht oder zumindest "unerreichbar" geschaltet. Für solche Szenarien müssen Sie sich einen temporären Speicher suchen.

Auch hier der Ablauf in vier Schritten

  1. Start
    Sie empfangen ihre Mails per MX-Record in das Quell-Postfach. Sofern Sie den TTL des MX-Records beeinflussen können, sollten sie ihn so klein wie möglich (z.B. 60 Sekunden) setzen.
  2. Export
    Ehe Sie die Domain umstellen und damit das Quellpostfach verlieren, müssen Sie die Inhalte irgendwo sicher auslagern. Dazu gibt es mehrere Wege. Die meisten IMAP4-Progammer erlauben eine "Offline Verfügbarkeit" samt Replikation, was quasi ein Backup ist. Sie können die Mails aber auch in lokale Order (Thunderbird) oder mit Outlook in eine PST-Datei kopieren. Es gibt noch viele weitere Tools, die einen Export/Import per IMAP4 in verschiedene Zielformate versprechen. Der Export sollte nur sehr kurz vor dem Ende passieren. Wenn Sie den TTL des MX-Records reduziert haben, können sie vielleicht den MX-Record nun noch schnell auf eine IP-Adresse lenken, die grade keine Mails annimmt, damit niemand noch Mails an den alten Provider senden. Sie könnten dann noch mal einen "Delta Export" machen, damit wie wirklich alle Mails haben.
  3. Domainumzug
    Nun heißt es schnell sein, denn bei einer "de-Domain" holen Sie sich beim aktuellen Provider einen "Authentication-Code", mit dem Sie die Domain beim neuen Zielprovider aktivieren können. In der Regel nimmt der alte Provider die DNS-Einträge schnell weg und der neue Provider ändert die Delegation beim DeNIC. Das kann bis zu 48 Stunden dauern. In der Zeit kommen immer mehr Mails im neuen System an und mit etwas Glück, lehnt das alte System die Mail mit einem temporären Fehler ab, so dass die Absender keinen NDR erzeugen sondern es weiter versuchen.
    Sie sollten aber beim neuen Provider sehr schnell die Postfächer wieder anlegen, damit die Mails auch zugestellt werden.
  4. Client Umstellung
    In der Zwischenzeit können Sie schon den Mailclients die neuen Zugangsdaten geben, so dass die Anwender sich mit dem Postfach verbinden und zumindest die einkommenden neue Mails lesen. Als Admin oder Anwender können Sie nun auch schon dazu übergehen, die "gesicherten" Mails in das Postfach einzuspielen.

Der Umzug einer Domain von einem Provider zum anderen Provider sieht erst einmal einfach aus, aber bei E-Mail kann es ganz schön knifflig sein. Die meisten Administratoren denken erst einmal an die Webserver. Da ist ja klar, dass man auf dem neuen Provider erst einmal die Webseite bereitstellt, damit nach dem Umzug die Inhalte da sind. Aber selbst da muss man sich über eine "Frozen Zone" Gedanken machen, z.B.: dass niemand mehr Inhalte "ändert". Das sind nicht nur Seiten in Wordpress sondern z.B. auch Kommentare und je umfangreicher die Webseite mit Datenbanken verbunden ist, desto aufwändiger wird so ein Umzug.

Einzelmigration mit lokaler Software

Wenn sie im Bereich der Familie eine Domain mit ein paar Postfächern umziehen wollen, dann ist es vermutlich am einfachsten, die Mail auf die lokale Festplatte zu sicher, Ich würde dazu einen der drei Optionen nutzen

  • Outlook
    Wenn Sie heute schon Outlook nutzen, dann exportieren Sie einfach alle Elemente über die Export-Funktion in eine PST-Datei
  • Thunderbird
    Hier können Sie einen "Lokalen Ordner" anlegen und dann alle Elemente aus ihrem Postfach in diesem Ordner "kopieren". Denkbar wäre auch ein IMAP4-Offline-Betrieb. Wenn Sie nach dem Umzug dann aber kein neues Profil einrichten sondern das bestehende Profil ändern, könnte Der Mailclients die lokalen Kopien "löschen", da sie auf dem Server mit dem neuen leeren Postfach ja nicht mehr vorhanden sind.
  • Mailstore
    Ein Sonderfall ist die Archivfunktion des Herstellers "Mailstore". der für Home User bis zu drei Postfächer auch per IMAP "archivieren" kann.

Bei allen drei Optionen sollten Sie überlegen, ob sie die Elemente einfach nur kopieren oder sogar "verschieben". Beim Verschieben wird das Postfach beim Provider mit geleert und sie sehen viel schneller, ob dort noch neue Mails einlaufen. Auf der anderen Seite sollten Sie dann die lokal Kopie gut bewachen, denn wenn dann was kuputt geht, ist das Postfach leer. Auch ihre mobilen Geräte haben dank "Synchronisation" ja keine Mails mehr.

Firmenmigration mit lokaler Software

Wenn Sie aber Administrator einer Firma sind und mehrere Postfächer migrieren wollen, dann taugen Client-Lösungen nur bedingt.

Für die Migration von Mails per IMAP4 zu Exchange Online gibt es von Microsoft fertig Lösungen
Siehe z.B. https://docs.microsoft.com/en-us/exchange/mailbox-migration/migrating-imap-mailboxes/migrating-imap-mailboxes

Wenn Sie aber "IMAP zu IMAP" migrieren, dann könnten Sie auch zwischen vielen Produkten auswählen. Eine Empfehlung kann man hier schlecht geben, denn es gibt einige kostenfreie oder sehr günstige Skripte aber auch GUI-gesteuerte Tools zur lokalen Installation. Einige Hersteller bieten die Software auch "gehostet" an. Ein Sondefall ist eine "Assisted Migration", bei der die Migration auch durch Mitarbeiter des Herstellers aktiv durchgeführt wird

Sie sehen hier mehrere "Tools", die keine klassische kommerzielle Programme sind. Anscheinend gibt es viele Programmierer, die mit der Leistung ihres Firmenservers nicht zufrieden waren und daher einen Abgleich zu einem anderen Server programmiert haben. Sie sollten das ein oder andere Tool probieren und die Funktion testen. Zum Glück ist eine Migration ja kein "Dauerzustand" sondern nur eine relativ kurze Zeit.

Migration per Cloud

Nun könnten Sie sich überlegen, warum Sie die Mails erst über das Internet und ihre eigene Leitung herunterladen und später zu einem anderen Provider wieder hochladen sollten. Die Frage ist berechtigt und natürlich gibt es Dienste, die einen serverseitige Umzug versprechen. Durch das Prinzip bedingt können Sie sogar schneller kopieren und Synchronisieren, da Sie natürlich auch "in der Cloud" laufen. Allerdings müssen sie dran denken:

  • Quelle und Ziel muss aktiv sind
    Das Verfahren ist nur tauglich, wenn beide Systeme aus der Internet erreichbar sind und zumindest für eine gewisse Zeit parallel existieren.
  • Credentials beim Hoster
    Ein gewisses Vertrauen müssen Sie schon aufbringen, wenn Sie so einem Dienstleister die Benutzernamen und Kennwort für den Zugriff auf das Quell- und Zielpostfach aushändigen, damit er migrieren kann
  • Kostenpflichtig
    Vor dem Hintergrund ist ein "Vertrag" natürlich ratsam, der Rechte und Pflichten regelt.

Die meisten Anbieter unterstützen dann aber auch mehr als "nur IMAP4", sondern haben auch entsprechende Schnittstellen zu Exchange, Office 365, Notes, Outlook.com ,G-Mail und andere Mailserver. Meist bewegen sich die Kosten im Bereich von 5-10 €/Postfach. Die meisten Produkte machen natürlich erst einmal Werbung mit einer Migration zu Office 365. Zwar bietet auch Microsoft eine Migration per IMAP4 zu Exchange Online an, aber gerade der Umfang mit GroupWise, Notes, GoogleMail und anderen Quellen ist da doch ziemlich durchwachsen. IMAP4 kennt nicht wirklich Termine und Kontakte

Die folgende Liste ist nur als erster Anlaufpunkt zu verstehen. Es gibt deutlich mehr Anbieter und ich habe mir keinen hier Erfahrungen gemacht.

IMAP4 APIs

Sie können natürlich auch selbst mit etwas Code sich an IMAP4 versuchen. In Perl gibt es sogar direkt eine IMAP4-Klasse. In .NET oder Powershell gibt es hier aber nichts, so dass Sie auf 3rd Party Tools zurückgreifen müssen. Ich habe mit keinem der Produkte bislang Erfahrungen gesammelt und habe auch nicht vor, noch einen IMAP4 Export/Importer oder Sync-Tool zu schreiben.

Weitere Links