Migration Google Workspace zu GWS: Datumsfehler

Das Szenario, das niemand auf dem Schirm hat

Die Migration von einem Google-Workspace-Tenant zum anderen ist abgeschlossen. Unternehmensübernahme, Domainwechsel, Zusammenführung zweier Einheiten, die jahrelang unter getrennten G-Suite-Konten gearbeitet haben. Alles lief reibungslos, die Postfächer sind eingerichtet, die Nutzerinnen und Nutzer können sich anmelden. Montagmorgen, erstes Ticket: "Alle meine E-Mails haben dasselbe Datum." Dann ein zweites. Dann zehn.

Instinktiv denkt man: das ist ein IMAP-Problem, ein falsch konfiguriertes Tool, irgendetwas Exotisches. Keine Google-zu-Google-Migration. Und trotzdem passiert es genau da.

Dieses Szenario ist wahrscheinlich das am schlechtesten dokumentierte in der Branche. Die meisten IT-Admins, die es erleben, suchen stundenlang nach einer Erklärung beim E-Mail-Client, bei Outlook, bei Kontoeinstellungen, bevor sie merken: das Problem steckt in den E-Mail-Headern selbst.

Warum eine Google-zu-Google-Migration Daten zerstört

Um zu verstehen, was passiert, muss man zur Mechanik der E-Mail-Header zurück. Jede RFC-2822-Nachricht enthält ein originales Date:-Feld, das der sendende Client oder Server beim Versand gesetzt hat. Das ist das "echte" Datum der E-Mail, das dem Zeitpunkt entspricht, zu dem die Nachricht verfasst und abgeschickt wurde.

Aber es gibt noch einen weiteren Mechanismus: die INTERNALDATE in IMAP. Das ist eine serverseitig gespeicherte Metadaten, die angibt, wann die Nachricht im Postfach abgelegt wurde. Und genau hier wird es interessant.

Wenn ein Migrationstool eine E-Mail von einem Google-Workspace-Tenant zu einem anderen überträgt, geschieht das über das IMAP-Protokoll (auch wenn beide Server bei Google liegen). Die Nachricht wird aus der Quelle gelesen und dann in das Zielpostfach eingefügt. Bei diesem Einfügen fügt der Zielserver automatisch einen Received:-Header mit dem Zeitstempel des Vorgangs hinzu, also dem Migrationsdatum.

Clients wie Outlook verwenden den ersten Received:-Eintrag in der Kette, um das Datum einer Nachricht anzuzeigen, nicht unbedingt das originale Date:-Feld. Ergebnis: Alle E-Mails zeigen das Datum des Migrationstags.

Welche Tools das Problem auslösen

Praktisch alle Tools, die für Tenant-zu-Tenant-Migrationen in Google Workspace eingesetzt werden, sind betroffen. Keine nennenswerte Ausnahme:

• GSMMO (Google Workspace Migration for Microsoft Outlook): ursprünglich für Migrationen aus Exchange entwickelt, aber in manchen GWS-zu-GWS-Szenarien eingesetzt.
• CloudM Migrate: bei MSPs weit verbreitet für Google-zu-Google-Migrationen, fügt systematisch einen Migrations-Received:-Header hinzu. Siehe die detaillierte Analyse zu CloudM.
• BitTitan MigrationWiz: gleiches Verhalten, dokumentiert in diesem Artikel zu BitTitan.
• imapsync: das Open-Source-Tool für IMAP-Migrationen per Skript, auch zwischen zwei Google-Tenants einsetzbar.
• Manuelle Exports/Imports über Takeout + IMAP-Reimport: seltener, aber mit exakt demselben Effekt.

Der Grund ist einfach: All diese Tools funktionieren als Standard-IMAP-Clients. Sie haben keinen Zugang zu einem "nativen" Google-Pfad, der die Metadaten erhalten würde. Auch wenn beide Tenants bei Google liegen, läuft die Übertragung über die IMAP-Schicht, und diese Schicht weiß nicht, dass sie quasi mit sich selbst kommuniziert.

Die Mechanik der Received-Header im Detail

(Wer schon einmal versucht hat, die Rohheader einer E-Mail in Gmail oder Outlook zu lesen, weiß: das ist keine entspannte Lektüre. Aber genau dort liegt die ganze Wahrheit.)

Eine E-Mail, die normal zugestellt wurde, enthält eine Kette von Received:-Headern in umgekehrter Reihenfolge des Wegs: Der letzte Server, der die Nachricht angefasst hat, steht oben. Nach einer Migration landet der Migrations-Header also ganz oben in der Liste.

