Outlook: IMAP-Empfangsdatum vs. Sendedatum nach Migration

Das Symptom, das jeder kennt

Sie haben gerade eine IMAP-Migration zu Microsoft 365 oder Google Workspace abgeschlossen. Montagmorgen trudeln die ersten Tickets ein: "Alle meine E-Mails haben dasselbe Datum", "Mein Verlauf ist kaputt", "Ich finde nichts mehr in meinem Postfach". Sie öffnen Outlook und sehen: Tausende von E-Mails zeigen das Datum des vergangenen Wochenendes. Nicht das Datum, an dem sie gesendet wurden. Das Datum, an dem die Migration stattgefunden hat.

Das ist kein Outlook-Bug. Es ist eine direkte Folge der Funktionsweise des IMAP-Protokolls und der Migrationstools. Um zu verstehen warum, muss man unter die Haube schauen.

Drei Datumsangaben in einer einzigen E-Mail

Eine E-Mail ist komplexer als sie auf den ersten Blick wirkt. Header, Nachrichtentext, Anhänge... und mehrere unterschiedliche Zeitstempel, die nebeneinander existieren. (Wenn Sie jemals versucht haben, die rohen Header einer E-Mail zu lesen, wissen Sie: das ist keine Freizeitlektüre.)

Der Date:-Header (RFC 2822)

Das ist das Datum, das der Absender beim Verfassen in die Nachricht geschrieben hat. Definiert durch RFC 2822, sieht es so aus:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Dieser Header ist fest im Nachrichteninhalt verankert. Er ändert sich nie, außer jemand modifiziert den Roh-Inhalt der Nachricht direkt. Das ist das "Sendedatum" im eigentlichen Sinne.

Der Received:-Header (an jedem Netzwerk-Hop hinzugefügt)

Jeder Server, der eine E-Mail auf ihrem Weg berührt, fügt einen Received:-Header ganz oben in die Nachricht ein, mit seinem eigenen Zeitstempel. Eine E-Mail, die drei Server passiert, sammelt damit drei Received:-Header. Der aktuellste steht immer ganz oben. Das sieht dann ungefähr so aus:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Das Ergebnis: Wenn ein Migrationstool wie BitTitan MigrationWiz, CloudM, imapsync oder GSMMO eine E-Mail vom Quell- auf den Zielserver verschiebt, verhält es sich ebenfalls wie ein "Netzwerk-Hop". Es injiziert einen neuen Received:-Header ganz oben in den Header-Stack, mit Datum und Uhrzeit der Migration.

Das IMAP-INTERNALDATE

Das ist das dritte Datum, und genau das ist das Problem. Das INTERNALDATE ist eine serverseitig gespeicherte Metadaten-Angabe, unabhängig vom Nachrichteninhalt selbst. Es repräsentiert das Datum, an dem die E-Mail im Postfach zugestellt (oder eingefügt) wurde. Wenn ein Migrationstool eine E-Mail über den IMAP-Befehl APPEND einfügt, entscheidet es selbst, welchen Wert es dem INTERNALDATE gibt. Und in vielen Fällen verwenden die Tools den Zeitpunkt der Migration. Nicht das ursprüngliche Datum.

Genau hier beginnt das ganze Problem.

Warum Outlook das Migrationsdatum anzeigt

Outlook verwendet das INTERNALDATE für die Anzeige der Spalte "Empfangen". Das ist das Standardverhalten, und es entspricht der IMAP-Spezifikation: Das INTERNALDATE soll das Eingangsdatum im Postfach repräsentieren. Bei einem normalen E-Mail-Eingang (eine echte eingehende Nachricht) liegt das INTERNALDATE nahe am Datum im Date:-Header. Beide sind konsistent.

Nach einer fehlgeschlagenen Migration zeigt das INTERNALDATE aller importierten E-Mails auf die Nacht vom 14. auf den 15. Juni 2024 (oder wann auch immer die Migration stattfand). Outlook liest diesen Wert, zeigt ihn in der Spalte "Empfangen" an, und das Ergebnis ist katastrophal: 45.000 E-Mails scheinen an demselben Abend eingegangen zu sein.

Um präzise zu sein: Der erste Received:-Header (der aktuellste im Stack) beeinflusst die Anzeige in bestimmten Konfigurationen ebenfalls. Aber das INTERNALDATE bleibt der Haupteinflussfaktor für die Spalte "Empfangen" in Outlook im synchronisierten IMAP-Modus.

