eM Client: falsche Daten nach PST- oder Thunderbird-Import

Das Symptom: alle E-Mails tragen dasselbe Datum

Sie haben gerade einen PST-Import in eM Client abgeschlossen, oder Sie haben von Thunderbird zu Ihrem neuen Postfach migriert. Der Import verlief scheinbar fehlerfrei. Aber beim Öffnen des Posteingangs stimmt etwas nicht: Hunderte, manchmal Tausende von E-Mails zeigen alle dasselbe Datum, nämlich das des Importtags. Eine E-Mail aus dem Jahr 2019 sieht aus, als wäre sie gestern angekommen. Ein vor drei Jahren unterzeichneter Vertrag erscheint, als hätte er gerade Ihr Postfach erreicht.

Die erste Reaktion ist verständlich: eM Client ist schuld. Falsche Einstellung, falsche Sortierspalte, Anzeigefehler... Man sucht in den Einstellungen. Man wechselt zwischen "Empfangsdatum" und "Sendedatum". Nichts ändert sich. Oder genauer: etwas ändert sich, aber das eigentliche Problem bleibt bestehen.

Das liegt daran, dass das Problem nicht in eM Client steckt. Es liegt in den Metadaten auf dem Server.

Die eigentliche Ursache: das überschriebene IMAP INTERNALDATE

Um zu verstehen, was passiert, muss man eine Ebene tiefer schauen und sich ansehen, wie das IMAP-Protokoll E-Mails speichert.

Jede Nachricht auf einem IMAP-Server besitzt zwei unterschiedliche Datumstypen:

• Der Date:-Header (gemäß RFC 2822): Das ist das Datum, das der Absender beim Versand in die Nachricht eingetragen hat. Es ist im Nachrichteninhalt eingebettet und theoretisch unveränderlich.
• Das INTERNALDATE: eine Server-seitige Metadaten-Angabe, die außerhalb der Nachricht liegt und den Zeitpunkt angibt, zu dem die Nachricht im Postfach abgelegt wurde. Genau dieser Wert wird von E-Mail-Clients vorrangig zum Sortieren und Anzeigen verwendet.

Beim PST-Import oder einer Migration von Thunderbird legt das Import-Werkzeug (ob das native eM-Client-Modul, ein Drittanbieter-Tool oder eine manuelle IMAP-Kopie) die Nachrichten auf dem Ziel-IMAP-Server ab. Wenn das Werkzeug beim Ablegen das ursprüngliche INTERNALDATE nicht explizit erhält, weist der Server automatisch das aktuelle INTERNALDATE zu, also Datum und Uhrzeit des Imports.

Ergebnis: 8.000 seit 2017 archivierte E-Mails, alle mit dem Stempel "empfangen" zum Zeitpunkt der Migration.

(Übrigens: Wenn Sie jemals versucht haben, die Rohheader einer E-Mail über Quelle anzeigen in eM Client zu lesen, haben Sie vielleicht festgestellt, dass der ursprüngliche Date:-Header noch vorhanden und intakt ist. Das ist ein klares Zeichen, dass das Problem vom Server-INTERNALDATE kommt, nicht von der Nachricht selbst.)

Warum das Ändern der Sortierspalte nichts bringt

Die Verwirrung entsteht durch eine Unterscheidung, die kaum jemand kennt. In eM Client gibt es, wie in Outlook oder Thunderbird, typischerweise zwei Datumsspalten:

• "Empfangsdatum" (oder "Eingangsdatum"): basiert auf dem Server-INTERNALDATE.
• "Datum" oder "Sendedatum": basiert auf dem Date:-Header der Nachricht.

Viele Admins entdecken das und glauben, die Lösung gefunden zu haben: auf "Sendedatum" umstellen, und das Problem verschwindet in eM Client optisch. Aber das stimmt nicht ganz.

Genauer gesagt: Auch wenn Sie in eM Client nach Sendedatum sortieren, besteht das Problem für alle anderen Clients und Oberflächen, die auf dasselbe Postfach zugreifen. Wenn Ihre Nutzerinnen und Nutzer ihre E-Mails über OWA, Outlook im Büro, die Gmail-App auf dem Smartphone oder irgendeinen anderen IMAP-Client aufrufen, sehen sie die Importdaten. Die Sortiereinstellung in eM Client gilt nur für eM Client und verändert die serverseitig gespeicherten Metadaten in keiner Weise.

