imapsync-Migrationsdaten in Gmail korrigieren

imapsync ist das Standardtool für IMAP-zu-IMAP-Postfachmigration, und das aus gutem Grund - es handhabt Ordner-Mapping, Flag-Beibehaltung und inkrementelle Synchronisierung besser als die meisten Alternativen. Aber wenn das Ziel Gmail ist, wird die Datumsbeibehaltung auf eine Weise unzuverlässig, die selbst erfahrene Sysadmins überrascht.

Das Flag --syncinternaldates soll das lösen. Es weist imapsync an, die INTERNALDATE der Quellnachricht während des APPEND an den Zielserver zu übergeben. Auf einem Standard-IMAP-Server funktioniert das. Bei Gmail? Nicht immer. Gmails IMAP-Implementierung schleust eingehende Nachrichten durch eine eigene interne Verarbeitungs-Pipeline - Spam-Filterung, Sicherheitsscans, Content-Indizierung. Während dieser Verarbeitung kann Gmail die angeforderte INTERNALDATE überschreiben und die Nachricht stattdessen mit dem Upload-Zeitstempel versehen. Außerdem fügt Gmail einen Received-Header hinzu (typischerweise mit "gmailapi.google.com" oder der IMAP-Gateway-Kennung), datiert auf den Upload-Moment.

Der frustrierende Teil: Das passiert nicht bei jeder Nachricht. Manche E-Mails im migrierten Postfach bekommen die korrekte INTERNALDATE. Andere bekommen das Upload-Datum. Es gibt kein klares Muster - eine Nachricht von 2018 kann in Ordnung sein, während die direkt daneben vom selben Tag das Migrationsdatum trägt. Man endet mit einem Postfach, in dem 30-70% der E-Mails falsche Daten haben, zufällig über Ordner und Zeiträume verstreut.

Haben Sie mal versucht, einem Compliance-Beauftragten zu erklären, warum 4.200 von 11.000 migrierten E-Mails das falsche Empfangsdatum zeigen, aber die anderen 6.800 in Ordnung sind? Tatsächlich ein ziemliches Puzzle.

Gmails Weboberfläche verbirgt das Problem. Gmail Web zeigt den Date-Header-Wert, nicht die INTERNALDATE, sodass die meisten betroffenen E-Mails im Browser gut aussehen. Das erzeugt ein gefährliches falsches Sicherheitsgefühl - der Migrations-Admin prüft Gmail Web, sieht korrekte Daten und schließt das Ticket.

Dann beginnen Benutzer, Outlook, Apple Mail und Thunderbird mit ihren neuen Gmail-Konten zu verbinden. Diese Clients lesen die IMAP INTERNALDATE für ihre Datumsspalten. Plötzlich zeigen zufällige E-Mails das Migrationsdatum, während andere das korrekte Datum zeigen. Die Inkonsistenz zwischen Gmail Web und Desktop-Clients erzeugt verwirrte Support-Tickets. Serverseitige IMAP-Suchbefehle (SEARCH SINCE, SEARCH BEFORE) referenzieren die INTERNALDATE und liefern unvollständige oder ungenaue Ergebnisse. Backup-Tools von Drittanbietern, die über IMAP archivieren, erfassen die verfälschten Daten dauerhaft. Google Vault und Workspace-Compliance-Tools können die INTERNALDATE für datumsbasierte Holds referenzieren, was potenziell juristische Discovery beeinträchtigt. Die Mustererkennung von Redate.io über Migrationstool-Signaturen identifiziert die spezifischen Gmail Received-Header, die auf Datumsverfälschung hindeuten, und wendet dann gezielte Metadaten-Korrektur auf jede betroffene Nachricht an, während alle Labels, Sterne und der Gelesen/Ungelesen-Status bewahrt werden.