Der Workaround "Spalte Gesendet hinzufügen" in Outlook

Die erste Reaktion der meisten IT-Admins, wenn sie das Problem entdecken, ist die Suche nach einem clientseitigen Workaround. Und tatsächlich gibt es einen.

In Outlook lässt sich die Spaltenanzeige eines Ordners anpassen, um die Spalte "Empfangen" durch die Spalte "Datum" oder "Gesendet" zu ersetzen (oder zu ergänzen). Die Spalte "Datum" liest direkt den Date:-Header der Nachricht, nicht das INTERNALDATE. Da der Date:-Header durch die Migration nicht verändert wurde, erscheinen die ursprünglichen Daten wieder.

In Outlook (Desktop, Version Microsoft 365) geht das so: Rechtsklick auf den Spaltenheader in der Nachrichtenliste, "Ansichtseinstellungen", dann die Spalten bearbeiten, um "Empfangen" zu entfernen und "Datum" hinzuzufügen. Per GPO lässt sich das für eine Massenbereitstellung umsetzen.

Klingt gut. Auf dem Papier löst das das visuelle Problem. In der Praxis ist es ein Pflaster auf einer Schlagader.

Die konkreten Grenzen dieses Workarounds

Mobile und Web-Clients

Outlook auf iOS, Android und die Outlook Web App (OWA) bieten nicht dieselben Anpassungsmöglichkeiten. Die Ansichtsänderung, die Sie auf Windows-Rechnern ausgerollt haben, überträgt sich nicht. Nutzerinnen und Nutzer, die ihre E-Mails auf dem Smartphone abrufen, sehen weiterhin das Migrationsdatum. Und in einem mittelgroßen Unternehmen ist das wahrscheinlich die Hälfte aller Anwender.

Die Suche

Die Outlook-Suche verwendet den Windows Search-Index (oder den Exchange/Microsoft-365-Index auf Serverseite). Dieser Index wird auf Basis des INTERNALDATE aufgebaut, nicht des Date:-Headers. Sucht ein Nutzer nach "E-Mails aus Januar 2022", liefert die Suche die E-Mails zurück, deren INTERNALDATE im Januar 2022 liegt. Nicht die, deren Date:-Header auf Januar 2022 verweist. Das Ergebnis: Ältere E-Mails tauchen in Datumsfiltern nicht mehr auf. Das Ändern der Anzeigespalte ändert daran nichts.

Postfachregeln

Outlook-Regeln ("wenn die E-Mail vor dem... empfangen wurde", "wenn die E-Mail nach dem... empfangen wurde") verwenden ebenfalls das INTERNALDATE. Eine Sortier- oder Archivierungsregel auf Basis von Datumsbereichen funktioniert nach der Migration nicht mehr korrekt, wenn das INTERNALDATE nicht korrigiert wurde.

Compliance und eDiscovery

Das ist möglicherweise der kritischste Punkt. Compliance-Tools, rechtliche Archivierungssysteme und eDiscovery-Lösungen (zum Beispiel Microsoft Purview) verwenden das INTERNALDATE als Datumsbezug für rechtliche Anfragen. Wenn Ihr Unternehmen Aufbewahrungspflichten unterliegt oder auf Auskunftsersuchen reagieren muss, können korrumpierte INTERNALDATE-Werte ernsthafte rechtliche Probleme verursachen. Ein Audit, das "alle E-Mails zwischen diesem und jenem Datum" anfordert, liefert dann schlicht die falschen Ergebnisse. In Deutschland sind solche Aufbewahrungspflichten unter anderem durch die GoBD und das Handelsgesetzbuch (HGB) geregelt.

Drittanbieter-Tools

CRM-Systeme, Ticketing-Tools, Archivierer... alles, was sich per IMAP oder über die Microsoft-365/Google-Workspace-APIs mit Ihrem Mailserver verbindet, liest das INTERNALDATE. Das Ändern der Outlook-Ansicht korrigiert für diese Systeme gar nichts.

Die einzige echte Lösung: Korrektur auf Serverebene

Die Sortierung nach Sendedatum in Outlook ist keine Lösung. Es ist ein Pflaster. Die eigentliche Korrektur muss auf Ebene der Servermetadaten erfolgen, nicht in der Client-Ansicht.

