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 op het moment dat de kopie wordt geschreven. De bestemming behoudt de datum die wordt meegegeven: Microsoft 365 en Gmail bewaren de oorspronkelijke datum als de kopie die datum meekrijgt. Gebeurt dat niet, dan krijgt de kopie het moment van invoegen als datum. En op Google Workspace krijgt elk bericht dat via de Gmail API wordt geschreven ook een verse Received:-header, gedateerd op het moment van invoegen.

Zo ziet u wat de headers van zo'n e-mail nog steeds bevatten na een CloudM-migratie naar Microsoft 365:

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

De originele Date:-header uit 2019 staat er nog, en de originele Received:-keten ook. Maar in Microsoft 365 is de datum die Outlook als ontvangen toont de eigen registratie van de mailbox over het moment van aankomst: als CloudM de oorspronkelijke datum niet heeft doorgegeven, zegt die registratie 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 is de instelling minder belangrijk: Microsoft 365 behoudt de datum die wordt meegegeven, dus wat de weergegeven datum bepaalt, is of CloudM de oorspronkelijke datum van elke e-mail doorgeeft.

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, en elke e-mail krijgt de datum van de kopie.
• 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: elk bericht dat via de Gmail API wordt geschreven, krijgt een Received:-header gedateerd op het moment van de migratie.
• On-premises Exchange naar Microsoft 365: Het hangt volledig af van de datum die CloudM doorgeeft, of de kopie nu via IMAP of via EWS verloopt.
• IMAP-bron (generiek) naar elke bestemming: Dezelfde regel: wanneer CloudM verbinding maakt met een generieke IMAP-server als bron, krijgt de kopie de migratiedatum zodra de oorspronkelijke datum niet wordt doorgegeven aan de bestemming.

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. Wat de datum bepaalt, is wat de migratie-engine meegeeft bij elk bericht, en die engine is overal hetzelfde. Of uw migratiefarm nu in CloudM's cloud draait of op uw eigen Azure-VM, het resultaat voor de datums is hetzelfde.

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 een kopie die de oorspronkelijke datum niet meekrijgt, 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 waarvan de weergegeven datum niet overeenkomt met de oorspronkelijke datum. 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 eigen headerketenanalyse-engine, die niet moet weten welke tool de migratie heeft uitgevoerd. 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 totdat u ze zelf verwijdert. 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.