So sieht das in einer via CloudM von einem GWS-Tenant zum anderen migrierten Nachricht aus:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <benutzer@neue-domain.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

Das Date:-Feld sagt 2019. Der erste Received:-Header sagt Oktober 2024. Outlook liest den ersten Received:-Header. Der Nutzer sieht Oktober 2024 für eine E-Mail aus 2019.

Das originale Date:-Feld ist unverändert. Es hat sich nicht bewegt. Das ist die gute Nachricht: Der Datenwert ist vorhanden, er wartet nur darauf, korrekt ausgewertet zu werden.

Outlook und Gmail verhalten sich unterschiedlich

Das ist ein wichtiger Punkt. Nutzerinnen und Nutzer, die auf ihre E-Mails über die Gmail-Weboberfläche zugreifen, sehen oft die richtigen Daten, weil Gmail vorrangig das Date:-Feld nach RFC 2822 zur Anzeige verwendet. Das Problem fällt im Web weniger auf.

Dagegen haben Nutzende, die ihr Google-Workspace-Postfach in Outlook über IMAP einrichten (oder über Exchange-ActiveSync-Synchronisierung), das falsche Datum voll im Blick, weil Outlook sich auf die IMAP-INTERNALDATE stützt, die ihrerseits das Datum des ersten bei der Migration eingefügten Received:-Headers widerspiegelt.

Genauer gesagt: Das Verhalten von Outlook variiert je nach Version und Verbindungsmodus. Outlook 2019 und aktuelle Microsoft-365-Versionen verwenden die INTERNALDATE bei IMAP-Verbindungen. Ältere Versionen können sich leicht anders verhalten. In allen in der Praxis beobachteten Fällen produziert eine GWS-zu-GWS-Migration über IMAP jedoch falsche Daten in Outlook.

In Organisationen, die zu einem neuen Tenant migriert haben und bei denen ein Teil der Nutzenden Gmail im Web und ein anderer Teil Outlook verwendet, sind die Tickets daher widersprüchlich. Die IT-Teams verbringen Zeit damit zu verstehen, warum "manche betroffen sind und andere nicht", dabei lautet die Antwort schlicht: Es kommt auf den E-Mail-Client an.

Übernahmen, Fusionen, Domainwechsel: die häufigsten Fälle

Solche Migrationen sind keine Ausnahme. Hier sind die Szenarien, die die meisten Tickets erzeugen:

Unternehmensübernahme

Ein übernommenes Unternehmen hatte seinen eigenen Google-Workspace-Tenant (Domain @alte-firma.de). Nach der Übernahme muss alles auf den Tenant des Mutterkonzerns (@gruppe.de) migriert werden. Die 250 Postfächer, die Archive, die 8 Jahre E-Mail-Geschichte. BitTitan oder CloudM wird beauftragt. Ergebnis: 2,4 Millionen E-Mails mit dem Datum des Migrationswochenendes.

Domainwechsel

Ein umbenanntes Unternehmen wechselt von @altername.de zu @neuername.de. Gleicher Google-Tenant, aber Einrichtung eines neuen Tenants für einen sauberen Neustart (eine häufige Wahl, um Konfigurationsaltlasten zu vermeiden). Migration der Postfächer über imapsync oder GSMMO. Die Daten werden auf exakt dieselbe Weise zerstört.

Konsolidierung von Tochtergesellschaften

Ein Konzern mit 4 Tochtergesellschaften, jede auf ihrem eigenen historischen G-Suite-Tenant, beschließt, alles auf einem einzigen Tenant zusammenzuführen. Vier parallele Migrationen, vier Chargen E-Mails mit beschädigten Daten.

In allen drei Szenarien ist das Problem identisch und die Lösung dieselbe. Die Checkliste für E-Mail-Migrationen hilft dabei, dieses Problem vor dem Start der Migration zu antizipieren.

Warum ein selbst geschriebenes Skript keine Lösung ist

Das Problem zu verstehen ist eine Sache. Zu sagen "Ich schreibe ein Python-Skript, das die Header bereinigt" und es auf 30.000 Produktions-E-Mails anzuwenden, ist eine ganz andere.

Grenzfälle gibt es zuhauf. Ein Skript, das bei 50 Test-E-Mails in einer sauberen Umgebung funktioniert, wird in einem echten Produktionspostfach unweigerlich auf Folgendes stoßen:

