Shared Hosting zu Microsoft 365: das versteckte Datumsproblem

Das Problem, das niemand erwähnt hat

Sie haben die Migration Ihrer Postfächer von OVH, Infomaniak, Ionos oder o2switch zu Microsoft 365 gerade abgeschlossen. Der Migrationsassistent im EAC (Exchange Admin Center) lief die ganze Nacht, alles steht auf Grün, die Postfächer sind befüllt. Montagmorgen, erstes Ticket: "Alle meine alten E-Mails haben das heutige Datum." Dann ein zweites. Dann zehn.

Das ist kein Bug in Microsoft 365. Und kein Zufall. Es ist das mechanische Ergebnis einer IMAP-Migration, und bei Shared-Hosting-Anbietern ist das Problem häufig doppelt so schlimm wie bei einer klassischen Migration. Hier ist der Grund.

Wie IMAP Datumsangaben verwaltet (und wo es schiefläuft)

Jede auf einem IMAP-Server gespeicherte E-Mail hat zwei verschiedene Arten von Datumsangaben. Auf der einen Seite der Date:-Header (definiert durch RFC 2822), der im Nachrichtenkörper selbst enthalten ist und angibt, wann die Nachricht gesendet oder empfangen wurde. Auf der anderen Seite das INTERNALDATE, eine serverseitige Metadaten-Information, die angibt, wann die Nachricht im Postfach abgelegt wurde. Genau diesen Wert nutzen E-Mail-Clients wie Outlook standardmäßig zum Sortieren und Anzeigen von E-Mails.

(Wer schon einmal versucht hat, die Roh-Header einer E-Mail im EAC zu lesen, weiß: das ist nicht gerade Strandlektüre. Leicht zwanzig bis dreißig Header-Zeilen, bevor man überhaupt zum eigentlichen Inhalt kommt.)

Wenn ein IMAP-Migrationstool eine Nachricht von einem Postfach in ein anderes überträgt, muss es das INTERNALDATE auf dem Zielserver neu erstellen. Manche Tools machen das korrekt. Viele nicht, oder nur mit Einschränkungen. Und die empfangenden Server haben dabei ein Wörtchen mitzureden: Exchange Online zum Beispiel behält, was er bekommt. Trägt eine Kopie ihr Originaldatum, behält Exchange Online dieses Datum bei. Wenn Datumsangaben also falsch sind, liegt das am eingesetzten Tool, nicht an Microsoft 365.

Ergebnis: Jede migrierte E-Mail wirkt so, als wäre sie am Migrationstag "empfangen" worden. Egal, ob sie aus dem Jahr 2019 stammt.

Das Zwei-Stufen-Szenario: Warum Shared Hosting alles verschlimmert

Hier wird die Situation bei Migrationen von Shared-Hosting-Anbietern wie OVH, Infomaniak, Gandi, Ionos oder o2switch besonders problematisch.

Diese Anbieter setzen typischerweise auf geteilte Postfix-, Dovecot- oder cPanel-Server mit Standard-IMAP-Konfigurationen. Viele kleine und mittelständische Unternehmen haben dort über Jahre E-Mails angesammelt, teils seit 2010 oder 2012. Wenn sie sich für den Wechsel zu Microsoft 365 entscheiden, läuft die Migration oft in zwei Phasen ab.

Schritt 1: Die erste Korrumpierung (noch vor Microsoft 365)

In vielen Fällen haben die E-Mails bereits eine erste Migration hinter sich. Das Unternehmen hat im Laufe der Jahre ein- oder zweimal den Hosting-Anbieter gewechselt: zum Beispiel von Gandi zu OVH im Jahr 2018, dann von OVH zu Infomaniak im Jahr 2022. Jeder dieser IMAP-Transfers konnte das ursprüngliche INTERNALDATE auf das Datum der Übertragung zurücksetzen, wenn das Tool das Originaldatum nicht übernommen hat, und manche Tools fügen zusätzlich eigene Migrations-Header mit diesem Datum hinzu.

Wenn die E-Mails bei Microsoft 365 ankommen, tragen sie also bereits Narben mit sich. Der ursprüngliche Date:-Header ist intakt (er ist Teil des Nachrichtenkörpers und wird nicht angetastet), aber die Datums-Metadaten wurden bereits einmal gestört.

