CloudM Migrate: verkeerde e-maildatums herstellen

Het CloudM Migrate datumprobleem waar niemand voor waarschuwt

CloudM Migrate heeft de klus geklaard. Het dashboard toont 100 % voltooid, alle gebruikers gemigreerd, nul fouten. U sluit het projectticket en gaat verder met de volgende klant.

Een week later belt de IT-directeur. "Waarom toont elke e-mail in mijn inbox 2 april?"

Niet sommige e-mails. Allemaal. Vijf jaar klantcorrespondentie, juridische documenten, HR-dossiers, inkooporders uit 2020, allemaal met de datum waarop CloudM de migratie uitvoerde. De berichten zijn er, de inhoud is intact, bijlagen zijn in orde. Maar de datums kloppen bij geen enkel bericht.

Dit is geen CloudM-bug. De supportdocumentatie van CloudM erkent het openlijk. Het probleem zit op het snijvlak van hoe migratietools berichten overdragen en hoe doelmailservers inkomende e-mailmetadata verwerken. Maar dat weten helpt uw klant niet wiens inbox onmogelijk chronologisch te sorteren is geworden.

Hoe CloudM e-mailberichten daadwerkelijk overdraagt

CloudM Migrate maakt verbinding met bron- en doelplatforms via hun API's. Voor Google Workspace betekent dat een serviceaccount met domeinbrede delegatie (geconfigureerd in de Google Admin Console onder Beveiliging > API-bediening). Voor Microsoft 365 gebruikt CloudM Exchange Web Services of de Microsoft Graph API, afhankelijk van het migratiepad.

Wanneer CloudM een bericht van de bron leest, krijgt het de volledige RFC 2822-inhoud, inclusief alle originele headers en de berichttekst. De originele Date:-header (die door de mailserver van de afzender werd gestempeld toen het bericht oorspronkelijk werd verzonden) komt intact mee. Net als alle originele Received:-headers die het bezorgpad van het bericht traceren.

Het probleem ontstaat bij de bestemming. Wanneer CloudM dat bericht in de doelmailbox schrijft, behandelt de doelserver het als een nieuwe bezorging. Er wordt een verse Received:-header op gestempeld met de huidige datum en tijd, en het INTERNALDATE (de tijdstempel die IMAP voor sortering gebruikt) wordt ingesteld op het moment van invoegen.

Zo ziet de headerketen eruit na een CloudM-migratie naar Microsoft 365:

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

De header uit 2019 staat er nog. De originele Date:-header zegt nog steeds 23 september 2019. Maar Outlook leest de bovenste Received:-header om de weergavevolgorde te bepalen, en die zegt 2 april 2026.

CloudM's instelling "Strip Received Headers"

CloudM biedt een instelling om dit aan te pakken. In de Geavanceerde Instellingen van het doelplatform, onder Message Options, is er een "Strip Received Headers"-schakelaar. Wanneer ingeschakeld, verwijdert CloudM de Received-headers voordat het bericht wordt ingevoegd en vervangt ze door een enkele header die overeenkomt met de Date:-header van de e-mail.

Klinkt alsof dat alles oplost, toch? Niet helemaal.

Ten eerste moet u ervan weten voordat u de migratie uitvoert. De meeste beheerders ontdekken het datumprobleem nadat de migratie is afgerond. Op dat moment staan de berichten al op de bestemming met verkeerde datums. CloudM opnieuw uitvoeren met de instelling ingeschakeld maakt alleen duplicaten, het herstelt niet wat er al staat.

Ten tweede heeft deze instelling een harde beperking wanneer Google Workspace de bestemming is. Googles eigen documentatie bevestigt het: Gmail herschrijft altijd Received:-headers op berichten die via API worden ingevoegd, met de invoegstijdstempel. Dit is een beperking op platformniveau die CloudM niet kan omzeilen. Zelfs met "Strip Received Headers" ingeschakeld, voegt Google Workspace zijn eigen Received:-header toe met de migratiedatum.

