POP zu IMAP: Alte E-Mails zeigen das heutige Datum

Das klassische Montagmorgen-Szenario

Sie haben Ihr E-Mail-Konto gerade von POP3 auf IMAP umgestellt. Die Konfiguration war einfach, Ihr Hoster hat Sie durch den Prozess geführt, alles lief reibungslos. Bis Sie Ihr Postfach wieder öffnen. Ihre E-Mails von 2019, 2021, Ihre Archive vom letzten Jahr... alle zeigen dasselbe Datum: heute. Manchmal sogar dieselbe Uhrzeit, auf Sekunden genau.

Das ist kein Bug Ihres E-Mail-Clients. Kein Zeitzonenproblem. Es ist das erwartete Verhalten des IMAP-Protokolls, und es betrifft jeden, der lokal gespeicherte E-Mails auf diesem Weg auf einen Server hochlädt.

POP3 vs. IMAP: ein grundlegender Unterschied beim Speichern

Um zu verstehen, warum das Problem auftritt, muss man zunächst begreifen, wie POP3 funktioniert und warum das radikal anders ist als IMAP.

Bei POP3 dient der Server nur als temporäres Postfach. Ihr Client (Outlook, Thunderbird, Apple Mail) verbindet sich, lädt die Nachrichten herunter und löscht sie dann vom Server (oder lässt sie je nach Konfiguration dort). Die E-Mails leben danach ausschließlich lokal: in einer .pst-Datei für Outlook, im lokalen Thunderbird-Profil, in einer Datenbank auf Ihrer Festplatte.

Bei IMAP ist es umgekehrt: Die E-Mails leben auf dem Server. Ihr Client zeigt nur an, was remote gespeichert ist. Daher die transparente Synchronisierung zwischen allen Ihren Geräten.

Das Problem entsteht beim Übergang zwischen den beiden. Wenn Sie Ihre alten lokalen POP-E-Mails auf den IMAP-Server hochladen.

IMAP APPEND: der Befehl, der alles verändert

Wenn Ihr E-Mail-Client eine lokale Nachricht auf einen IMAP-Server hochlädt, verwendet er den Befehl IMAP APPEND. Dieser Befehl sagt dem Server: "Speichere diese Nachricht in diesem Ordner."

Der Server empfängt die Nachricht, speichert sie und weist ihr einen Zeitstempel zu. Dieser Zeitstempel ist das INTERNALDATE. Das ist die zentrale Metadatenangabe von IMAP: Sie zeigt an, wann die Nachricht auf dem Server abgelegt wurde. Und standardmäßig gilt: Wenn der Client im APPEND-Befehl kein explizites Datum angibt, verwendet der Server... den aktuellen Zeitpunkt.

Das heißt: Egal ob die Nachricht in ihren Headern ein Datum aus dem Jahr 2018 enthält, wenn niemand dem Server sagt "diese E-Mail stammt aus 2018", geht der Server davon aus, dass sie gerade eingeliefert wurde, und weist ihr das heutige INTERNALDATE zu.

(Falls Sie schon einmal die rohen E-Mail-Header angeschaut haben, haben Sie die Zeile Date: inmitten von einem Dutzend Received:-Zeilen gesehen. Dieses Date:-Feld, definiert durch RFC 2822, enthält das echte Sendedatum. Das IMAP INTERNALDATE ist jedoch eine separate Metadatenangabe, die serverseitig gespeichert wird und nichts mit dem Nachrichteninhalt selbst zu tun hat.)

Warum sich das von einer IMAP-zu-IMAP-Migration unterscheidet

Bei einer klassischen Migration von einem IMAP-Server zu einem anderen (mit BitTitan, CloudM, imapsync usw.) ist das Problem etwas anders gelagert. Das Migrationstool kopiert Nachrichten von einem Server auf den anderen, und dabei kann es (theoretisch) das ursprüngliche INTERNALDATE über den APPEND-Befehl an den Zielserver übermitteln. Das Problem dort: Manche Tools fügen einen Received:-Header mit dem Migrationsdatum hinzu, was die Anzeige in Clients wie Outlook durcheinanderbringt.

