Falsche E-Mail-Daten nach Migration zu Exchange Online

Das klassische Montagmorgen-Szenario

Die IMAP-Migration zu Exchange Online ist abgeschlossen. Der Batch ist im Exchange Admin Center (EAC) fehlerfrei durchgelaufen, die Postfächer sind synchronisiert, die Nutzerinnen und Nutzer können sich einloggen. Freitagabend schließen Sie Ihren Rechner mit dem guten Gefühl, etwas geleistet zu haben.

Montagmorgen kommen die Tickets. "Alle meine E-Mails sind vom Freitag datiert." "Mein Posteingang ist unbrauchbar." "Alte E-Mails fehlen." In Wirklichkeit fehlt nichts: Die E-Mails sind da, aber Outlook zeigt sie alle mit dem Migrationsdatum statt mit dem ursprünglichen Sendedatum an. Eine E-Mail von 2019 erscheint mit dem Datum des letzten Freitags. Das Ergebnis: Der gesamte Posteingang wirkt, als enthielte er nur neue Nachrichten.

Das ist eines der frustrierendsten Probleme bei IMAP-Migrationen zu Exchange Online, und Microsoft dokumentiert es so gut wie gar nicht.

Warum die EAC-Migration Datumsangaben zerstört

Wenn Sie den Exchange Admin Center nutzen, um eine IMAP-Migration von einem lokalen Server (Dovecot, Courier, Cyrus, UW-IMAP) einzurichten, verbindet sich Exchange Online per IMAP mit dem Quellserver, ruft die Nachrichten ab und injiziert sie über seine eigene interne Transportpipeline in die Zielpostfächer.

Genau da entsteht das Problem.

Jede E-Mail, die durch die Exchange-Transportpipeline läuft, erhält automatisch einen zeitgestempelten Received:-Header. Das ist seit Jahrzehnten Standardverhalten bei SMTP- und IMAP-Servern: Jeder Server, der eine Nachricht anfasst, drückt ihr einen Zeitstempel auf. Das Problem: Outlook (insbesondere Outlook für Windows in neueren Versionen) verwendet den neuesten Received:-Header als Anzeigyreferenz, wenn andere Metadaten mehrdeutig sind.

Der ursprüngliche Date:-Header (derjenige, der angibt, wann die E-Mail tatsächlich versendet wurde, im Sinne der RFC 2822) ist weiterhin im Bestand vorhanden. Er wurde nicht entfernt. Aber er wird durch den neuen Received:-Header, den Exchange beim Injizieren hinzufügt, gewissermaßen "überschattet".

Zusätzlich wird das IMAP-INTERNALDATE (die Metadaten, die IMAP-Server intern zur Datierung von Nachrichten verwenden und die die Sortierung in den meisten E-Mail-Clients steuern) auf das Injektionsdatum gesetzt, nicht auf das ursprüngliche Sendedatum. Exchange Online hat keine native Möglichkeit, das INTERNALDATE des Quellservers bei einer Batch-Migration über den EAC zu erhalten.

EAC vs. Drittanbieter-Tools: ein wichtiger Unterschied

Hier müssen zwei Situationen unterschieden werden. Bei Tools wie BitTitan MigrationWiz oder CloudM Migrate existiert das Problem ebenfalls, aber diese Tools bieten manchmal Konfigurationsoptionen (teils schlecht dokumentiert, oft in den erweiterten Einstellungen versteckt), die versuchen, bestimmte Datumsmetadaten zu erhalten.

Die native Migration über den EAC bietet keinerlei Option dieser Art. Microsoft stellt keinen Parameter bereit, mit dem die Erhaltung des INTERNALDATE in der Batch-Migrationspipeline gesteuert werden könnte. Es ist eine Black Box: Sie konfigurieren den Batch, starten ihn, und Exchange macht intern, was es will. Und was es konsequent tut: Es datiert Nachrichten auf den Zeitpunkt ihrer Injektion.

(Wer schon einmal die Roh-Header einer über den EAC migrierten E-Mail analysiert hat, weiß, dass der von Exchange hinzugefügte Received:-Header unverkennbar ist: Er enthält Verweise auf interne Microsoft-Server wie *.protection.outlook.com oder *.prod.exchangelabs.com, mit einem Zeitstempel, der exakt in das Migrationsfenster fällt.)