Voor Microsoft 365-bestemmingen werkt de instelling in theorie beter, maar de M365-transportpipeline heeft eigen gedrag. Exchange Online kan het INTERNALDATE eigenlijk nog steeds instellen op basis van zijn eigen bezorgingsverwerking, afhankelijk van hoe het bericht het systeem binnenkomt.

Welke CloudM-migraties datums breken (en welke niet)

Niet elke CloudM-migratie produceert verkeerde datums. Het resultaat hangt af van de bron-doelcombinatie en het specifieke API-pad dat CloudM gebruikt:

• Google Workspace naar Microsoft 365: Datums breken. CloudM leest via de Gmail API en schrijft naar Exchange. De M365-transportlaag stempelt nieuwe Received-headers.
• Microsoft 365 naar Google Workspace: Datums breken. Zelfs met Strip Received Headers herschrijft Googles API de Received-header met de invoegdatum. CloudM's supportdocumentatie noemt dit een "strikte platformbeperking".
• Google Workspace naar Google Workspace: Datums breken. Domeinwisselingen, tenantconsolidaties, overnamefusies, de Google-doeltenant stempelt altijd de migratiedatum op inkomende berichten.
• On-premises Exchange naar Microsoft 365: Breekt doorgaans via het IMAP-pad. Als CloudM EWS aan beide kanten gebruikt, is datumbehoud betrouwbaarder maar niet gegarandeerd.
• IMAP-bron (generiek) naar elke bestemming: Datums breken. Wanneer CloudM verbinding maakt met een generieke IMAP-server als bron, voegt de bestemming toch eigen bezorgheaders toe.

Het lastige? Het CloudM-migratiedashboard signaleert niets hiervan. De voortgangsbalk vult zich, de statuskolom zegt "Completed", de aantallen komen overeen. Vanuit CloudM's perspectief was de migratie geslaagd. En technisch klopt dat. De berichten zijn overgedragen. De datums hebben de reis alleen niet overleefd.

CloudM Managed vs. Self-Service: zelfde datumprobleem

CloudM biedt twee implementatiemodellen. De SaaS-versie (CloudM Migrate gehost) draait volledig in CloudM's infrastructuur. De zelfgehoste versie laat u primaire en secundaire migratieservers implementeren op uw eigen netwerk, Google Cloud, Azure of AWS.

Sommige MSP's nemen aan dat de zelfgehoste optie meer controle geeft over datumverwerking omdat u de migratieservers direct beheert. Dat is niet zo. Het datumprobleem ontstaat bij de doelserver, niet op CloudM's verwerkingsknooppunten. Of uw migratiefarm nu in CloudM's cloud draait of op uw eigen Azure-VM, de doelmailserver stempelt nog steeds de migratiedatum op elk bericht dat binnenkomt.

CloudM biedt ook een volledig beheerde "Serviced Migration" aan waarbij hun team het project van begin tot eind afhandelt. Zelfde uitkomst voor datums. De techniek is identiek, eigenlijk zitten er alleen andere handen aan het toetsenbord. Heeft u ooit betaald voor een premium dienst en toch dezelfde beperking gekregen als bij de gratis versie? Zo voelt het.

De complicatie van ongeldige Date-headers

Er is nog een CloudM-specifiek gedrag dat de zaak verergert. Wanneer CloudM een bronmail tegenkomt met een Date:-header die niet voldoet aan RFC 822 (misvormde tijdzone, ontbrekende dag van de week, niet-standaard formaat), past CloudM de header aan zodat het bericht gemigreerd kan worden.

Dit betekent dat sommige e-mails zelfs hun originele datumreferentie verliezen. De aangepaste Date:-header komt mogelijk helemaal niet overeen met de werkelijke verzenddatum. CloudM's supportdocumentatie noemt dit gedrag onder "Possible Changes to Migrated Items" maar specificeert niet wat de aangepaste datum wordt.

Voor een mailbox met 12.000 berichten verzameld over acht jaar, kunnen er honderden e-mails zijn met licht niet-standaard Date-headers (vooral berichten van oudere mailservers, geautomatiseerde systemen of internationale afzenders met eigenaardigheden in de tijdzoneformattering). Na CloudM's aanpassing plus de Received-header-herschrijving door de doelserver, eindigen deze berichten met datums die geen enkele gelijkenis vertonen met de werkelijkheid.

