iCloud zu Office 365 Migration: falsche E-Mail-Daten

Ein Migrationsszenario, das Daten systematisch zerstört

Sie haben gerade Ihre iCloud-Mailbox zu Office 365 übertragen. Die E-Mails sind da, die Ordner stimmen, alles sieht gut aus. Montagmorgen kommt die erste Beschwerde: "Alle meine alten E-Mails zeigen das heutige Datum." Dann eine zweite. Dann zehn.

Das ist kein Einzelfall. Die Migration von iCloud Mail zu Office 365 gehört zu den am häufigsten dokumentierten Szenarien für Datums-Korruption bei E-Mails, aus sehr konkreten technischen Gründen, die mit dem Verhalten von Apple Mail, dem IMAP-Protokoll und der Art und Weise zusammenhängen, wie Microsoft 365 eingehende Nachrichten verarbeitet.

Warum iCloud zu Office 365 Daten zerstört

Um das Problem zu verstehen, muss man drei Dinge unterscheiden, die viele verwechseln (auch erfahrene IT-Administratoren): den Date:-Header, das IMAP-INTERNALDATE und das Erstellungsdatum der Datei.

Der Date:-Header (RFC 2822)

Jede E-Mail enthält einen Date:-Header, der angibt, wann die Nachricht gesendet wurde. Dieser Header ist im Rohtext der Nachricht eingebettet und ändert sich theoretisch nie. Er ist das "originale" Datum im eigentlichen Sinne.

Das IMAP-INTERNALDATE

Das IMAP-Protokoll (definiert in RFC 3501) weist jeder Nachricht eine eigene Metadaten-Angabe zu, das sogenannte INTERNALDATE. Diesen Wert verwenden die meisten E-Mail-Clients zum Sortieren und Anzeigen von Nachrichten im Posteingang, nicht den Date:-Header. Outlook verlässt sich besonders stark auf das INTERNALDATE für Anzeige und Sortierung.

Das Problem: Wenn ein Migrationswerkzeug eine E-Mail von einem IMAP-Server auf einen anderen kopiert, sollte es dieses INTERNALDATE idealerweise erhalten. In der Praxis passiert das nicht immer.

Das besondere Verhalten von Apple Mail

Apple Mail verwendet beim Synchronisieren von Nachrichten aus iCloud manchmal das serverseitige Erstellungsdatum der Datei als Referenz für das INTERNALDATE. Das ist kein Bug im strengen Sinne, sondern eine Interpretation der IMAP-Spezifikation, die von anderen Clients abweicht. (Wer schon einmal versucht hat, ein INTERNALDATE-Problem anhand der rohen IMAP-RFCs zu debuggen, weiß: Die Spezifikation lässt an diesem Punkt einen erheblichen Interpretationsspielraum.)

Ergebnis: Wenn Sie E-Mails aus iCloud über Apple Mail exportieren oder migrieren, können die INTERNALDATEs der Nachrichten bereits fehlerhaft sein, noch bevor sie in Office 365 ankommen.

Die drei iCloud-Migrationsmethoden und ihre Tücken

Direkte IMAP-Migration

Die gängigste Methode ist, iCloud als IMAP-Quelle und Office 365 als Ziel zu konfigurieren und dann ein Migrationswerkzeug zu verwenden (imapsync, MigrationWiz oder ein Eigenbau-Tool). Das Werkzeug verbindet sich mit beiden Servern und kopiert die Nachrichten.

Das Problem ist hier zweifach. Erstens haben Apples IMAP-Server Ratenbegrenzungen, die Werkzeuge zu Pausen zwingen. Dabei schließen und öffnen sich Verbindungen neu, was zu parasitären INTERNALDATEs führen kann. Zweitens erhält jede per IMAP APPEND nach Exchange Online kopierte Nachricht standardmäßig das Datum des Einspielens als Empfangsdatum, sofern das Werkzeug das ursprüngliche INTERNALDATE nicht explizit im Einfügebefehl übergibt.

Manche Werkzeuge machen das korrekt. Andere nicht systematisch. Bei einer Mailbox mit 40.000 Nachrichten entspricht schon eine Fehlerquote von 2 % 800 E-Mails mit falschem Datum.

Für Migrationen via imapsync, siehe auch: imapsync-Migrationsdaten in Microsoft 365 korrigieren.

