English
Français
Deutsch
Español
Português
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Türkçe
Ελληνικά
Русский
Polski
Čeština
Українська
Magyar
Română
Български
Hrvatski
Srpski
Slovenčina
Slovenščina
Lietuvių
Latviešu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
Das CloudM-Migrate-Datumsproblem, vor dem niemand warnt
CloudM Migrate hat den Job erledigt. Das Dashboard zeigt 100 % abgeschlossen, alle Benutzer migriert, null Fehler. Sie schließen das Projektticket und wenden sich dem nächsten Kunden zu.
Eine Woche später ruft der IT-Leiter an. "Warum zeigt jede E-Mail in meinem Postfach den 2. April?"
Nicht einige E-Mails. Alle. Fünf Jahre Kundenkorrespondenz, Rechtsdokumente, Personalunterlagen, Bestellungen aus 2020, alles mit dem Datum, an dem CloudM die Migration ausgeführt hat. Die Nachrichten sind da, der Inhalt ist intakt, Anhänge sind in Ordnung. Aber das Datum stimmt bei jeder einzelnen E-Mail nicht.
Das ist kein CloudM-Bug. Die Support-Dokumentation von CloudM räumt das offen ein. Das Problem liegt an der Schnittstelle zwischen der Art, wie Migrationstools Nachrichten übertragen, und wie Ziel-Mailserver eingehende E-Mail-Metadaten verarbeiten. Aber dieses Wissen hilft Ihrem Kunden nicht, dessen Posteingang plötzlich chronologisch unsortierbar geworden ist.
Wie CloudM E-Mail-Nachrichten tatsächlich überträgt
CloudM Migrate verbindet sich über APIs mit Quell- und Zielplattformen. Für Google Workspace bedeutet das ein Dienstkonto mit domainweiter Delegation (konfiguriert in der Google Admin Console unter Sicherheit > API-Steuerung). Für Microsoft 365 verwendet CloudM je nach Migrationspfad entweder Exchange Web Services oder die Microsoft Graph API.
Wenn CloudM eine Nachricht von der Quelle liest, erhält es den vollständigen RFC-2822-Inhalt, einschließlich aller Original-Header und des Nachrichtentexts. Der ursprüngliche Date:-Header (der Zeitstempel, den der Mailserver des Absenders beim erstmaligen Versand gesetzt hat) kommt intakt mit. Ebenso alle ursprünglichen Received:-Header, die den Zustellungsweg der Nachricht nachzeichnen.
Das Problem entsteht beim Schreiben der Kopie. Das Ziel behält das Datum, das es erhält: Microsoft 365 und Gmail bewahren das Originaldatum, wenn die Kopie es mitbringt. Bringt sie es nicht mit, erhält die Kopie den Moment des Einfügens als ihr Datum. Und bei Google Workspace erhält jede Nachricht, die über die Gmail-API geschrieben wird, zusätzlich einen frischen Received:-Header mit dem Zeitpunkt des Einfügens.
So sehen die Header einer dieser E-Mails nach einer CloudM-Migration zu Microsoft 365 immer noch aus:
Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200
Der ursprüngliche Date:-Header von 2019 ist noch da, ebenso die ursprüngliche Received:-Kette. Aber in Microsoft 365 ist das Datum, das Outlook als Empfangsdatum anzeigt, der eigene Eintrag des Postfachs dafür, wann jede E-Mail eingetroffen ist: Wenn CloudM das Originaldatum nicht übergeben hat, sagt dieser Eintrag 2. April 2026.
CloudMs Einstellung "Strip Received Headers"
CloudM bietet tatsächlich eine Einstellung dafür an. In den erweiterten Einstellungen der Zielplattform gibt es unter Message Options einen "Strip Received Headers"-Schalter. Ist er aktiviert, entfernt CloudM die Received-Header vor dem Einfügen der Nachricht und ersetzt sie durch einen einzelnen Header, der dem Date:-Header der E-Mail entspricht.
Klingt so, als würde das alles lösen, 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 liegen die Nachrichten bereits mit falschem Datum am Ziel. CloudM mit aktivierter Einstellung erneut auszuführen, erzeugt nur Duplikate, es korrigiert nicht, was schon da ist.
Zweitens hat diese Einstellung eine harte Grenze, wenn Google Workspace das Ziel ist. Googles eigene Dokumentation bestätigt es: Gmail fügt bei über die API eingefügten Nachrichten immer eine zusätzliche Received:-Zeile hinzu, versehen mit dem Zeitstempel des Einfügens. Das ist eine Einschränkung auf Plattformebene, die CloudM nicht umgehen kann. Selbst mit aktiviertem "Strip Received Headers" fügt Google Workspace seinen eigenen Received:-Header mit dem Migrationsdatum hinzu.
Für Microsoft-365-Ziele spielt die Einstellung eine kleinere Rolle: Microsoft 365 behält das Datum, das es erhält, also entscheidet allein, ob CloudM das Originaldatum jeder E-Mail übergibt, welches Datum angezeigt wird.
Bei welchen CloudM-Migrationen das Datum verloren geht (und bei welchen nicht)
Nicht jede CloudM-Migration führt zu einem falschen Datum. Das Ergebnis hängt von der Quell-Ziel-Kombination und dem jeweiligen API-Pfad ab, den CloudM verwendet:
- Google Workspace zu Microsoft 365: Das Datum geht verloren, wenn CloudM es nicht übergibt. CloudM liest über die Gmail-API und schreibt nach Exchange; ohne Originaldatum erhält jede E-Mail das Datum der Kopie.
- Microsoft 365 zu Google Workspace: Das Datum geht verloren. Selbst mit "Strip Received Headers" fügt Googles API einen
Received:-Header mit dem Einfügedatum hinzu. CloudMs Support-Dokumentation nennt das eine "strenge Plattformeinschränkung". - Google Workspace zu Google Workspace: Das Datum geht verloren. Bei Domainwechseln, Tenant-Zusammenführungen und Übernahmen erhält jede über die Gmail-API geschriebene Nachricht einen
Received:-Header, der auf die Migration datiert ist. - Exchange On-Premises zu Microsoft 365: Alles hängt davon ab, welches Datum CloudM übergibt, egal ob die Kopie über IMAP oder EWS läuft.
- IMAP-Quelle (generisch) zu beliebigem Ziel: Dieselbe Regel: Verbindet sich CloudM mit einem generischen IMAP-Server als Quelle, zeigt die Kopie das Migrationsdatum, sobald das Originaldatum nicht an das Ziel übergeben wird.
Der Haken? CloudMs Migrations-Dashboard zeigt davon nichts an. Der Fortschrittsbalken füllt sich, die Statusspalte sagt "Completed", die Anzahl der Elemente stimmt. Aus CloudMs Sicht war die Migration erfolgreich. Und technisch gesehen stimmt das. Die Nachrichten wurden übertragen. Nur das Datum hat die Reise nicht überlebt.
CloudM Managed vs. Self-Service: Dasselbe Datumsproblem
CloudM bietet zwei Bereitstellungsmodelle an. Die SaaS-Version (CloudM Migrate, gehostet) läuft vollständig in CloudMs Infrastruktur. Die selbst gehostete Version erlaubt es Ihnen, primäre und sekundäre Migrationsserver in Ihrem eigenen Netzwerk, in Google Cloud, Azure oder AWS bereitzustellen.
Manche MSPs nehmen an, die selbst gehostete Option biete mehr Kontrolle über die Datumsbehandlung, weil man die Migrationsserver selbst verwaltet. Das ist nicht so. Entscheidend ist, welches Datum die Migrations-Engine bei jeder Nachricht mitgibt, und diese Engine ist überall dieselbe. Ob Ihre Migrationsfarm in CloudMs Cloud oder auf Ihrer eigenen Azure-VM läuft, das Ergebnis für das Datum bleibt gleich.
CloudM bietet außerdem eine vollständig verwaltete "Serviced Migration" an, bei der das eigene Team das Projekt von Anfang bis Ende übernimmt. Gleiches Ergebnis beim Datum. Die Technik ist identisch, nur die Hände an der Tastatur sind andere. Haben Sie schon mal für einen Premium-Service bezahlt und trotzdem dieselbe Einschränkung wie beim kostenlosen Tarif erlebt? Genau so fühlt sich das an.
Die Komplikation mit ungültigen Date-Headern
Es gibt noch ein weiteres CloudM-spezifisches Verhalten, das die Sache verschlimmert. Stößt CloudM auf eine Quell-E-Mail mit einem Date:-Header, der nicht RFC 822 entspricht (fehlerhafte Zeitzone, fehlender Wochentag, nicht standardkonformes Format), ändert CloudM den Header, damit die Nachricht migriert werden kann.
Das bedeutet, dass manche E-Mails sogar ihren ursprünglichen Datumsbezug verlieren. Der geänderte Date:-Header stimmt möglicherweise überhaupt nicht mit dem tatsächlichen Sendedatum überein. CloudMs Support-Dokumentation erwähnt dieses Verhalten unter "Possible Changes to Migrated Items", spezifiziert aber nicht, welches Datum daraus wird.
Bei einem Postfach mit 12.000 Nachrichten, die sich über acht Jahre angesammelt haben, können Hunderte E-Mails mit leicht nicht standardkonformen Date-Headern dabei sein (besonders Nachrichten von älteren Mailservern, automatisierten Systemen oder internationalen Absendern mit Eigenheiten bei der Zeitzonenformatierung). Nach der Änderung durch CloudM, und wenn die Kopie zusätzlich das Originaldatum nicht mitbringt, landen diese Nachrichten mit einem Datum, das mit der Wirklichkeit nichts mehr zu tun hat.
Warum manuelle Korrekturen nach CloudM nicht skalieren
Könnten Sie das selbst korrigieren? Technisch ist der ursprüngliche Date:-Header noch in den meisten Nachrichten eingebettet (außer bei denen, die CloudM zur RFC-Konformität geändert hat). Manche Administratoren haben versucht, Skripte zu schreiben, um das Datum nach einer CloudM-Migration zu korrigieren.
Hier ist die Realität dieses Ansatzes. Sie müssen sich mit potenziell Tausenden von Postfächern verbinden, jedes mit Tausenden von Nachrichten. Für jede E-Mail müssen Sie die vollständige Header-Kette parsen, feststellen, welche Received:-Header CloudM oder der Zielserver hinzugefügt hat, die Randfälle behandeln (S/MIME-signierte Nachrichten, bei denen eine Header-Änderung die Signatur zerstört, PGP-verschlüsselte Inhalte, Multipart-MIME-Strukturen mit verschachtelten Boundaries, RFC-2047-kodierte Nicht-ASCII-Header von japanischen oder koreanischen Absendern), und das alles, ohne einen einzigen Anhang zu verlieren oder das E-Mail-Threading zu zerstören.
Ein Skript, das bei 50 Test-E-Mails aus einem sauberen Postfach funktioniert, überlebt den Kontakt mit einer Produktionsumgebung von 40.000 Nachrichten über ein Jahrzehnt nicht. Was passiert, wenn Sie auf eine 47-MB-E-Mail mit sechs verschachtelten Anhängen stoßen? Was ist mit den API-Ratenlimits (250 Kontingenteinheiten pro Nutzer und Sekunde bei Google, Drosselung auf etwa 10.000 Anfragen pro 10 Minuten bei Microsoft)? Was ist Ihr Rollback-Plan, wenn bei Nachricht Nummer 8.347 etwas schiefgeht?
Und die wirklich wichtige Frage, die sich die meisten Administratoren erst stellen, wenn es zu spät ist: Wie verifizieren Sie, dass jede korrigierte Nachricht tatsächlich intakt ist?
CloudM-Migrationsdaten mit Redate.io korrigieren
Redate.io verbindet sich direkt mit den betroffenen Postfächern (Google Workspace, Microsoft 365 oder IMAP) und überprüft sie auf E-Mails, deren angezeigtes Datum nicht mit ihrem Originaldatum übereinstimmt. Die Überprüfung ist kostenlos und dauert wenige Minuten pro Postfach; sie zeigt die genaue Anzahl betroffener Nachrichten, bevor Sie sich zu irgendetwas verpflichten.
Die Korrektur nutzt eine firmeneigene Engine zur Analyse der Header-Kette, die nicht wissen muss, welches Tool die Migration durchgeführt hat. Redate.io führt eine gezielte Metadaten-Korrektur durch, ohne den Nachrichteninhalt zu verändern, und erhält Anhänge, Threading, Labels, Ordner und digitale Signaturen. Jede korrigierte Nachricht durchläuft eine individuelle Prüfung, bei der die Nachrichtenintegrität mit dem Original verglichen wird, bevor der Prozess fortgesetzt wird.
Original-E-Mails werden in einem sichtbaren Sicherungsordner Redate.io - Originals aufbewahrt, bis Sie ihn selbst löschen. Muss etwas zurückgesetzt werden, liegen die Originale direkt im Postfach, nicht in irgendeinem externen Archiv vergraben.
Für MSPs, die CloudM in Kundenumgebungen eingesetzt haben, übernimmt Redate.io Korrekturen über viele Postfächer hinweg, mit derselben Prüfung pro Nachricht, ob Sie 1 Postfach oder 500 korrigieren. Das Datumsproblem, das CloudM hinterlassen hat, muss kein dauerhaftes Merkmal der Mailumgebung Ihres Kunden bleiben.
Plattformspezifische Anleitungen für CloudM-Migrationen
Der Korrekturprozess passt sich an die Zielplattform an. Redate.io übernimmt die Besonderheiten jeder Plattform automatisch, aber für 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
Für eine ausführlichere Erklärung, warum das bei allen Migrationstools passiert, nicht nur bei CloudM, siehe warum E-Mails nach der Migration ein falsches Datum zeigen.
Mit CloudM migriert und jetzt mit falschem Datum auf jeder E-Mail? Starten Sie eine kostenlose Überprüfung, um genau zu sehen, wie viele Nachrichten betroffen sind und was die Korrektur kostet.