Waarom handmatige correcties niet schalen na CloudM

Zou u dit zelf kunnen herstellen? Technisch gezien zit de originele Date:-header nog in de meeste berichten (behalve die welke CloudM voor RFC-conformiteit heeft aangepast). Sommige beheerders hebben geprobeerd scripts te schrijven om datums te corrigeren na een CloudM-migratie.

Hier de realiteit van die aanpak. U moet verbinding maken met mogelijk duizenden mailboxen, elk met duizenden berichten. Voor elke e-mail moet u de volledige headerketen parsen, identificeren welke Received:-headers CloudM of de doelserver heeft toegevoegd, de randgevallen afhandelen (S/MIME-ondertekende berichten waarbij headerwijziging de handtekening breekt, PGP-versleutelde inhoud, multipart MIME-structuren met geneste grenzen, RFC 2047-gecodeerde niet-ASCII-headers van Japanse of Koreaanse afzenders), en dit alles zonder een enkele bijlage te verliezen of de e-mailthreading te breken.

Een script dat werkt op 50 testmails uit een schone mailbox overleeft het contact met een productieomgeving van 40.000 berichten over een decennium niet. Wat gebeurt er wanneer u een e-mail van 47 MB tegenkomt met zes geneste bijlagen? En de API-snelheidslimieten (250 quota-eenheden per gebruiker per seconde bij Google, Microsoft's throttling bij ongeveer 10.000 verzoeken per 10 minuten)? Wat is uw rollbackplan wanneer er iets misgaat bij bericht nummer 8.347?

En de echte vraag die de meeste beheerders pas stellen als het te laat is: hoe verifieert u dat elk gecorrigeerd bericht daadwerkelijk intact is?

CloudM-migratiedatums herstellen met Redate.io

Redate.io maakt rechtstreeks verbinding met de getroffen mailboxen (Google Workspace, Microsoft 365 of IMAP) en scant op e-mails die CloudM's migratiedatumsignatuur dragen. De scan is gratis en duurt een paar minuten per mailbox, waarbij het exacte aantal getroffen berichten wordt getoond voordat er enige verplichting is.

De correctie gebruikt een proprietary headerketenanalyse-engine die CloudM-specifieke migratiepatronen identificeert in de Received-headerketen. Redate.io voert gerichte metadatacorrectie uit zonder de berichtinhoud te wijzigen, waarbij bijlagen, threading, labels, mappen en digitale handtekeningen behouden blijven. Elk gecorrigeerd bericht ondergaat individuele verificatie, waarbij de berichtintegriteit wordt gecontroleerd tegen het origineel voordat het proces verder gaat.

Originele e-mails worden bewaard in een zichtbare back-upmap Redate.io - Originals gedurende 30 dagen. Als er iets teruggedraaid moet worden, staan de originelen daar in de mailbox, niet begraven in een extern archief.

Voor MSP's die CloudM op klantomgevingen hebben gebruikt, handelt Redate.io multi-mailboxcorrecties op schaal af, met dezelfde verificatie per bericht of u nu 1 mailbox of 500 herstelt. Het datumprobleem dat CloudM heeft achtergelaten hoeft geen permanent kenmerk van de mailomgeving van uw klant te worden.

Platformspecifieke handleidingen voor CloudM-migraties

Het correctieproces past zich aan het doelplatform aan. Redate.io handelt de specificaties van elk platform automatisch af, maar voor details over uw setup:

• CloudM-migratiedatums in Gmail herstellen
• CloudM-migratiedatums in Outlook herstellen
• CloudM-migratiedatums in Google Workspace herstellen
• CloudM-migratiedatums in Microsoft 365 herstellen

Voor een uitgebreide uitleg waarom dit bij alle migratietools gebeurt (niet alleen CloudM), lees waarom e-mails verkeerde datums tonen na migratie.

Gemigreerd met CloudM en vast met verkeerde datums op elke e-mail? Start een gratis scan om precies te zien hoeveel berichten zijn getroffen en wat het kost om ze te herstellen.