Die drei Daten in jeder E-Mail
Jede auf einem IMAP-Server gespeicherte E-Mail trägt mindestens drei verschiedene Datumswerte. Zu verstehen, wie diese Daten funktionieren und wie E-Mail-Clients entscheiden, welches sie anzeigen, ist der Schlüssel zum Verständnis, warum die Migration Daten kaputt macht. Dieser Artikel ist eine technische Tiefenanalyse des IMAP-Datumssystems, gedacht für IT-Administratoren und alle, die die eigentliche Ursache von Datumsproblemen nach der Migration verstehen wollen.
1. Der RFC-2822-"Date"-Header
Der "Date"-Header ist in RFC 2822 (Internet-Nachrichtenformat) definiert. Er wird vom E-Mail-Client des Absenders zum Zeitpunkt der Erstellung und des Sendens der Nachricht gesetzt. Dieser Header ist Teil des Nachrichtentexts selbst - er reist mit der Nachricht und wird von den Mailservern auf dem Zustellweg nie verändert. Ein typischer Date-Header sieht so aus:
Date: Mon, 15 Jan 2024 09:32:17 +0100
Der Date-Header stellt das "Sendedatum" der Nachricht dar. Es ist das zuverlässigste Datum, da es einmal gesetzt und nie verändert wird. Allerdings spiegelt es die Uhr des Absenders wider, die falsch konfiguriert sein kann. In seltenen Fällen kann der Date-Header komplett fehlen (besonders bei automatisierten Systembenachrichtigungen oder fehlerhaften Nachrichten).
2. Das IMAP INTERNALDATE
Das INTERNALDATE ist in RFC 3501 (IMAP4rev1-Protokoll) definiert. Es ist ein serverseitiger Metadatenwert, der das Datum und die Uhrzeit darstellt, zu der die Nachricht an den Server zugestellt wurde. Anders als der Date-Header ist das INTERNALDATE nicht Teil der E-Mail-Nachricht selbst. Es wird separat vom IMAP-Server als Metadatum gespeichert.
Wenn eine E-Mail normal zugestellt wird (nicht migriert), setzt der IMAP-Server das INTERNALDATE auf die aktuelle Uhrzeit zum Zeitpunkt der Zustellung. Dieser Wert entspricht dem Date-Header eng, in der Regel bis auf wenige Sekunden oder Minuten. E-Mail-Clients verwenden das INTERNALDATE oft als "Empfangsdatum", da es widerspiegelt, wann der Server die Nachricht tatsächlich empfangen hat.
Und hier wird es interessant. Wenn eine Nachricht per IMAP-APPEND-Befehl eingefügt wird (was Migrationswerkzeuge verwenden), erlaubt der APPEND-Befehl dem Client, das INTERNALDATE explizit anzugeben. Gut konzipierte Migrationswerkzeuge nutzen diese Funktion, um das ursprüngliche INTERNALDATE vom Quellserver zu erhalten. Aber selbst wenn das INTERNALDATE korrekt gesetzt wird, kann das "Received"-Header-Problem (unten beschrieben) das angezeigte Datum in vielen Clients trotzdem überschreiben.
3. Die "Received"-Header-Kette
Jedes Mal, wenn eine E-Mail einen Mailserver passiert, fügt dieser Server einen "Received"-Header am Anfang der Nachricht ein. Das erzeugt eine Kette von Received-Headern, die den Weg der E-Mail vom Absender zum Empfänger aufzeichnet. Der neueste (oben) zeigt den letzten Server, der die Nachricht verarbeitet hat, und der älteste (unten) den ersten.
Eine normale E-Mail kann 3 bis 6 Received-Header haben, die die Reise vom Ausgangsserver des Absenders über Relays zum Eingangsserver des Empfängers dokumentieren. Jeder Received-Header enthält einen Zeitstempel. Hier ein vereinfachtes Beispiel:
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Wie E-Mail-Clients entscheiden, welches Datum sie anzeigen
Outlook (Desktop, Web, Mobil)
Microsoft Outlook verwendet eine Kombination aus dem INTERNALDATE und dem neuesten "Received"-Header, um das in der Inbox angezeigte "Empfangsdatum" zu bestimmen. In der Praxis tendiert Outlook dazu, den Zeitstempel des neuesten Received-Headers für die Spalte "Empfangen" zu bevorzugen. Die Spalte "Gesendet" verwendet den Date-Header. Da Outlook standardmäßig nach der Spalte "Empfangen" sortiert, ist es der Received-Header-Zeitstempel, den die Benutzer zuerst sehen.
Apple Mail
Apple Mail auf macOS und iOS verwendet hauptsächlich das IMAP-INTERNALDATE zur Datumsanzeige. Wenn das INTERNALDATE während der Migration korrekt erhalten wurde, kann Apple Mail das richtige Datum anzeigen - aber nur, wenn das INTERNALDATE beim APPEND-Vorgang explizit gesetzt wurde. Wenn das Migrationswerkzeug das INTERNALDATE nicht gesetzt hat, verwendet der Server standardmäßig die Einfügezeit (das Migrationsdatum). Für Details zur Auswirkung auf Apple-Mail-Benutzer siehe Apple Mail: Falsches Datum nach der Migration.
Thunderbird
Mozilla Thunderbird bietet die meiste Flexibilität. Es kann sowohl "Datum" (aus dem Date-Header) als auch "Empfangen" (aus den Received-Headern) anzeigen. Standardmäßig zeigt Thunderbird den Wert des Date-Headers, was bedeutet, dass Daten in Thunderbird korrekt erscheinen können, selbst wenn sie in Outlook falsch sind. Die Spalte "Empfangen" in Thunderbird zeigt immer das Migrationsdatum. Siehe Thunderbird: Falsches Datum nach der Migration für weitere Details.
Gmail-Weboberfläche
Der Gmail-Webclient verwendet den Date-Header für seine primäre Datumsanzeige. Das bedeutet, dass Gmail Web oft korrekte Daten zeigt, auch nach der Migration. Aber das IMAP-INTERNALDATE auf dem Gmail-Server ist trotzdem falsch, was jeden IMAP-Client betrifft, der sich mit diesem Gmail-Konto verbindet. Der Unterschied zwischen Gmail Web und Outlook oder Apple Mail ist eine häufige Verwirrungsquelle - und eine, die Administratoren viel Zeit bei der Fehlersuche kostet.
Warum IMAP APPEND Daten kaputt macht
Was während der Migration passiert
Wenn ein Migrationswerkzeug eine E-Mail von Server A zu Server B verschiebt, verbindet sich das Werkzeug per IMAP mit Server A, lädt die Rohnachricht herunter, verbindet sich dann mit Server B und fügt sie per APPEND-Befehl ein. Während dieses Einfügens behandelt Server B die eingehende Nachricht und fügt einen neuen Received-Header mit dem aktuellen Zeitstempel hinzu: dem Migrationsdatum. Das ist standardmäßiges IMAP-Verhalten, definiert im Protokoll. Der Server behandelt jeden APPEND als neue Nachrichtenzustellung.
Das Ergebnis: eine kontaminierte Header-Kette
Nach der Migration sehen die Received-Header der E-Mail so aus:
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Der Received-Header des Migrationswerkzeugs ist jetzt der oberste Eintrag. Jeder E-Mail-Client, der den neuesten Received-Header zur Bestimmung des Anzeigedatums verwendet (Outlook, insbesondere), zeigt "11. April 2025" statt "15. Januar 2024" an. Der ursprüngliche Date-Header und die ursprünglichen Received-Header sind darunter weiterhin intakt, aber sie befinden sich nicht mehr in der Position, die E-Mail-Clients bevorzugen.
Selbst gute INTERNALDATE-Behandlung verhindert das nicht
Einige Migrationswerkzeuge setzen das INTERNALDATE während des APPEND korrekt. Zum Beispiel erhält imapsync das INTERNALDATE des Quellservers explizit. Aber der Received-Header wird vom Zielserver hinzugefügt, nicht vom Migrationswerkzeug. Das Migrationswerkzeug hat keine Kontrolle über dieses Verhalten. Selbst bei perfekter INTERNALDATE-Erhaltung enthält der oberste Received-Header weiterhin das Migrationsdatum, und Clients wie Outlook zeigen weiterhin das falsche Datum an.
Was kann man also konkret dagegen tun?
Welche Migrationswerkzeuge fügen Received-Header hinzu
Alle IMAP-Migrationswerkzeuge verursachen dieses Problem, da der Received-Header vom Zielserver hinzugefügt wird, nicht vom Werkzeug selbst. Der Inhalt des hinzugefügten Headers variiert je nach Werkzeug und Server.
BitTitan MigrationWiz fügt einen Received-Header mit "mx.migrationwiz.com" hinzu. CloudM Migrate fügt Header mit Verweis auf "cloudm.io" hinzu. imapsync löst einen generischen Received-Header des Zielservers aus. GSMMO fügt Header mit "gmailapi.google.com"-Referenzen hinzu.
Die Korrektur: Korrekte Daten wiederherstellen
Die gute Nachricht: Die korrekte Datumsinformation existiert weiterhin in jeder E-Mail. Der ursprüngliche Date-Header ist intakt. Die ursprünglichen Received-Header sind intakt. Das Problem ist, dass ein kontaminierender Header darüber sitzt.
Die proprietäre Korrektur-Engine von Redate.io analysiert die vollständige Header-Kette jeder betroffenen E-Mail und führt einen Signaturabgleich mit Hunderten bekannter Migrationswerkzeug-Signaturen durch, um genau zu identifizieren, welche Header eine Korrektur benötigen. Die mehrstufige Analyse-Pipeline behandelt Grenzfälle, die einfachere Ansätze scheitern lassen: S/MIME-signierte Nachrichten, PGP-verschlüsselte Inhalte, multipart/alternative-Strukturen, Content-Transfer-Encoding-Probleme, Nicht-ASCII-Header (RFC 2047), übergroße Anhänge und beschädigte MIME-Grenzen.
Nach der Korrektur durchläuft jede E-Mail einen Integritätsprüfungsprozess, der bestätigt, dass Struktur, Inhalt und Anhänge der Nachricht identisch erhalten sind. Die Originale werden 30 Tage in einem sichtbaren Sicherungsordner aufbewahrt.
Könnte man ein Skript schreiben, um diese Korrektur selbst zu versuchen? Technisch ja. Aber der Unterschied zwischen "funktioniert bei 95 % der E-Mails" und "funktioniert bei 100 % der E-Mails, ohne eine einzige zu beschädigen" repräsentiert Monate an Entwicklung. Und wenn es um das vollständige Postfach einer Person geht, bedeutet eine 5-%-Fehlerrate Hunderte stillschweigend beschädigter Nachrichten ohne Möglichkeit zu verifizieren, was schiefgelaufen ist.
Möchten Sie wissen, wie viele E-Mails in Ihrem Postfach falsche Daten haben? Starten Sie eine kostenlose Analyse mit Redate.io für eine sofortige Zählung der betroffenen E-Mails - keine Zahlung erforderlich.