In Ihrem Fall hingegen gehen Sie von rein lokalen Daten aus. Es gibt kein Quell-INTERNALDATE, das kopiert werden könnte. Die .pst-Datei oder das Thunderbird-Profil speichert Nachrichten in einem eigenen proprietären Format mit eigenen internen Metadaten. Wenn der E-Mail-Client diese Nachrichten ausliest, um sie auf den IMAP-Server hochzuladen, rekonstruiert er den APPEND-Befehl aus dem Nachrichteninhalt. Und meistens übergibt er dabei kein explizites Datum.

Das Ergebnis: Der IMAP-Server empfängt innerhalb weniger Minuten Hunderte oder Tausende von Nachrichten und weist allen denselben Zeitstempel zu: jetzt.

Genau deshalb breitet sich das Problem sofort auf allen Ihren Geräten aus. Ihr Smartphone, Ihr Tablet, Ihr zweiter Computer: Sie alle verbinden sich mit demselben IMAP-Server und sehen exakt dasselbe. Eine clientseitige Korrektur ist nicht möglich.

Welcher Client zeigt was, und warum

Nicht alle E-Mail-Clients reagieren gleich. Das ist ein Punkt, den viele IT-Admins erst im Nachhinein entdecken.

Outlook (in neueren Versionen, besonders seit den Updates von 2023-2024) verwendet das INTERNALDATE des Servers für die Spalte "Empfangen". Es zeigt also das Datum des Hochladens, nicht das ursprüngliche Sendedatum. Mehr zu diesem Outlook-spezifischen Verhalten finden Sie hier: Outlook: IMAP-Empfangsdatum vs. Sendedatum nach Migration.

Gmail / Google Workspace und Thunderbird verhalten sich etwas differenzierter. Gmail kann etwa manchmal das Date:-Feld aus dem Nachrichten-Header für die Anzeige verwenden, was zunächst den Eindruck vermittelt, alles sei in Ordnung... bis Sie versuchen, nach Datum zu sortieren und feststellen, dass die Reihenfolge völlig durcheinander ist.

Apple Mail zeigt in der Regel das aus dem Date:-Header extrahierte Datum an, aber Sortierung und Suche laufen im Hintergrund über das INTERNALDATE. Ihre E-Mails können also visuell "korrekt datiert" wirken, während die Sortierfunktion nicht mehr richtig arbeitet. Zum genauen Verhalten von Apple Mail: Apple Mail: falsches Datum nach Migration.

Die gute Nachricht: Das ursprüngliche Datum ist intakt

Der Date:-Header jeder E-Mail, der das echte Sende- (oder Empfangs-)datum enthält, wurde nicht angetastet. Er ist nach wie vor im Nachrichteninhalt vorhanden. Das ist das Datum, das Sie sehen, wenn Sie eine E-Mail öffnen und sich die Details anschauen.

Was der IMAP-Server "zerstört" hat, ist ausschließlich das INTERNALDATE, diese externe Metadatenangabe. Die Nachricht selbst ist unberührt.

Das macht eine Korrektur möglich. Und das erklärt auch, warum das Problem eine Weile unbemerkt bleiben kann: Die E-Mails wirken korrekt, wenn Sie sie einzeln öffnen. Erst wenn Sie die nach Datum sortierte Liste Ihres Posteingangs betrachten, wird das Problem sichtbar. E-Mails aus 2019 erscheinen ganz oben, als wären sie gerade angekommen. Alle mit demselben Datum.

Das Mengenproblem: 3.000 E-Mails sind etwas anderes als 3

Vielleicht denken Sie: "Ich lösche alles und importiere es einfach neu, diesmal richtig." Bei 5 oder 10 Test-E-Mails funktioniert das. Bei einem Postfach mit 8.000 Nachrichten, verschachtelten Ordnern, großen Anhängen, S/MIME-signierten E-Mails und Konversationsverläufen bis 2015... ist das eine ganz andere Geschichte.

Ein selbst geschriebenes Skript, das bei einem Testlauf mit 50 E-Mails funktioniert, kann bei einem Produktionspostfach ohne Weiteres Duplikate erzeugen, Anhänge verlieren oder Konversations-Threads zerstören. Die Verwaltung von API-Quoten, Netzwerk-Timeouts, Nachrichten mit untypischen MIME-Strukturen... alles Grenzfälle, die ein nicht spezialisiertes Tool nicht beherrscht.