Dazu kommt: Auf Microsoft 365 und Google Workspace sortiert die native Web-Oberfläche nach INTERNALDATE. Dieses Verhalten lässt sich vom Client aus nicht ändern.

Die Sortierung nach Sendedatum ist keine Lösung. Es ist ein Pflaster, das ein echtes Problem kaschiert, ohne es zu beheben.

Der Sonderfall PST-Import

PST-Importe verdienen einen eigenen Abschnitt. Eine PST-Datei (Personal Storage Table) ist ein proprietäres Microsoft-Format, das E-Mails, Kontakte und Kalendereinträge lokal speichert. Beim Import einer PST in eM Client gibt es zwei Szenarien:

• Lokaler Import auf ein IMAP-Konto: eM Client liest die PST und überträgt die Nachrichten auf den Ziel-IMAP-Server. Wird das Ablage-Datum dabei nicht erhalten, wird das INTERNALDATE überschrieben. Das ist der häufigste Fall und der Punkt, an dem die Daten korrumpiert werden.
• Import in einen lokalen Ordner: Die Nachrichten verbleiben auf dem Gerät, außerhalb des Servers. Das INTERNALDATE existiert in diesem Kontext nicht, und eM Client kann das Date:-Datum der Nachricht anzeigen. Hier weniger Datumsprobleme, aber auch weniger praktischer Nutzen.

Bei Thunderbird ist die Situation ähnlich. Egal ob Sie die integrierte Importfunktion von eM Client verwenden (die Thunderbird-Profile liest) oder mbox-Ordner per IMAP kopiert haben: Die Nachrichten werden ohne Garantie der INTERNALDATE-Erhaltung auf dem Server abgelegt. Und ein Server, der eine Nachricht ohne explizite Datumsanweisung für das INTERNALDATE erhält, stempelt sie konsequent mit dem Empfangszeitpunkt.

Welche Plattformen sind betroffen?

Das Problem tritt unabhängig von der Zielplattform auf, weil es sich um ein Standardverhalten des IMAP-Protokolls handelt:

• Microsoft 365 / Exchange Online: Das INTERNALDATE wird bei jedem Import überschrieben, der den IMAP-APPEND-Befehl nicht mit einem expliziten Datumsparameter verwendet. Dasselbe gilt für Migrationen von Exchange on-premise.
• Google Workspace: Gleiches Verhalten. Per eM Client oder Drittanbieter-Tools importierte E-Mails zeigen in Gmail und in der Admin-Oberfläche das Importdatum.
• Klassische IMAP-Hoster (IONOS, Strato, 1&1, Netcup u. a.): Kein besonderes Datum-Handling beim Empfang einer APPEND-Nachricht. Das INTERNALDATE ist das Ablage-Datum.

Ein Kunde meldete sich, nachdem er rund hundert Postfächer von Exchange 2013 zu Microsoft 365 migriert hatte, mit eM Client als Übergangswerkzeug für einige VIP-Konten. Ergebnis: Die über MigrationWiz migrierten Postfächer waren einwandfrei, aber alle über eM Client migrierten Postfächer zeigten ausnahmslos die Importdaten. Die betroffenen Nutzerinnen und Nutzer haben das nicht gerade mit Begeisterung aufgenommen.

Warum ein selbstgebautes Skript das nicht einfach löst

Technisch gesehen könnte jemand, der das IMAP-Protokoll versteht, auf die Idee kommen, ein Skript zur Korrektur der INTERNALDATEs zu schreiben. Der ursprüngliche Date:-Header ist ja vorhanden, in jeder Nachricht intakt. Man müsste ihn nur auslesen und die Server-Metadaten entsprechend rekonstruieren, oder?

In der Theorie ja. In der Praxis ist das ein Minenfeld.