Schritt 2: Die zweite Korrumpierung beim Wechsel zu Exchange Online

Das IMAP-Migrationstool im EAC, oder ein Drittanbieter-Tool wie BitTitan MigrationWiz im IMAP-Modus, nimmt diese bereits beschädigten E-Mails auf. Übernimmt dieses Tool ebenfalls nicht das Originaldatum jeder E-Mail, ordnet Exchange Online die Nachricht dem Tag der Übertragung zu, und genau dieses Datum zeigt Outlook anschließend als "Empfangsdatum" an.

Eine E-Mail aus dem März 2017 kann damit zwei fehlerhafte Datumsschichten tragen: Migrations-Header aus dem Umzug von 2022 und ein Empfangsdatum aus der Migration zu Microsoft 365 im Jahr 2024. Outlook zeigt 2024. Der Nutzer sieht 2024. Das ist auf zwei Ebenen falsch.

Zur Präzisierung: Outlook ermittelt das Anzeigedatum aus einer Kombination aus dem INTERNALDATE, das Exchange Online erfasst hat, und den vorhandenen Headern. Übernimmt das Migrationstool die Originaldatumsangaben jedoch nicht, fügt der Umzug zu Exchange Online eine neue Fehlerschicht über die alte hinzu.

Migrationstools und Hosting-Anbieter: die riskanten Kombinationen

Einige Kombinationen tauchen bei Migrationen von Shared-Hosting-Anbietern besonders häufig auf:

• OVH / Infomaniak / Ionos + IMAP-Tool des EAC: Das native Microsoft-Tool ist praktisch, aber bekannt dafür, Datumsangaben bei umfangreichen IMAP-Migrationen nicht korrekt zu erhalten.
• cPanel (o2switch, LWS usw.) + BitTitan MigrationWiz im IMAP-Modus: MigrationWiz im IMAP-Modus fügt eigene Migrations-Header hinzu. Das Ergebnis ist dokumentiert, unter anderem auf der Seite BitTitan-Migrationsdaten in Microsoft 365 korrigieren.
• Gandi / Mailcow + imapsync: imapsync ist ein leistungsfähiges Tool, aber die Behandlung des INTERNALDATE hängt von der Konfiguration ab. Ohne die entsprechende Option werden Datumsangaben nicht erhalten. Mehr dazu auch unter imapsync: Daten nicht erhalten?
• Jede manuelle Migration per Drag-and-Drop in Outlook: Wer ganze Ordner per Drag-and-Drop zwischen zwei in Outlook konfigurierten Konten kopiert hat, bei dem wird das INTERNALDATE jeder E-Mail auf das Kopierdatum überschrieben. Ausnahmslos.

Der gemeinsame Nenner: Alle diese Methoden führen dazu, dass E-Mails in Exchange Online landen, deren angezeigtes Datum in Outlook nichts mehr mit der Realität zu tun hat.

Warum "selbst korrigieren" im großen Maßstab keine gute Idee ist

Das Problem zu verstehen ist eine Sache. 8.000 E-Mails in 40 Exchange-Online-Postfächern zu korrigieren, mit komplexen Ordnerstrukturen, S/MIME-signierten Nachrichten, großen Anhängen und verschachtelten Gesprächsverläufen, ist eine ganz andere.

Ein PowerShell-Skript, das bei zehn Test-E-Mails zu funktionieren scheint, kann bei Nachricht Nummer 4.237 still scheitern, weil dort eine korrumpierte MIME-Boundary oder ein nach RFC 2047 kodierter Header vorliegt (dieses =?UTF-8?B?...?=-Format für Nicht-ASCII-Zeichen in Absendernamen). Ohne einen individuellen Prüfmechanismus werden Sie das nicht bemerken. Sie haben einfach eine E-Mail weniger.

Die konkreten Risiken beim DIY-Ansatz bei dieser Art von Migration:

