Falsches E-Mail-Datum nach cPanel-Migration

Der Montagmorgen, der wehtut

Sie haben gerade die Migration von einem cPanel-Shared-Hosting zu Google Workspace oder Microsoft 365 abgeschlossen. Die Operation lief reibungslos, die Postfächer sind erreichbar, die Nutzerinnen und Nutzer können sich einloggen. Dann, gegen 9:15 Uhr, kommt das erste Ticket: "Meine alten E-Mails zeigen alle dasselbe Datum, das vom letzten Wochenende." Dann ein zweites. Dann zehn.

Das ist kein Einzelfall. Es ist die direkte Folge davon, wie Migrationen aus cPanel mit den Datums-Metadaten von E-Mails umgehen (oder eben nicht umgehen).

cPanel, Roundcube, Horde: ein spezifischer IMAP-Kontext

Eine cPanel-Shared-Hosting-Umgebung ist ein Linux-Server, auf dem ein IMAP-Server (meist Dovecot) läuft, mit Roundcube oder Horde als Webmail-Oberfläche. Nichts Ungewöhnliches daran. Aber dieser Kontext hat ein paar Eigenheiten, die Migrationen zu Enterprise-Plattformen komplizierter machen, als es zunächst scheint.

Zum einen sammeln cPanel-Postfächer über Jahre, manchmal ein Jahrzehnt, E-Mails an. Ein Kunde, der seine Domain seit 2013 auf Shared Hosting betreibt, kann sehr tiefe Archive haben. Dieses Volumen erzeugt, kombiniert mit der Art der Migration, einen fruchtbaren Boden für das Datumsproblem.

Dazu kommt, dass die für diese Migrationen genutzten Werkzeuge oft entweder das native cPanel-Werkzeug (die Funktion "Migrations" von WHM), imapsync, per Kommandozeile vom Hosting-Anbieter oder IT-Berater ausgeführt, oder Consumer-Lösungen wie GSMMO für die Migration zu Google Workspace sind.

Warum Datumsangaben nach einer cPanel-Migration beschädigt werden

Um das Problem zu verstehen, müssen Sie zwei unterschiedliche Konzepte erfassen: den Date:-Header einer E-Mail und das IMAP-INTERNALDATE.

Der Date:-Header wird beim Versand gemäß RFC 2822 in den Rohtext der Nachricht geschrieben. Er hält fest, wann die E-Mail verfasst und gesendet wurde. Dieser Header ändert sich nie, außer wenn jemand die Nachricht absichtlich verändert.

INTERNALDATE hingegen ist ein Metadatenfeld, das der IMAP-Server jeder gespeicherten Nachricht zuordnet. Es ist vom eigentlichen Nachrichteninhalt getrennt. Wenn eine E-Mail normal auf einem Server ankommt, wird INTERNALDATE aus den Received:-Headern abgeleitet, oder aus dem Zeitstempel der Ablage, wenn die Nachricht direkt eingereicht wird. Diesen Wert verwenden Outlook, Thunderbird und die meisten E-Mail-Clients zum Sortieren der Nachrichten.

Bei einer IMAP-Migration werden Nachrichten von einem Server auf einen anderen kopiert. Das Problem: Das Migrationswerkzeug muss jede Nachricht auf dem Zielserver neu anlegen. Und bei vielen Werkzeugen wird das INTERNALDATE der neu angelegten Nachricht auf das Migrationsdatum gesetzt, nicht auf das ursprüngliche Datum der Nachricht. Zusätzlich wird ein Received:-Header mit dem Zeitstempel der Migration an die Kette der Header vorangestellt, was E-Mail-Clients, die sich darauf stützen, um das angezeigte Datum zu berechnen, weiter verwirrt.

Das Ergebnis: Eine E-Mail aus 2019 landet auf Google Workspace mit einem INTERNALDATE, das auf den Tag der Migration gesetzt ist, und einem Received:-Header von gestern. Outlook zeigt sie im Posteingang an, als wäre sie gerade eingetroffen. Die gesamte Archivchronologie ist zerstört.

Das WHM- / cPanel-Migrationswerkzeug

Das in WHM eingebaute Werkzeug für die Migration von cPanel-Konten auf eine andere Plattform erzeugt dieses Problem fast systematisch, wenn das Ziel ein externer IMAP-Server ist (Google Workspace, Microsoft 365). Es kopiert den Maildir-Inhalt auf den neuen Server, ohne das ursprüngliche INTERNALDATE zu erhalten. Jede Nachricht erhält den Zeitstempel der Operation.

imapsync und manuelle Migrationen aus cPanel

imapsync ist ein leistungsfähiges Werkzeug, aber sein Standardverhalten bewahrt nicht immer die Datumsangaben. Ohne die richtigen Parameter (und die richtige Version) kann es ohne Weiteres 40.000 Nachrichten kopieren und jede einzelne mit dem Ausführungsdatum des Skripts stempeln. (Wer schon einmal imapsync-Protokolle Zeile für Zeile durchgesehen hat, um ein Datumsproblem in einem Postfach mit 25.000 Nachrichten zu diagnostizieren, weiß, dass das eine Erfahrung ist, die man nicht wiederholen möchte.)