Zunächst häufen sich die Grenzfälle auf einem Produktions-Postfach schnell. Digital signierte S/MIME-Nachrichten reagieren besonders empfindlich auf jede Strukturmanipulation. PGP-verschlüsselte Nachrichten ebenso. E-Mails mit großen Anhängen, nicht-standardisierten MIME-Grenzen oder ungewöhnlichen Content-Transfer-Encoding-Angaben können sich bei nachlässiger Verarbeitung still und leise korrumpieren. Ein Skript, das bei 50 Test-E-Mails funktioniert, wird bei einem Postfach mit 20.000 Nachrichten und 6 Jahren Geschichte nicht zuverlässig arbeiten.

Dann das API-Quota-Management. Auf Microsoft 365 lassen sich die Rate-Limits der Graph API oder von EWS um 3 Uhr morgens bei einem Korrektur-Batch von 8.000 Nachrichten grundsätzlich handhaben. Aber nicht von allein. Ein unbeaufsichtigtes Skript, das bei Nachricht Nr. 3.741 auf einen 429-Too-Many-Requests-Fehler trifft, läuft vielleicht weiter, vielleicht auch nicht. Und welche Nachrichten tatsächlich verarbeitet wurden, wissen Sie im Zweifel nicht.

Und vor allem: Wie stellen Sie sicher, dass jede korrigierte E-Mail nach der Verarbeitung intakt ist? Ein selbstgebautes Skript hat in der Regel keinen Mechanismus zur Einzelprüfung. Redate.io macht das automatisch, für jede einzelne Nachricht.

Daten an der Quelle korrigieren mit Redate.io

Redate.io greift das Problem dort an, wo es entsteht: auf Ebene der Server-Metadaten, nicht auf Ebene des E-Mail-Clients.

Der Prozess beginnt mit einem kostenlosen Scan. Redate.io verbindet sich mit dem betroffenen Postfach (Microsoft 365 über Azure AD, Google Workspace über Domänendelegierung oder direktes IMAP für klassische Hoster) und erkennt E-Mails, deren Datumsmetadaten nicht mit dem Nachrichteninhalt übereinstimmen. Das Ergebnis sehen Sie, bevor Sie irgendetwas bezahlen.

Die Korrektur nutzt ein proprietäres Analyse-System, das die vollständige Header-Kette jeder Nachricht untersucht, Muster gegen Hunderte bekannter Import-Tool-Signaturen abgleicht (einschließlich der spezifischen Verhaltensweisen von eM Client, Thunderbird und PST-Importen) und die Datumsmetadaten gezielt rekonstruiert, ohne den Nachrichteninhalt, die Anhänge oder die MIME-Struktur zu verändern.

Jede korrigierte E-Mail wird einzeln überprüft. Die Originale werden 30 Tage lang in einem sichtbaren Sicherungsordner aufbewahrt, was ein selbstgebautes Skript standardmäßig nie tun würde.

Die Preisgestaltung ist unkompliziert: einmalige Zahlung pro Postfach, basierend auf dem Volumen der zu korrigierenden E-Mails. Kein Abo, keine laufenden Kosten. Details finden Sie auf der Startseite.

Für die nächste Migration: was Sie prüfen sollten

Wenn Sie eine Migration planen und dieses Problem im Vorfeld vermeiden möchten, ist die entscheidende Frage einfach: Erhält das verwendete Werkzeug das INTERNALDATE beim Ablegen der Nachrichten auf dem Zielserver explizit?

Für PST-Importe nach Microsoft 365 verwalten von Microsoft zertifizierte Werkzeuge (wie MigrationWiz in den nativen Modi oder das Exchange-Online-Migrationstool) diese Erhaltung in der Regel korrekt. Bei manuellen Importen über eM Client oder Thunderbird ist das selten der Fall. Prüfen Sie die Dokumentation Ihres Werkzeugs, bevor Sie einen Import auf Produktions-Postfächern starten.

Eine gute Checkliste für E-Mail-Migrationen enthält immer eine Datum-Überprüfung nach der Migration auf einer Stichprobe von Postfächern. Admins, die regelmäßig Migrationen für Kunden durchführen, finden weitere Details im Artikel über die Datumskorrektur aus MSP-Sicht sowie in der Erklärung zum IMAP INTERNALDATE und seinen Tücken.

Sind die Daten Ihrer E-Mails nach einem eM-Client-Import korrumpiert? Starten Sie einen kostenlosen Scan auf Redate.io und messen Sie das Ausmaß des Problems, bevor Sie entscheiden, was zu tun ist.