• Doppelte Nachrichten, wenn die Einfügelogik auf halbem Weg versagt
• Fehlende Anhänge, wenn die Multipart-Struktur falsch rekonstruiert wird
• Kaputte Gesprächsverläufe in Outlook (Konversationen basieren auf den Headern References: und In-Reply-To:, die verändert werden können)
• Fehler 429 (Too Many Requests) der Microsoft Graph API um 3 Uhr nachts, die die Verarbeitung ohne Rollback-Möglichkeit abbrechen
• Kein einfaches Mittel, um zu prüfen, ob alle 8.000 Korrekturen tatsächlich fehlerfrei angewendet wurden

Und speziell bei Migrationen von Shared-Hosting-Anbietern kommt eine weitere Schwierigkeit hinzu: Die E-Mails tragen mehrere Schichten parasitärer Received:-Header, nicht nur eine. Ein einfaches Skript, das "den letzten Received:" entfernt, reicht nicht. Die gesamte Header-Kette muss analysiert werden, um zu erkennen, welcher Header zu welcher Migration gehört und welcher das ursprüngliche Empfangsdatum tatsächlich widerspiegelt.

Was Redate.io anders macht

Jede Nutzerin und jeder Nutzer meldet sich mit dem eigenen Microsoft-Konto an, und Redate.io öffnet genau dieses Postfach mit den Rechten, die diese Anmeldung gewährt. Der erste Scan ist kostenlos: Redate.io identifiziert alle E-Mails, bei denen das angezeigte Datum nicht dem tatsächlichen Datum entspricht, und liefert eine präzise Auswertung je Postfach.

Die Korrektur basiert auf einem proprietären Korrekturmodul, das die vollständige Header-Kette jeder Nachricht analysiert, unabhängig vom eingesetzten Migrationstool arbeitet und die Datums-Metadaten korrekt rekonstruiert, selbst wenn mehrere Korrumpierungsschichten übereinanderliegen. Jede korrigierte E-Mail wird einzeln geprüft. Die Originale werden in einem sichtbaren Ordner Ihres eigenen Postfachs aufbewahrt, bis Sie sie selbst löschen.

Bei Migrationen von Shared-Hosting-Anbietern behandelt die mehrstufige Analyse-Pipeline von Redate.io explizit Szenarien mit doppelter Korrumpierung: Statt sich nur den letzten Received:-Header anzusehen, rekonstruiert sie die vollständige Vorgeschichte, um das tatsächliche Empfangsdatum zu ermitteln. Mehr dazu auch unter Datumsangaben nach Microsoft-365-Migration korrigieren sowie im technischen Hintergrundartikel zu IMAP INTERNALDATE: Warum Datumsangaben kaputtgehen.

Vor oder nach der Migration: zwei Zeitpunkte zum Handeln

Zwei Situationen, zwei Vorgehensweisen.

Sie haben noch nicht migriert. Die gute Nachricht: Der Schaden lässt sich begrenzen. Manche Migrationstools (MigrationWiz im Exchange-Modus, CloudM mit den richtigen Einstellungen) erhalten Datumsangaben besser als andere. Aber selbst im besten Fall wird eine Migration von einem Shared-Hosting-Anbieter ohne saubere Vorgeschichte wahrscheinlich Spuren hinterlassen. Planen Sie einen Durchlauf mit Redate.io nach der Migration ein, bevor Sie die Postfächer an die Nutzerinnen und Nutzer übergeben.

Sie haben bereits migriert und die Tickets häufen sich. Redate.io korrigiert bestehende Postfächer in Microsoft 365, unabhängig davon, wie lange die Migration zurückliegt. Der Scan gibt Ihnen ein genaues Bild des tatsächlichen Zustands jedes einzelnen Postfachs, bevor irgendeine Korrektur vorgenommen wird. Schauen Sie sich auch die Checkliste E-Mail-Migration: Datumsprobleme vermeiden an, um dieselben Fehler künftig zu vermeiden.

Sie haben von OVH, Infomaniak, Ionos oder o2switch zu Microsoft 365 migriert und die Datumsangaben stimmen nicht? Erstellen Sie ein Redate.io-Konto, um Ihre Postfächer kostenlos zu scannen und den genauen Umfang des Problems zu sehen, bevor Sie weitere Schritte unternehmen.