CloudM Migrate: Falsche E-Mail-Daten korrigieren

Das CloudM-Migrate-Datenproblem, vor dem niemand warnt

CloudM Migrate hat den Job erledigt. Das Dashboard zeigt 100 % abgeschlossen, alle Benutzer migriert, null Fehler. Sie schliessen das Projektticket und wenden sich dem nachsten Kunden zu.

Eine Woche spater ruft der IT-Leiter an. "Warum zeigt jede E-Mail in meinem Postfach den 2. April?"

Nicht einige E-Mails. Alle. Funf Jahre Kundenkorrespondenz, Rechtsdokumente, HR-Unterlagen, Bestellungen aus 2020, alles mit dem Datum, an dem CloudM die Migration ausgefuhrt hat. Die Nachrichten sind da, der Inhalt ist intakt, Anhange sind in Ordnung. Aber die Daten stimmen bei jeder einzelnen E-Mail nicht.

Das ist kein CloudM-Bug. Die Support-Dokumentation von CloudM raumt das offen ein. Das Problem liegt an der Schnittstelle zwischen der Art, wie Migrationstools Nachrichten ubertragen, und wie Ziel-Mailserver eingehende E-Mail-Metadaten verarbeiten. Aber dieses Wissen hilft Ihrem Kunden nicht, dessen Posteingang plotzlich chronologisch unsortierbar geworden ist.

Wie CloudM E-Mail-Nachrichten tatsachlich ubertragt

CloudM Migrate verbindet sich uber ihre APIs mit Quell- und Zielplattformen. Fur Google Workspace bedeutet das ein Dienstkonto mit domainweiter Delegation (konfiguriert in der Google Admin Console unter Sicherheit > API-Steuerung). Fur Microsoft 365 verwendet CloudM entweder Exchange Web Services oder die Microsoft Graph API, je nach Migrationspfad.

Wenn CloudM eine Nachricht von der Quelle liest, erhalt es den vollstandigen RFC-2822-Inhalt, einschliesslich aller Original-Header und des Nachrichtentexts. Der ursprungliche Date:-Header (der Zeitstempel, den der Mailserver des Absenders beim erstmaligen Versand gestempelt hat) kommt intakt mit. Ebenso alle ursprunglichen Received:-Header, die den Zustellungsweg der Nachricht nachzeichnen.

Das Problem tritt am Ziel auf. Wenn CloudM diese Nachricht in das Zielpostfach schreibt, behandelt der Zielserver sie wie eine neue Zustellung. Er versieht sie mit einem frischen Received:-Header mit dem aktuellen Datum und der aktuellen Uhrzeit und setzt das INTERNALDATE (den Zeitstempel, den IMAP fur die Sortierung verwendet) auf den Moment des Einfugens.

So sieht die Header-Kette nach einer CloudM-Migration zu Microsoft 365 aus:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

Der 2019er Header ist noch da. Der ursprungliche Date:-Header zeigt immer noch den 23. September 2019. Aber Outlook liest den obersten Received:-Header, um die Anzeigereihenfolge zu bestimmen, und der sagt jetzt 2. April 2026.

CloudMs Einstellung "Strip Received Headers"

CloudM bietet eine Einstellung fur dieses Problem. In den erweiterten Einstellungen der Zielplattform gibt es unter Message Options einen "Strip Received Headers"-Schalter. Wenn aktiviert, entfernt CloudM die Received-Header vor dem Einfugen der Nachricht und ersetzt sie durch einen einzelnen Header, der dem Date:-Header der E-Mail entspricht.

Klingt so, als wurde das alles losen, oder? Nicht ganz.

Erstens muss man davon wissen, bevor man die Migration startet. Die meisten Administratoren entdecken das Datumsproblem erst nach Abschluss der Migration. Zu diesem Zeitpunkt befinden sich die Nachrichten bereits mit falschen Daten am Ziel. CloudM mit aktivierter Einstellung erneut auszufuhren erstellt nur Duplikate, es repariert nicht, was schon da ist.

Zweitens hat diese Einstellung eine harte Limitierung, wenn Google Workspace das Ziel ist. Googles eigene Dokumentation bestatigt es: Gmail uberschreibt Received:-Header bei uber API eingefugten Nachrichten immer mit dem Einfugezeitstempel. Das ist eine Einschrankung auf Plattformebene, die CloudM nicht umgehen kann. Selbst mit aktiviertem "Strip Received Headers" fugt Google Workspace seinen eigenen Received:-Header mit dem Migrationsdatum hinzu.

Fur Microsoft-365-Ziele funktioniert die Einstellung theoretisch besser, aber die M365-Transportpipeline hat ihr eigenes Verhalten. Exchange Online kann das INTERNALDATE trotzdem basierend auf seiner eigenen Zustellungsverarbeitung setzen, je nachdem wie die Nachricht ins System gelangt.