Genauer gesagt: imapsync hat durchaus Optionen, die versuchen, das Datum zu erhalten, aber diese Optionen wirken je nach Quell- und Zielserver unterschiedlich, und ihre Wirksamkeit ist über alle cPanel- / Dovecot-Konfigurationen hinweg nicht garantiert.

GSMMO und Consumer-Werkzeuge

Google Workspace Migration for Microsoft Outlook (GSMMO) ist für die Migration aus Outlook konzipiert, nicht aus einem reinen IMAP-Server. Wird es genutzt, um aus cPanel zu migrieren (über ein in Outlook konfiguriertes IMAP-Konto), erfahren die Datumsangaben dieselbe Behandlung: Das INTERNALDATE auf Google Workspace wird auf das Migrationsdatum gesetzt. Das GSMMO-E-Mail-Datumsproblem ist tatsächlich eigens dokumentiert, so häufig kommt es vor.

Welche E-Mail-Clients sind betroffen?

Die Datumsbeschädigung zeigt sich nicht in jedem Client auf dieselbe Weise.

Outlook ist am schlimmsten betroffen. Es verwendet INTERNALDATE (oder den Migrations-Received:-Header) als primären Sortierschlüssel für Ordner. Nach einer schlecht ausgeführten cPanel-Migration kann ein Outlook-Postfach Tausende von archivierten E-Mails mit dem Datum des Migrationswochenendes anzeigen. Das Korrigieren der imapsync-Migrationsdaten in Outlook ist eine der am häufigsten angefragten Korrekturen.

Gmail (Google Workspace) zeigt in der E-Mail-Liste im Allgemeinen das Datum aus dem Date:-Header an, aber die Sortierung kann in manchen Fällen trotzdem vom INTERNALDATE beeinflusst werden. Nutzerinnen und Nutzer berichten von unregelmäßigem Verhalten bei Suche und datumsbasierter Sortierung.

Apple Mail und Thunderbird verhalten sich uneinheitlicher, aber keiner der beiden ist immun, besonders wenn ein Migrations-Received:-Header oben in der Header-Kette steht.

Gute Nachricht: das ursprüngliche Datum ist noch da

Das ist das technische Detail, das alles verändert. Der ursprüngliche Date:-Header wird in den Rohtext der Nachricht geschrieben. Die Migration rührt ihn nicht an. Wenn Sie eine betroffene E-Mail öffnen und die Rohheader ansehen (in Gmail: "Original anzeigen", in Outlook: Datei > Eigenschaften), sehen Sie das ursprüngliche Date: intakt, gefolgt von einem oder mehreren Received:-Headern, von denen der erste das Migrationsdatum trägt.

Diese Information ist noch vorhanden. Sie kann genutzt werden, um die Metadaten zu korrigieren. Genau das macht die Korrektur-Engine von Redate.io.

Warum "es einfach selbst korrigieren" riskanter ist, als es aussieht

Die Versuchung ist real. Das Problem scheint einfach: das ursprüngliche Datum lesen, die Metadaten korrigieren, weitermachen. Aber es liegt eine erhebliche Lücke zwischen dem Verständnis des Mechanismus und der Korrektur von 12.000 Produktions-E-Mails, ohne eine einzige zu verlieren.

Ein paar Realitäten, die selbstgebaute Skripte typischerweise nicht berücksichtigen:

Ein Skript, das bei 50 Test-E-Mails in einer Entwicklungsumgebung funktioniert, hält nicht unbedingt bei 18.000 Nachrichten in einem Produktionspostfach stand, das von einem cPanel-Konto stammt, das seit 2011 läuft.

Wie Redate.io Datumsangaben nach einer cPanel-Migration korrigiert

Redate.io verbindet sich direkt mit dem Zielpostfach (Google Workspace, Microsoft 365 per einfacher Anmeldung, oder direktes IMAP) und beginnt mit einer kostenlosen Überprüfung, um E-Mails zu identifizieren, deren Datumsmetadaten nicht mit dem ursprünglichen Date:-Header übereinstimmen.

Die mehrstufige Analyse-Pipeline wendet dann Musterabgleich auf Received:-Header an, um jene zu identifizieren, die von Migrationswerkzeugen eingefügt wurden (und sie von legitimen Headern zu unterscheiden). Die gezielte Metadatenkorrektur wird angewendet, ohne den Nachrichteninhalt zu verändern: Textkörper, Anhänge, ursprüngliche Header, alles bleibt intakt. Jede korrigierte E-Mail wird einzeln überprüft, bevor die Operation bestätigt wird.

Für cPanel-Migrationen im Besonderen erkennt Redate.io E-Mails, deren angezeigtes Datum nicht mit dem ursprünglichen Datum übereinstimmt, unabhängig davon, mit welchem Werkzeug die Migration durchgeführt wurde, ob Dovecot-zu-IMAP-Migration, imapsync-Skript oder eine bei Shared-Hosting-Anbietern übliche Konfigurationsvariante.

Spezifische Anleitungen nach Zielplattform

Abhängig davon, wo Ihre cPanel-Migration gelandet ist, behandeln diese Anleitungen die genauen Schritte:

Aus cPanel migriert, und Ihre Nutzerinnen und Nutzer sehen falsche Datumsangaben? Starten Sie eine kostenlose Überprüfung auf Redate.io, um genau herauszufinden, wie viele E-Mails betroffen sind, ohne dass Änderungen vorgenommen werden, bevor Sie zustimmen.