PST-Import in Outlook: Warum alle Daten auf heute springen

Das Symptom: Alle Ihre E-Mails tragen das heutige Datum

Sie haben gerade einen PST-Import in Outlook abgeschlossen. Der Fortschrittsbalken hat 100 % erreicht, alles lief reibungslos. Dann öffnen Sie den Posteingang... und jede importierte E-Mail zeigt das heutige Datum. Eine Nachricht von 2019, eine andere von 2021, ein fünf Jahre altes Archiv: alle tragen dasselbe Datum. Das Datum des Imports.

Das ist kein Anzeigefehler. Das ist kein Zeitzonenproblem. Es ist ein vollständig dokumentiertes Verhalten, das damit zusammenhängt, wie IMAP Datums-Metadaten verwaltet. Für jeden, der alte E-Mails nach Datum suchen muss, ist es dennoch eine Katastrophe.

Lokale PST-Datei und IMAP: zwei völlig unterschiedliche Welten

Bevor erklärt werden kann, warum die Daten kaputtgehen, muss man verstehen, was eine PST-Datei aus Sicht der Datumsverwaltung eigentlich ist.

Eine PST-Datei (Personal Storage Table) ist ein proprietäres Microsoft-Format. Sie speichert E-Mails mit allen Metadaten: Sendedatum, Empfangsdatum, Anhänge, Kategorien, Lesemarkierungen. Diese Metadaten werden direkt von Outlook verwaltet, unabhängig von jedem Mailprotokoll. Wenn Sie eine PST-Datei in Outlook öffnen, ohne mit einem Server verbunden zu sein, stammen die angezeigten Daten direkt aus den internen Feldern der PST-Datei. So weit, so gut.

Das Problem entsteht, wenn Sie diesen Inhalt in ein auf einem IMAP-Server gehostetes Postfach übertragen wollen, sei es Microsoft 365, Google Workspace oder ein gewöhnlicher Hosting-Anbieter. Damit verlassen Sie die PST-Welt und betreten die IMAP-Welt, wo vollkommen andere Regeln gelten.

IMAP APPEND und das INTERNALDATE: der Kern des Problems

In IMAP hat jede auf dem Server gespeicherte Nachricht zwei Arten von Datumsdaten:

• Den Date:-Header (RFC 2822), der Teil des Nachrichteninhalts selbst ist. Das ist das Datum, das der Absender in die Nachricht eingetragen hat.
• Das INTERNALDATE, eine vom IMAP-Server verwaltete Metadaten. Es gibt den Zeitpunkt an, zu dem die Nachricht auf dem Server abgelegt wurde. Genau diesen Wert nutzt Outlook, um Nachrichten in der Ansicht "Empfangsdatum" zu sortieren.

(Wenn Sie schon einmal versucht haben, rohe E-Mail-Header zu lesen, wissen Sie, dass das nicht gerade Urlaubslektüre ist. Aber genau dort passiert alles Entscheidende.)

Wenn eine E-Mail normal auf Ihrem Server eingeht, setzt der Mailserver das INTERNALDATE automatisch auf den genauen Zeitpunkt des Eingangs. Das angezeigte Datum in Outlook entspricht also dem tatsächlichen Empfangszeitpunkt.

Wenn Outlook eine PST-Datei in ein IMAP-Postfach importiert, verwendet es den Befehl IMAP APPEND, um jede Nachricht an den Server zu senden. Der IMAP-Standard erlaubt es, beim APPEND ein explizites INTERNALDATE zu übergeben. Outlook tut das aber nicht. Die Nachrichten werden ohne Angabe eines INTERNALDATE gesendet. Der IMAP-Server wendet daraufhin seine Standardregel an: Das INTERNALDATE wird auf die aktuelle Zeit gesetzt, also den Zeitpunkt des Imports.

Ergebnis: 8.000 importierte E-Mails, 8.000 E-Mails mit dem heutigen Datum.

Warum Outlook sich so verhält

Das ist kein Versehen von Microsoft. Es ist eine Implementierungsentscheidung, die damals wohl sinnvoll erschien: Im ursprünglichen Anwendungsfall des PST-Imports archiviert ein Nutzer Nachrichten lokal und importiert sie in sein aktuelles Postfach. Das relevante Datum für die Sortierung wäre dann das ursprüngliche Empfangsdatum... aber Microsoft hat entschieden, das INTERNALDATE bei diesem Vorgang nicht zu übernehmen.