• Nachrichten mit S/MIME-Signaturen oder PGP-verschlüsseltem Inhalt, bei denen jede Änderung der Nachrichtenstruktur die kryptografische Signatur ungültig macht.
• E-Mails mit komplexen verschachtelten MIME-Strukturen (multipart/alternative in multipart/mixed mit mehrere Dutzend Megabyte großen Anhängen).
• In RFC 2047 kodierte Header (Nicht-ASCII-Zeichen), die schlecht konfigurierte Parser stillschweigend schlucken.
• 429-Too-Many-Requests-Fehler der Google-API um 2 Uhr nachts, mitten in einem Korrektur-Batch, die den Prozess in einem undefinierten Zustand hinterlassen.
• E-Mails, bei denen die Received:-Kette mehrdeutig ist: Mehrere aufeinanderfolgende Migrationstools haben jeweils ihren eigenen Header hinzugefügt, und es ist nicht trivial zu bestimmen, welchen man entfernen soll.

Und die wichtigste Frage: Wie lässt sich E-Mail für E-Mail überprüfen, dass jede korrigierte Nachricht intakt ist und nichts verloren gegangen oder beschädigt wurde? Ein selbst geschriebenes Skript führt diese Überprüfung in der Regel nicht durch. Redate.io erledigt das automatisch, mit Aufbewahrung der Originale in einem sichtbaren Sicherungsordner für 30 Tage.

Was Redate.io bei solchen Migrationen macht

Redate.io verbindet sich mit dem Ziel-Google-Workspace-Tenant (über Domain-Delegation, ohne manuelle Eingriffe postfach für Postfach) und scannt E-Mails, um diejenigen zu identifizieren, deren Datumsmetadaten mit dem Nachrichteninhalt nicht übereinstimmen. Dieser Scan ist kostenlos und liefert ein genaues Bild des Ausmaßes des Problems, bevor irgendeine Korrektur erfolgt.

Die proprietäre Korrekturmaschine analysiert anschließend die Header-Kette jeder Nachricht, wendet einen Musterabgleich auf bekannte Signaturen von Migrationstools an (BitTitan, CloudM, imapsync, GSMMO und weitere weniger verbreitete Tools) und nimmt eine gezielte Korrektur der Metadaten vor, ohne den Nachrichteninhalt zu verändern. Jede korrigierte E-Mail wird einzeln verifiziert. Die Originale bleiben erhalten.

Speziell für Tenant-zu-Tenant-Migrationen in Google Workspace verarbeitet die Pipeline auch Fälle, in denen mehrere Migrationsdurchläufe stattgefunden haben (etwa ein Postfach, das 2021 erstmals und 2024 erneut migriert wurde), mit mehreren überlagerten Parasiten-Headern, die es zu entwirren gilt.

Die spezifischen Korrekturanleitung für CloudM zu Google Workspace und BitTitan zu Google Workspace beschreiben die Verbindungsschritte für diesen Konfigurationstyp im Detail.

Das Problem erkennen, bevor Nutzende sich beschweren

Der beste Zeitpunkt, beschädigte Daten zu erkennen, ist direkt nach der Migration, vor dem Go-live. Eine schnelle Prüfung an einigen Pilotpostfächern über einen IMAP-Client wie Thunderbird erlaubt den Vergleich der angezeigten Daten mit dem Erwarteten. Wenn alle importierten E-Mails scheinbar dasselbe aktuelle Datum tragen, ist das das typische Anzeichen des Problems.

In der Praxis wird das Problem aber oft erst mehrere Wochen nach der Migration entdeckt, wenn jemand einen alten Vertrag sucht und feststellt, dass sein Gmail-Postfach perfekt sortiert ist... nach Migrationsdatum. Tausende von E-Mails mit demselben Zeitstempel. Die Datumssuche funktioniert nicht mehr. Konversations-Threads sind durcheinander. Die Geschichte scheint verschwunden zu sein.

Für MSPs, die regelmäßig Google-Workspace-Tenant-Migrationen durchführen, empfiehlt sich die Integration eines Redate.io-Scans in die Post-Migrations-Checkliste (vor der Kundenabnahme), um solche Überraschungen zu vermeiden. Weitere Hinweise dazu liefert der Artikel zu falschen E-Mail-Daten nach der Migration.

Sie haben gerade zwischen zwei Google-Workspace-Tenants migriert und die E-Mail-Daten stimmen nicht? Starten Sie einen kostenlosen Scan auf Redate.io, um das Ausmaß vor jeder Korrektur zu messen.