Welche CloudM-Migrationen Daten zerstoren (und welche nicht)

Nicht jede CloudM-Migration erzeugt falsche Daten. Das Ergebnis hangt von der Quell-Ziel-Kombination und dem spezifischen API-Pfad ab, den CloudM verwendet:

• Google Workspace zu Microsoft 365: Daten gehen kaputt. CloudM liest uber die Gmail-API und schreibt in Exchange. Die M365-Transportschicht stempelt neue Received-Header.
• Microsoft 365 zu Google Workspace: Daten gehen kaputt. Selbst mit Strip Received Headers uberschreibt Googles API den Received-Header mit dem Einfugedatum. CloudMs Support-Dokumentation nennt dies eine "strenge Plattformlimitierung".
• Google Workspace zu Google Workspace: Daten gehen kaputt. Domainwechsel, Tenant-Konsolidierungen, Fusionen, der Ziel-Google-Tenant stempelt immer das Migrationsdatum auf eingehende Nachrichten.
• Exchange On-Premises zu Microsoft 365: Geht uberwiegend uber den IMAP-Pfad kaputt. Wenn CloudM auf beiden Seiten EWS nutzt, ist die Datumsbewahrung zuverlassiger, aber nicht garantiert.
• IMAP-Quelle (generisch) zu beliebigem Ziel: Daten gehen kaputt. Wenn CloudM sich als Quelle mit einem generischen IMAP-Server verbindet, fugt das Ziel trotzdem seine eigenen Zustellungs-Header hinzu.

Der heikle Punkt? CloudMs Migrations-Dashboard signalisiert nichts davon. Der Fortschrittsbalken fullt sich, die Statusspalte sagt "Completed", die Elementzahlen stimmen. Aus CloudMs Sicht war die Migration erfolgreich. Und technisch gesehen stimmt das. Die Nachrichten wurden ubertragen. Die Daten haben die Reise nur nicht uberlebt.

CloudM Managed vs. Self-Service: Dasselbe Datumsproblem

CloudM bietet zwei Bereitstellungsmodelle. Die SaaS-Version (CloudM Migrate gehostet) lauft vollstandig in CloudMs Infrastruktur. Die selbst gehostete Version ermoglicht es Ihnen, primare und sekundare Migrationsserver in Ihrem eigenen Netzwerk, Google Cloud, Azure oder AWS bereitzustellen.

Manche MSPs nehmen an, die selbst gehostete Option biete mehr Kontrolle uber die Datumsbehandlung, da man die Migrationsserver direkt verwaltet. Tut sie nicht. Das Datumsproblem tritt am Zielserver auf, nicht auf CloudMs Verarbeitungsknoten. Ob Ihre Migrationsfarm in CloudMs Cloud oder auf Ihrer eigenen Azure-VM lauft, der Ziel-Mailserver stempelt trotzdem das Migrationsdatum auf jede empfangene Nachricht.

CloudM bietet auch eine vollstandig verwaltete "Serviced Migration" an, bei der deren Team das Projekt komplett ubernimmt. Gleiches Ergebnis fur Daten. Die Technik ist identisch, tatsachlich sitzen nur andere Hande an der Tastatur. Haben Sie schon mal fur einen Premium-Service bezahlt und trotzdem dieselbe Einschrankung wie beim kostenlosen Tarif bekommen? Genau so fuhlt sich das an.

Die Komplikation mit ungultigen Date-Headern

Es gibt ein weiteres CloudM-spezifisches Verhalten, das die Sache verschlimmert. Wenn CloudM auf eine Quell-E-Mail mit einem Date:-Header stosst, der nicht RFC 822 entspricht (fehlerhafte Zeitzone, fehlender Wochentag, nicht standardkonformes Format), andert CloudM den Header, damit die Nachricht migriert werden kann.

Das bedeutet, dass manche E-Mails sogar ihre ursprungliche Datumsreferenz verlieren. Der modifizierte Date:-Header stimmt moglicherweise uberhaupt nicht mit dem tatsachlichen Sendedatum uberein. CloudMs Support-Dokumentation erwahnt dieses Verhalten unter "Possible Changes to Migrated Items", spezifiziert aber nicht, was das modifizierte Datum wird.

Bei einem Postfach mit 12.000 Nachrichten, die uber acht Jahre angesammelt wurden, konnten Hunderte von E-Mails mit leicht nicht standardkonformen Date-Headern dabei sein (besonders Nachrichten von alteren Mailservern, automatisierten Systemen oder internationalen Absendern mit Besonderheiten bei der Zeitzonen-Formatierung). Nach CloudMs Modifikation plus der Received-Header-Uberschreibung durch den Zielserver landen diese Nachrichten mit Daten, die keinerlei Ahnlichkeit mit der Realitat haben.