Um es genau zu sagen: Dieses Verhalten betrifft den PST-Import über den nativen Outlook-Assistenten (Datei > Öffnen und Exportieren > Importieren/Exportieren). Andere Importmethoden, etwa bestimmte Drittanbieter-Tools oder Migrationen über das Exchange Admin Center, können sich je nach ihrer IMAP APPEND-Implementierung anders verhalten.

Dieses Verhalten ist seit Jahren in den Microsoft-Foren bekannt und dokumentiert. Es hat sich weder mit Outlook 2016 noch mit Outlook 2019 geändert, und auch die aktuellen Microsoft-365-Versionen zeigen dasselbe Problem. Wer heute einen PST-Import durchführt, begegnet exakt demselben Problem wie 2015.

Was diesen Fall von einer klassischen IMAP-Migration unterscheidet

Hier wird es interessant: Ein PST-Import erzeugt ein ähnliches Ergebnis wie eine klassische IMAP-Migration mit kaputten Daten, aber durch einen anderen Mechanismus.

Bei einer typischen IMAP-Migration, zum Beispiel mit BitTitan MigrationWiz oder imapsync, wechseln E-Mails von einem IMAP-Quellserver zu einem IMAP-Zielserver. Das Migrationstool ruft die Nachrichten ab und fügt sie via IMAP APPEND wieder ein. Manche Tools übernehmen das INTERNALDATE korrekt, andere nicht. In jedem Fall enthalten die Nachrichten dabei bereits einen Received:-Header mit dem Migrationsdatum, was die Anzeige in Outlook unabhängig vom INTERNALDATE stören kann.

Beim PST-Import ist der Mechanismus einfacher: Es wird kein Migrations-Received:-Header hinzugefügt (PST-Dateien laufen nicht über einen zwischengeschalteten Mailserver), aber das INTERNALDATE wird schlicht nie auf den richtigen Wert gesetzt. Das sichtbare Ergebnis ist identisch, die eigentliche Ursache leicht verschieden.

Dieser Unterschied hat direkte Auswirkungen auf die Korrektur: Der Ansatz ist je nachdem, ob man eine IMAP-Migration oder einen PST-Import behandelt, nicht ganz derselbe. Mehr dazu im Artikel IMAP INTERNALDATE: Warum Datumsangaben kaputtgehen.

Warum die Outlook-Ansichtsoptionen nichts beheben

Die typische erste Reaktion bei diesem Problem: in den Outlook-Einstellungen suchen. Tatsächlich gibt es eine Option, die vielversprechend klingt: E-Mails nach "Datum" statt nach "Empfangsdatum" sortieren.

Die Sortierung nach Sendedatum ist keine Lösung. Das ist ein Pflaster.

Warum? Selbst wenn Sie die Sortierung auf die Spalte "Datum" umstellen (die dem Date:-Header der Nachricht entspricht, also dem ursprünglichen Datum), bleiben mehrere Probleme bestehen:

• Die Outlook-Suche indiziert auf Basis des INTERNALDATE. Eine Suche nach "E-Mails aus Januar 2020" liefert die importierten Nachrichten vom Januar 2020 nicht, weil deren INTERNALDATE auf den Tag des Imports verweist.
• Die Gruppierungen "Heute", "Diese Woche", "Dieser Monat" in der Outlook-Oberfläche basieren auf dem INTERNALDATE, nicht auf dem Date:-Header.
• In Weboberflächen (Outlook Web App, Gmail) und auf mobilen Clients richtet sich das angezeigte Datum und das Sortierverhalten fast immer nach dem INTERNALDATE des Servers.
• Automatische Regeln und Filter, die auf dem Empfangsdatum basieren, arbeiten nicht mehr korrekt.

Kurz gesagt: Die Ansicht umzustellen löst das Anzeigeproblem für einen bestimmten Nutzer, auf einem bestimmten Client, in einer bestimmten Konfiguration. Die eigentliche Ursache wird nicht behoben.

Auch eine OST-Neusynchronisierung hilft nicht

Ein weiterer klassischer Versuch: den OST-Cache leeren und eine vollständige Neusynchronisierung vom Server erzwingen. Die Idee dahinter: Vielleicht liegt das Problem am lokalen Outlook-Cache, nicht am Server.