Warum das Neuerstellen des Batches nichts löst

Die erste Reaktion vieler IT-Admins ist: "Wenn ich die migrierten Postfächer lösche und den Batch von vorne starte, werden die Daten vielleicht diesmal korrekt."

Das ist verständlich. Aber es funktioniert nicht.

Das Problem liegt nicht in der Batch-Konfiguration. Es liegt nicht an einer vergessenen Option. Es steckt in der Architektur der Exchange-Transportpipeline selbst, die bei jeder Migration identisch ist. Ein erneuter Durchlauf liefert exakt dasselbe Ergebnis: dieselben Received:-Header mit dem neuen Migrationsdatum, dieselben falschen INTERNALDATEs. Sie haben Zeit verloren, und die Nutzerinnen und Nutzer wurden ein zweites Mal ohne Grund gestört.

Manche Admins versuchen auch, die Sortiereinstellungen in Outlook zu ändern ("Sortieren nach Sendedatum" statt "Eingangsdatum"). Das ist keine Lösung. Es ist ein Pflaster. Der Date:-Header und das INTERNALDATE bleiben für Clients falsch, die diese Einstellung nicht unterstützen: für OWA, für Outlook Mobile und für jede Drittanbieter-Anwendung, die per IMAP oder EWS auf das Postfach zugreift.

Was in den Headern wirklich passiert

Ein vereinfachtes Beispiel, was in einer per EAC migrierten E-Mail steht. Der ursprüngliche Header:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@altedomain.de
Subject: Bericht Q1 2019

Nach der Migration erhält die Nachricht am Anfang der Header-Kette etwas wie:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook sieht diesen Received:-Header zuerst (er steht ganz oben im Header-Block), interpretiert ihn als jüngstes Verarbeitungsdatum der Nachricht und zeigt ihn als Eingangsdatum an. Der ursprüngliche Date:-Header von 2019 ist weiterhin vorhanden, ein paar Zeilen weiter unten. Aber Outlook verwendet ihn nicht für die Anzeige in der Nachrichtenliste.

Genauer gesagt: Das Verhalten variiert leicht je nach Outlook-Version. Versionen ab 2021 (und besonders das neue Outlook für Windows, das seit Ende 2023 ausgerollt wird) reagieren auf dieses Problem besonders sensibel, weil sie sich stärker auf Exchange-Graph-Metadaten stützen als auf den rohen Date:-Header. Migrationen, die mit Outlook 2016 kein sichtbares Problem verursacht hätten, können mit dem neuen Outlook zum echten Problem werden.

Wer wirklich betroffen ist

Die häufigsten IMAP-Quellserver bei dieser Art von Migration sind Dovecot (sehr verbreitet in Linux/cPanel-Umgebungen) und Courier. Beide liefern INTERNALDATE-Werte über IMAP, die der EAC nicht erhält. Bei einer Migration von Exchange on-premises zu Exchange Online (Hybrid- oder Cutover-Migration) verhält es sich anders, weil Microsoft dabei ein internes Transportprotokoll (MAPI/EWS) einsetzt, das Metadaten besser bewahrt. Das Problem betrifft die generische IMAP-Migration über den EAC.

Am stärksten betroffen sind Nutzerinnen und Nutzer mit Postfächern und langer Geschichte (5 Jahre und mehr) und hohem Nachrichtenaufkommen. Wer 300 E-Mails im Posteingang hat, kommt damit schnell klar. Ein Vertriebsleiter mit 12.000 nach Datum sortierten E-Mails, auf die er täglich angewiesen ist, um Kundenkommunikation wiederzufinden, ist dagegen handlungsunfähig.

Warum ein selbst geschriebenes Skript hier keine gute Idee ist

Manche IT-Admins, die das technische Problem verstanden haben, sind versucht, ein PowerShell- oder Python-Skript zu schreiben, um die Header manuell zu korrigieren. Das Grundprinzip mag einfach klingen, sobald man den Mechanismus kennt. Die Realität einer produktiven Korrektur ist eine andere Geschichte.