.mbox- oder .eml-Export und anschließender Import

Manche Nutzer exportieren ihre iCloud-E-Mails über Apple Mail im .mbox-Format und versuchen, diese dann in Outlook zu importieren. Das ist eine handwerkliche Methode mit wechselhaften Ergebnissen.

Das .mbox-Format kodiert E-Mails als Folge von Textnachrichten. Die Daten sind in den jeweiligen Date:-Headern enthalten, aber die Trennzeile zwischen Nachrichten ("From ") enthält ebenfalls ein Datum, das von manchen Import-Tools als Erstellungsdatum interpretiert werden kann. Outlook verwendet beim Import einer in .pst konvertierten .mbox-Datei manchmal dieses Trennzeilendatum statt des Date:-Headers der eigentlichen Nachricht.

Drag-and-Drop über Outlook

Das ist die Methode, die den größten Schaden anrichtet. Ein Nutzer konfiguriert beide Konten in Outlook (iCloud und Office 365) und zieht seine Nachrichten per Drag-and-Drop von einem Ordner in den anderen. Das klingt einfach. Für die Daten ist es eine Katastrophe.

Wenn Outlook eine Nachricht per Drag-and-Drop zwischen zwei IMAP-Konten verschiebt, erstellt es tatsächlich eine neue .EML-Datei, fügt sie in das Zielkonto ein und löscht das Original. Diese neue Datei erbt das Windows-Erstellungsdatum, also den exakten Zeitpunkt des Drag-and-Drop. Der ursprüngliche Date:-Header ist zwar noch im Nachrichtentext vorhanden, aber das auf dem Exchange-Online-Server gespeicherte INTERNALDATE entspricht dem Zeitpunkt der Aktion. Outlook zeigt anschließend dieses Migrationsdatum für alle verschobenen Nachrichten an.

Um es genau zu sagen: Dieses Verhalten variiert je nach Outlook-Version. Seit dem Outlook-Update vom Herbst 2023 hat sich das Verhalten für bestimmte Szenarien leicht verbessert, aber Drag-and-Drop zwischen Konten bleibt eine dokumentierte Quelle für Datums-Korruption.

Was Office 365 und Outlook am Ende anzeigen

Exchange Online speichert E-Mails mit ihrem INTERNALDATE. Outlook Desktop liest dieses INTERNALDATE, um das Datum in der Spalte "Empfangen" anzuzeigen und den Posteingang zu sortieren. Wenn das INTERNALDATE während der Migration überschrieben wurde, zeigt Outlook das Migrationsdatum, Punkt.

Outlook Web App (OWA) verhält sich genauso. Es gibt keine "alternative Ansicht", die das ursprüngliche Datum aus dem Date:-Header anzeigen würde. Was Sie in der Datumsspalte sehen, ist das INTERNALDATE.

Der ursprüngliche Date:-Header ist noch da, intakt und lesbar, wenn man die Roh-Header einer Nachricht aufruft. Aber keine normale Ansicht zeigt ihn. Das ist die eigentliche Frustration dieses Problems: Die richtige Information existiert, ist aber ohne technische Korrektur nicht zugänglich.

Was der Microsoft-Support nicht löst

Wenn Sie bei Microsoft Support ein Ticket zu diesem Problem öffnen, bekommen Sie wahrscheinlich Folgendes: eine Bestätigung, dass die angezeigten Daten den gespeicherten INTERNALDATEs entsprechen, einen Hinweis, die Sortiereinstellungen in Outlook zu prüfen, und eventuell eine Weiterleitung an das verwendete Migrationswerkzeug.

Das ist kein böser Wille. Microsoft hat schlicht kein natives Werkzeug, um die INTERNALDATEs von Tausenden bereits in Exchange Online ingerierten Nachrichten rückwirkend zu korrigieren. Die Korrektur erfordert den individuellen Zugriff auf jede Nachricht, die Analyse ihrer Header und die Rekonstruktion der Datumsmetadaten, was außerhalb des Rahmens des Standard-Supports liegt.

Der iCloud-Support betrachtet die Nachrichten als korrekt exportiert und sieht das Problem auf der Zielseite. Beide Supports schieben die Verantwortung weiter, und der Nutzer bleibt mit 12.000 E-Mails sitzen, alle datiert auf den Tag der Migration.

Das Skalierungsproblem