Falsche Fährte. Die OST-Datei ist ein lokaler Cache, der den Zustand des IMAP-Servers widerspiegelt. Wenn das INTERNALDATE auf dem Server falsch ist, ist es nach der Neusynchronisierung auch im OST falsch. Das Löschen der OST-Datei ändert nichts an den auf Exchange Online oder Google Workspace gespeicherten Daten. Der Server ist die maßgebliche Quelle.

Die einzige Möglichkeit, die Daten zu korrigieren, besteht darin, die Metadaten direkt auf Serverseite, Nachricht für Nachricht, zu korrigieren. Und genau hier wird es manuell schnell sehr kompliziert.

Das Skalierungsproblem: 1 E-Mail ist trivial. 15.000 sind eine andere Geschichte

Technisch gesehen könnte man, wenn man das Problem versteht, ein Skript schreiben, das das Postfach durchläuft, den Date:-Header jeder Nachricht ausliest und das INTERNALDATE entsprechend korrigiert. Das Problem zu verstehen ist das eine. Es bei 15.000 E-Mails ohne einen einzigen Verlust zu beheben, ist etwas völlig anderes.

Einige Realitäten aus der Praxis:

• Die Microsoft-Graph-API und die Gmail-API haben Ratenlimits. Ein naives Skript löst 429-Too-Many-Requests-Fehler aus, bricht mitten in der Korrektur ab und hinterlässt ein teilweise korrigiertes Postfach, ohne dass klar ist, welche E-Mails bereits bearbeitet wurden und welche nicht.
• Manche E-Mails in einer PST-Datei können fehlerhafte oder fehlende Date:-Header haben. Ein Skript ohne Behandlung dieser Grenzfälle kann diese Nachrichten beschädigen oder stillschweigend überspringen.
• Signierte E-Mails (S/MIME) oder verschlüsselte Nachrichten (PGP) haben zusätzliche Integritätsanforderungen. Werden ihre Metadaten unvorsichtig verändert, kann die kryptografische Signatur ungültig werden.
• Multipart/alternative-Strukturen mit komplexen MIME-Grenzen reagieren auf Änderungen manchmal unvorhersehbar.
• Kein Rollback-Mechanismus. Wenn etwas mitten in der Verarbeitung schiefläuft, wie kehren Sie zum Ausgangszustand zurück?

Ein Skript, das mit 10 Test-E-Mails funktioniert, wird auf einem Produktionspostfach mit 50.000 Nachrichten nicht funktionieren. Letztes Jahr hat ein Kunde mit einem 40-GB-PST-Archiv versucht, das Problem mit einem Python-Skript von Stack Overflow zu lösen. Ergebnis: 3.000 doppelte E-Mails, 200 Nachrichten mit nicht mehr zugänglichen Anhängen und zwei Wochen manuelle Bereinigungsarbeit.

Was Redate.io in diesem konkreten Fall tut

Redate.io analysiert die Metadaten jeder Nachricht im Zielpostfach, identifiziert E-Mails mit falschen Daten (einschließlich solcher aus einem PST-Import) und wendet eine Korrektur über seine proprietäre Korrektur-Engine an. Die mehrstufige Analyse-Pipeline vergleicht die Header-Kette jeder Nachricht, extrahiert das ursprüngliche Datum mit RFC-Konformitätsprüfung und führt eine gezielte Metadatenkorrektur durch, ohne den Nachrichteninhalt zu verändern.

Jede korrigierte E-Mail wird einzeln geprüft. Die Originale werden in einem sichtbaren Sicherungsordner 30 Tage lang aufbewahrt, bevor eine endgültige Änderung vorgenommen wird. Die Korrektur funktioniert auf den drei wichtigsten Plattformen: Microsoft 365 (über Azure AD), Google Workspace (über Domain-Delegation) und direktes IMAP für klassische Hosting-Anbieter.

Der erste Scan ist kostenlos. Er zeigt genau, wie viele E-Mails betroffen sind und wie die Verteilung der falschen Daten aussieht, bevor Sie sich zu irgendetwas entscheiden müssen.

Weitere Artikel:

• E-Mail-Daten nach Microsoft-365-Migration korrigieren
• Outlook: IMAP-Empfangsdatum vs. Sendedatum nach Migration
• Können E-Mail-Daten nach der Migration korrigiert werden?

Hat Ihr PST-Import alle E-Mail-Daten überschrieben? Scannen Sie Ihr Postfach kostenlos auf Redate.io und messen Sie das Ausmaß des Problems, bevor Sie handeln.