Und wenn mitten im Prozess etwas schiefgeht? Ohne Sicherungs- und Rollback-Mechanismus verlieren Sie Daten unwiederbringlich.

Das Problem ist Admins, die Migrationen in größerem Umfang betreuen, bestens bekannt. Zu verstehen, warum Datumsangaben kaputt sind, ist eine Sache. 15.000 E-Mails sauber zu korrigieren und dabei jede Nachrichtenstruktur zu erhalten, ist eine andere. Für eine vertiefte Betrachtung verschiedener Ansätze und ihrer Grenzen: Können E-Mail-Daten nach der Migration korrigiert werden?

Wie Redate.io diesen Fall behandelt

Redate.io wurde genau für solche Situationen entwickelt. Die Analyse-Engine identifiziert E-Mails, deren INTERNALDATE nicht mit dem Datum in den Nachrichten-Headern übereinstimmt, ob es sich um eine POP-zu-IMAP-Migration handelt, eine Migration zwischen IMAP-Servern oder das manuelle Hochladen lokaler Archive.

Die mehrstufige Analyse-Pipeline untersucht die Header-Kette jeder Nachricht, validiert die RFC-Konformität und rekonstruiert die Datumsmetadaten, ohne den Nachrichteninhalt zu verändern: weder Text noch Anhänge, noch die MIME-Struktur, noch etwaige digitale Signaturen. Jede korrigierte E-Mail wird vor der Bestätigung einzeln geprüft.

Die Originale werden 30 Tage lang in einem sichtbaren Sicherungsordner aufbewahrt. Falls Ihnen etwas nicht passt, können Sie jederzeit wiederherstellen.

Der erste Scan ist kostenlos: Redate analysiert Ihr Postfach, identifiziert die betroffenen E-Mails und nennt Ihnen die genaue Anzahl, bevor Sie irgendeine Entscheidung treffen. Kein blindes Commit.

Redate.io verbindet sich direkt mit Ihren Postfächern über Google Workspace (Domain-Delegation), Microsoft 365 (Azure AD) oder direktes IMAP. Keine lokale Installation. Keine .pst-Dateien, die Sie manuell bearbeiten müssen.

Admins, die mehrere Postfächer betreuen und Erfahrungsberichte zu solchen Fällen suchen, finden nützliche Informationen in diesem Artikel: MSP: E-Mail-Daten Ihrer Kunden korrigieren. Und für die Besonderheiten der Korrektur in Thunderbird, das beim POP/IMAP-Wechsel ein eigenes Verhalten zeigt: Thunderbird: Falsches Datum nach der Migration.

Falls es noch bevorsteht: Das Problem von Anfang an vermeiden

Wenn Sie Ihre lokalen Archive noch nicht auf den IMAP-Server hochgeladen haben oder weitere POP-Konten in Ihrer Organisation migrieren wollen, sollten Sie Folgendes im Hinterkopf behalten.

• Prüfen Sie, ob Ihr E-Mail-Client die explizite Datumsübergabe im APPEND-Befehl unterstützt. Thunderbird beispielsweise zeigte in diesem Punkt je nach Version unterschiedliches Verhalten.
• Testen Sie zunächst mit einem Validierungskonto und 50-100 repräsentativen Nachrichten: ältere E-Mails, E-Mails mit Anhängen, signierte E-Mails. Prüfen Sie die angezeigten Daten in verschiedenen Clients.
• Planen Sie die Korrektur, bevor die Endnutzer mit dem migrierten Postfach zu arbeiten beginnen. Datumsangaben in einem aktiven Postfach zu korrigieren ist komplexer als in einem frischen post-migrierten Postfach.
• Dokumentieren Sie die Anzahl der E-Mails vor und nach der Migration. Nur so lassen sich stille Datenverluste erkennen.

Eine vollständige Checkliste aller Punkte, die vor und nach einer Migration zu prüfen sind, bietet der Artikel Checkliste E-Mail-Migration: Datumsprobleme vermeiden.

Ihre alten E-Mails zeigen nach dem Wechsel von POP zu IMAP das heutige Datum? Starten Sie einen kostenlosen Scan auf Redate.io, um das Ausmaß des Problems zu messen und die Datumsmetadaten zu korrigieren, ohne den Inhalt Ihrer Nachrichten anzutasten.