Zu verstehen, warum die Daten kaputt sind, ist eine Sache. Sie manuell in einer Produktions-Mailbox zu korrigieren, ist eine andere.

Manche IT-Administratoren versuchen, die Korrektur zu skripten. Die Grundidee ist nicht schwer zu konzipieren, aber die Umsetzung bei echten Volumina wirft Probleme auf, mit denen Eigenbau-Skripte schlecht umgehen:

• S/MIME-signierte oder PGP-verschlüsselte E-Mails können nicht verändert werden, ohne die kryptografische Signatur zu invalidieren
• Nachrichten mit komplexen multipart/alternative-Strukturen (HTML + Nur-Text + verschachtelte Anhänge) sind fehleranfällig bei der Bearbeitung
• Nicht-ASCII-kodierte Header (RFC 2047, insbesondere für japanische, arabische oder kyrillische Zeichen) können durch Werkzeuge beschädigt werden, die diese Kodierungen nicht korrekt verarbeiten
• API-Kontingente von Microsoft Graph und Ratenbegrenzungen von Exchange Online (Fehler 429 Too Many Requests) stoppen Skripte, die nicht für exponentielles Backoff ausgelegt sind
• Ein Skript, das auf 500 Test-E-Mails einwandfrei läuft, bricht um 3 Uhr morgens bei der 8.000. Nachricht einer echten Mailbox ab, ohne Wiederaufnahme-Mechanismus

Und die entscheidende Frage: Wie prüft man, dass jede korrigierte E-Mail nach der Korrektur intakt ist? Dass der Anhang noch vorhanden ist? Dass der Diskussionsfaden nicht unterbrochen ist? Ein Eigenbau-Skript führt diese Prüfung normalerweise nicht durch.

Wie Redate.io iCloud-Migrationen zu Office 365 behandelt

Redate.io verbindet sich direkt mit Office 365 über Microsoft-365-Berechtigungen (Azure AD), ohne dass ein Zugriff auf iCloud-Server erforderlich ist. Die E-Mails befinden sich bereits in Exchange Online, wenn Redate eingreift.

Die Korrektur-Engine von Redate analysiert die Header-Kette jeder Nachricht, um das ursprüngliche Datum zu identifizieren. Sie unterscheidet dabei Received:-Header, die während der Migration hinzugefügt wurden, von legitimen Datumsmetadaten. Diese Analyse umfasst ein Musterabgleichverfahren über Signaturen bekannter Migrationswerkzeuge, was die Identifikation parasitärer Header ermöglicht, auch wenn diese nicht auf den ersten Blick erkennbar sind.

Jede korrigierte E-Mail wird nach der Verarbeitung einzeln geprüft. Die Originale werden 30 Tage lang in einem sichtbaren Sicherungsordner aufbewahrt, was kein Eigenbau-Skript standardmäßig leistet. Der erste Scan ist kostenlos und gibt Aufschluss darüber, wie viele E-Mails betroffen sind, bevor eine Korrektur eingeleitet wird.

Redate unterstützt auch Migrationen von Google Workspace zu Office 365 sowie Korrekturen nach cPanel-Migrationen. Siehe etwa: E-Mail-Daten nach Microsoft-365-Migration korrigieren oder Falsche E-Mail-Daten nach Migration zu Exchange Online.

Erst scannen, dann korrigieren

Der empfohlene Ausgangspunkt für jede iCloud-zu-Office-365-Migration, die fehlerhafte Daten erzeugt hat: den kostenlosen Scan von Redate.io auf den betroffenen Postfächern starten. Der Scan identifiziert genau, wie viele E-Mails ein verdächtiges INTERNALDATE haben und in welchen Ordnern sie sich befinden.

Das dauert je nach Volumen zwischen 12 und 45 Minuten und liefert ein klares Bild des Ausmaßes des Problems, bevor irgendetwas unternommen wird. Für MSPs, die nach einer Migration mehrere Postfächer gleichzeitig verwalten, verhindert dieser Batch-Scan, dass Postfächer korrigiert werden, die es gar nicht nötig haben.

Wenn die Daten Ihrer E-Mails nach einer Migration von iCloud fehlerhaft sind, starten Sie mit dem kostenlosen Scan auf Redate.io, um das Ausmaß des Problems in Ihren Office-365-Postfächern zu messen.