Konkret bedeutet das: Das INTERNALDATE jeder einzelnen E-Mail muss so korrigiert werden, dass es dem ursprünglichen Datum im Date:-Header entspricht. Der originale Date:-Header ist nach wie vor in der Nachricht vorhanden (die Migration hat ihn nicht gelöscht), was die Korrektur überhaupt erst möglich macht. Dort steckt die echte Datumsinformation.

Bei Google Workspace stellt die Gmail-API einen internalDate-Parameter zur Verfügung, über den direkt auf diese Metadaten zugegriffen werden kann. Bei Microsoft 365 ist der Mechanismus anders, das erwartete Ergebnis aber dasselbe. Auf einem Standard-IMAP-Server sieht die Spezifikation vor, dass das Datum beim Einfügen einer Nachricht angegeben werden kann.

In der Praxis diese Operation an zehntausenden von E-Mails in einer Produktivumgebung durchzuführen, ohne Datenverlust, ohne Duplikate, ohne Gesprächsverläufe oder Labels zu zerstören, unter Berücksichtigung von Sonderfällen (S/MIME-signierte Nachrichten, komplexe MIME-Strukturen, Nicht-ASCII-Encodierungen nach RFC 2047, große Anhänge, teils durch die Migration bereits korrumpierte MIME-Strukturen)... das ist eine ganz andere Geschichte. Ein Skript, das auf 50 Test-E-Mails funktioniert, hält einem Postfach mit 40.000 Nachrichten nicht stand. Die Behandlung von 429-Fehlern (API-Quota überschritten), Netzwerk-Timeouts um 2 Uhr nachts, Nachrichten mit bereits partiell beschädigter MIME-Struktur nach der Migration... all das erfordert ernsthaftes Engineering.

Genau das ist die Aufgabe von Redate.io. Die proprietäre Korrektur-Engine analysiert die Header-Kette jeder einzelnen E-Mail, identifiziert das zuverlässige Originaldatum und wendet eine gezielte Metadatenkorrektur an, ohne den Nachrichteninhalt zu verändern. Jede korrigierte E-Mail wird einzeln überprüft. Die Originale werden 30 Tage lang in einem Sicherungsordner aufbewahrt, was jederzeit ein Rollback ermöglicht. Das bietet kein selbst geschriebenes Skript.

Das verantwortliche Migrationstool identifizieren

Das Problem tritt unabhängig vom Ursprung der Migration ähnlich auf, aber die Details variieren je nach verwendetem Tool. BitTitan MigrationWiz, CloudM, imapsync und GSMMO hinterlassen jeweils ihre eigene Signatur in den Received:-Headern, die sie injizieren. Die Analyse-Pipeline von Redate.io pflegt eine Zuordnungsdatenbank mit hunderten Signaturen bekannter Migrationstools, um den Migrations-Header vom legitimen Transit-Chain zu unterscheiden.

Falls Sie nicht wissen, welches Tool für Ihre Migration verwendet wurde (das kommt vor, besonders wenn Sie ein Netzwerk von einem anderen MSP übernehmen), identifiziert der kostenlose Scan von Redate.io die betroffenen Postfächer und liefert eine Schätzung des Korrekturvolumens, bevor Sie irgend etwas beauftragen.

Für spezifische Szenarien stehen detaillierte Anleitungen zur Verfügung: imapsync-Daten in Outlook korrigieren, BitTitan-Daten in Outlook korrigieren oder CloudM-Daten in Outlook korrigieren.

Was jetzt zu tun ist

Wenn Sie diesen Artikel nach einer Migration lesen, ist die gute Nachricht: Der originale Date:-Header ist in jeder Ihrer E-Mails intakt. Die echten Datumsinformationen sind vorhanden, in jeder einzelnen Nachricht. Das Problem steckt in den Metadaten, nicht im Inhalt. Und Metadaten lassen sich korrigieren.

Für einen tieferen Einblick in die technischen Hintergründe empfiehlt sich der Artikel IMAP INTERNALDATE: Warum Datumsangaben kaputtgehen, oder der vollständige Leitfaden zu falschen Datumsangaben in Outlook nach der Migration für einen umfassenden Überblick über die verschiedenen Szenarien.

Bereit, die Datumsangaben Ihrer Postfächer zu korrigieren? Starten Sie einen kostenlosen Scan auf Redate.io, um betroffene E-Mails zu identifizieren und das Korrekturvolumen zu schätzen, bevor Sie irgendetwas in Auftrag geben.