Zunächst die Sonderfälle. S/MIME-signierte E-Mails und PGP-verschlüsselte Nachrichten haben eine Struktur, die keine Header-Modifikation verträgt, ohne die Signatur zu invalidieren. Nachrichten vom Typ multipart/alternative mit fehlerhaften MIME-Boundaries (auf alten Courier-Servern häufig) können durch ein Skript korrumpiert werden, das die Nachricht ändert, ohne die Struktur korrekt neu aufzubauen. Nicht-ASCII-Header, die gemäß RFC 2047 kodiert sind (Absendernamen mit Umlauten oder japanischen Zeichen etwa), sind eine klassische Fehlerquelle.

Dann das Volumen. Ein Skript, das mit 50 Test-E-Mails in der Entwicklungsumgebung funktioniert, kommt mit den Rate-Limits der Exchange-Online-API im Produktivbetrieb nicht zurecht. Der Fehler 429 Too Many Requests um 2 Uhr nachts mitten in einem Batch mit 8.000 Nachrichten, ohne Wiederaufnahme-Mechanismus, bedeutet eine durchwachte Nacht und möglicherweise doppelte oder verlorene Nachrichten.

Und vor allem: Wie stellt man sicher, dass jede korrigierte E-Mail intakt ist? Dass kein Anhang abgeschnitten wurde, kein Gesprächsfaden gebrochen ist, alle Labels und Ordner erhalten sind? Ohne individuelle Prüfung pro Nachricht hofft man einfach, dass alles gut gegangen ist.

Die Datumskorrektur nach einer Migration sieht aus wie ein 50-Zeilen-Skript, braucht aber Tausende von Zeilen, um im Produktivbetrieb zuverlässig zu funktionieren.

Was Redate.io anders macht

Redate.io verbindet sich mit Exchange Online über die Microsoft-365-APIs (Azure Active Directory, Delegationsberechtigungen auf Tenant-Ebene) und scannt die betroffenen Postfächer, um E-Mails zu identifizieren, deren Datumsmetadaten durch die Migration beschädigt wurden. Dieser Scan-Schritt ist kostenlos und gibt ein genaues Bild des Ausmaßes: Anzahl der betroffenen Nachrichten, betroffene Postfächer, Zeitraum der korrumpierten Daten.

Der proprietäre Korrekturmotor von Redate.io verarbeitet anschließend jede E-Mail einzeln über eine mehrstufige Analysepipeline. Diese umfasst eine Mustererkennung über Hunderte bekannter Migrationstool-Signaturen (einschließlich der Exchange-Online-Transportpipeline), eine RFC-Konformitätsprüfung und eine Überprüfung der strukturellen Integrität jeder Nachricht vor und nach der Korrektur. S/MIME-signierte E-Mails, komplexe MIME-Strukturen, nicht standardkonforme Kodierungen: alle werden über spezifische Verarbeitungspfade behandelt.

Jede korrigierte Nachricht wird einzeln verifiziert. Die Originale werden 30 Tage lang in einem sichtbaren Sicherungsordner aufbewahrt. Wenn mit einer bestimmten Nachricht etwas nicht stimmt, wird sie nicht verändert: Redate.io meldet die Anomalie, anstatt das Risiko einer Beschädigung einzugehen.

Die Preisgestaltung basiert auf dem Volumen, als Einmalzahlung pro Postfach. Kein Abonnement, keine laufenden Kosten. Das Problem wird einmal behoben, dann ist es erledigt.

Für Exchange-Online-Migrationen unterstützt Redate.io die Verbindung über Azure-AD-Anwendungsberechtigungen (ohne dass für jedes Postfach einzelne Zugangsdaten angelegt werden müssen), was die Verarbeitung großer Postfachflotten für IT-Admins und MSPs erheblich einfacher zu koordinieren macht.

Wer mehrere Kunden betreut, die von dieser Art Migration betroffen sind, sollte auch den vollständigen Leitfaden zur Datumskorrektur nach Microsoft-365-Migrationen lesen, für einen Überblick über die verschiedenen abgedeckten Szenarien.

Die E-Mails sind da, die ursprünglichen Daten auch. Starten Sie einen kostenlosen Scan auf Redate.io, um genau zu sehen, wie viele Nachrichten in Ihren Exchange-Online-Postfächern betroffen sind, bevor Sie entscheiden, wie Sie vorgehen.