Warum manuelle Korrekturen nach CloudM nicht skalieren

Konnte man das selbst reparieren? Technisch ist der originale Date:-Header noch in den meisten Nachrichten eingebettet (ausser bei denen, die CloudM fur RFC-Konformitat modifiziert hat). Einige Administratoren haben versucht, Skripte zu schreiben, um Daten nach einer CloudM-Migration zu korrigieren.

Hier die Realitat dieses Ansatzes. Sie mussen sich moglicherweise mit Tausenden von Postfachern verbinden, jedes mit Tausenden von Nachrichten. Fur jede E-Mail mussen Sie die vollstandige Header-Kette parsen, identifizieren welche Received:-Header CloudM oder der Zielserver hinzugefugt hat, die Randfalle behandeln (S/MIME-signierte Nachrichten bei denen Header-Anderungen die Signatur brechen, PGP-verschlusselte Inhalte, Multipart-MIME-Strukturen mit verschachtelten Boundaries, RFC-2047-kodierte Nicht-ASCII-Header von japanischen oder koreanischen Absendern), und all das ohne einen einzigen Anhang zu verlieren oder das E-Mail-Threading zu zerstoren.

Ein Skript, das bei 50 Test-E-Mails aus einem sauberen Postfach funktioniert, uberlebt den Kontakt mit einer Produktionsumgebung von 40.000 Nachrichten uber ein Jahrzehnt nicht. Was passiert, wenn Sie auf eine 47-MB-E-Mail mit sechs verschachtelten Anhangen stossen? Was ist mit den API-Ratenlimits (250 Quota-Einheiten pro Benutzer pro Sekunde bei Google, Microsofts Drosselung bei etwa 10.000 Anfragen pro 10 Minuten)? Was ist Ihr Rollback-Plan, wenn bei Nachricht Nummer 8.347 etwas schiefgeht?

Und die eigentliche Frage, die die meisten Administratoren erst stellen, wenn es zu spat ist: Wie verifizieren Sie, dass jede korrigierte Nachricht tatsachlich intakt ist?

CloudM-Migrationsdaten korrigieren mit Redate.io

Redate.io verbindet sich direkt mit den betroffenen Postfachern (Google Workspace, Microsoft 365 oder IMAP) und scannt nach E-Mails, die CloudMs Migrationsdatums-Signatur tragen. Der Scan ist kostenlos und dauert ein paar Minuten pro Postfach, wobei die genaue Anzahl betroffener Nachrichten angezeigt wird, bevor irgendeine Verpflichtung entsteht.

Die Korrektur verwendet eine proprietare Header-Ketten-Analyse-Engine, die CloudM-spezifische Migrationsmuster uber die Received-Header-Kette identifiziert. Redate.io fuhrt eine gezielte Metadaten-Korrektur durch, ohne den Nachrichteninhalt zu verandern, wobei Anhange, Threading, Labels, Ordner und digitale Signaturen erhalten bleiben. Jede korrigierte Nachricht durchlauft eine individuelle Verifizierung, bei der die Nachrichtenintegritat gegen das Original gepruft wird, bevor der Prozess fortfahrt.

Original-E-Mails werden in einem sichtbaren Sicherungsordner Redate.io - Originals fur 30 Tage aufbewahrt. Falls etwas zuruckgesetzt werden muss, sind die Originale direkt im Postfach, nicht in irgendeinem externen Archiv vergraben.

Fur MSPs, die CloudM in Kundenumgebungen eingesetzt haben, handhabt Redate.io Korrekturen uber mehrere Postfacher hinweg mit derselben Verifizierung pro Nachricht, ob Sie 1 Postfach oder 500 reparieren. Das Datumsproblem, das CloudM hinterlassen hat, muss kein dauerhaftes Merkmal der Mailumgebung Ihres Kunden werden.

Plattformspezifische Anleitungen fur CloudM-Migrationen

Der Korrekturprozess passt sich an die Zielplattform an. Redate.io handhabt die Besonderheiten jeder Plattform automatisch, aber fur Details zu Ihrem Setup:

• CloudM-Migrationsdaten in Gmail korrigieren
• CloudM-Migrationsdaten in Outlook korrigieren
• CloudM-Migrationsdaten in Google Workspace korrigieren
• CloudM-Migrationsdaten in Microsoft 365 korrigieren

Fur eine ausfuhrliche Erklarung, warum dies bei allen Migrationstools passiert (nicht nur bei CloudM), lesen Sie warum E-Mails nach der Migration falsche Daten anzeigen.

Mit CloudM migriert und jetzt falsche Daten auf jeder E-Mail? Starten Sie einen kostenlosen Scan, um genau zu sehen, wie viele Nachrichten betroffen sind und was die Korrektur kostet.