CloudM Migrate: Ret forkerte e-maildatoer

CloudM Migrates datoproblem, som ingen advarer dig om

CloudM Migrate har gjort sit arbejde. Dashboardet viser 100 % faerdigt, alle brugere migreret, nul fejl. Du lukker projektsagen og gar videre til den naeste kunde.

En uge senere ringer IT-chefen. "Hvorfor viser hver eneste e-mail i min indbakke den 2. april?"

Ikke nogle e-mails. Alle. Fem ars kundekorrespondance, juridiske dokumenter, HR-optegnelser, indkobsordrer fra 2020, alt sammen med den dato, CloudM korte migreringen. Beskederne er der, indholdet er intakt, vedhaeftninger er fine. Men datoerne er forkerte pa hver eneste en.

Det er ikke en CloudM-fejl. CloudMs egen supportdokumentation anerkender det abent. Problemet ligger i krydsfeltet mellem, hvordan migreringsvaerktojerne overforer beskeder, og hvordan destinationsmailservere handterer indgaende e-mailmetadata. Men den viden hjaelper ikke din kunde, hvis indbakke pludselig er umulig at sortere kronologisk.

Hvordan CloudM faktisk overforer e-mailbeskeder

CloudM Migrate forbinder til kilde- og destinationsplatforme via deres API'er. For Google Workspace betyder det en servicekonto med domaenembredelegering (konfigureret i Google Admin Console under Sikkerhed > API-styring). For Microsoft 365 bruger CloudM enten Exchange Web Services eller Microsoft Graph API, afhangigt af migrationsstien.

Nar CloudM laeser en besked fra kilden, far den det fulde RFC 2822-indhold, inklusive alle originale headers og beskedteksten. Den originale Date:-header (den som afsenderens mailserver stemplede, da e-mailen forst blev sendt) folger intakt med. Det samme galder alle originale Received:-headers, der sporer beskedens leveringssti.

Problemet opstar ved destinationen. Nar CloudM skriver den besked ind i malpostkassen, behandler destinationsserveren den som en ny levering. Den stempler en frisk Received:-header med den aktuelle dato og tid og saetter INTERNALDATE (det tidsstempel, IMAP bruger til sortering) til indsaettelsestidspunktet.

Sadan ser headerkaden ud efter en CloudM-migrering til 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

2019-headeren er der stadig. Den originale Date:-header siger stadig 23. september 2019. Men Outlook laeser den overste Received:-header for at bestemme visningsraekkefolgen, og den siger 2. april 2026.

CloudMs "Strip Received Headers"-indstilling

CloudM tilbyder en indstilling til at lose dette. I destinationsplatformens avancerede indstillinger under Message Options er der en "Strip Received Headers"-kontakt. Nar den er aktiveret, fjerner CloudM Received-headerne for indsaettelse af beskeden og erstatter dem med en enkelt header, der matcher e-mailens Date:-header.

Det lyder som om det loser alt, ikke? Ikke helt.

For det forste skal du kende til indstillingen, for du korer migreringen. De fleste administratorer opdager datoproblemet efter migreringen er afsluttet. Pa det tidspunkt sidder beskederne allerede pa destinationen med forkerte datoer. At kore CloudM igen med indstillingen aktiveret opretter bare duplikater, det retter ikke det, der allerede er der.

For det andet har denne indstilling en haard begransning, nar Google Workspace er destinationen. Googles egen dokumentation bekraefter det: Gmail omskriver altid Received:-headers pa beskeder indsat via API og stempler dem med indsaettelsestidsstemplet. Det er en platformsbegransning, som CloudM ikke kan omga. Selv med "Strip Received Headers" aktiveret tilfojer Google Workspace sin egen Received:-header med migreringsdatoen.

For Microsoft 365-destinationer fungerer indstillingen bedre i teorien, men M365-transportpipelinen har sin egen adfard. Exchange Online kan stadig saette INTERNALDATE baseret pa sin egen leveringsbehandling, alt efter hvordan beskeden kommer ind i systemet.

Hvilke CloudM-migreringer odelagger datoer (og hvilke gor ikke)

Ikke alle CloudM-migreringer producerer forkerte datoer. Resultatet afhaenger af kilde-destinationskombinationen og den specifikke API-sti, CloudM bruger:

• Google Workspace til Microsoft 365: Datoer gar i stykker. CloudM laeser via Gmail API og skriver til Exchange. M365-transportlaget stempler nye Received-headers.
• Microsoft 365 til Google Workspace: Datoer gar i stykker. Selv med Strip Received Headers omskriver Googles API Received-headeren med indsaettelsesdatoen. CloudMs supportdokumentation kalder det en "streng platformsbegransning".
• Google Workspace til Google Workspace: Datoer gar i stykker. Domaeneskift, tenantkonsolideringer, fusioneropkob, destinationens Google-tenant stempler altid migreringsdatoen pa indgaende beskeder.
• On-premises Exchange til Microsoft 365: Gar normalt i stykker via IMAP-stien. Hvis CloudM bruger EWS pa begge sider, er datobevaring mere palidelig, men ikke garanteret.
• IMAP-kilde (generisk) til enhver destination: Datoer gar i stykker. Nar CloudM forbinder til en generisk IMAP-server som kilde, tilfojer destinationen stadig sine egne leveringsheaders.

Den svaere del? CloudMs migreringsdashboard signalerer intet af dette. Fremskridtslinjen fylder op, statuskolonnen siger "Completed", elementtaellingerne stemmer. Fra CloudMs perspektiv var migreringen vellykket. Og teknisk set var den det. Beskederne blev overfort. Datoerne overlevede bare ikke turen.

CloudM Managed vs. Self-Service: samme datoproblem

CloudM tilbyder to deployeringsmodeller. SaaS-versionen (CloudM Migrate hostet) korer helt i CloudMs infrastruktur. Den selvhostede version lader dig deploye primaere og sekundaere migreringsservere pa dit eget netvaerk, Google Cloud, Azure eller AWS.

Nogle MSP'er antager, at den selvhostede mulighed giver mere kontrol over datohandtering, da du administrerer migreringsserverne direkte. Det gor den ikke. Datoproblemet sker pa destinationsserveren, ikke pa CloudMs behandlingsnoder. Uanset om din migreringsfarm korer i CloudMs cloud eller pa din egen Azure-VM, stempler destinationsmailserveren stadig migreringsdatoen pa hver besked, den modtager.

CloudM tilbyder ogsa en fuldt styret "Serviced Migration", hvor deres team handterer projektet fra ende til anden. Samme resultat for datoer. Teknikken er identisk, faktisk er det bare andre haender pa tastaturet. Har du nogensinde betalt for en premiumtjeneste og stadig faet den samme begransning som det gratis niveau? Sadan foler det sig ud.

Komplikationen med ugyldige Date-headers

Der er endnu en CloudM-specifik adfard, der gor tingene vaerre. Nar CloudM moder en kilde-e-mail med en Date:-header, der ikke overholder RFC 822 (fejlformateret tidszone, manglende ugedag, ikke-standardformat), aendrer CloudM headeren for at sikre, at beskeden kan migreres.

Det betyder, at nogle e-mails endda mister deres originale datoreference. Den aendrede Date:-header matcher maaske slet ikke den rigtige afsendelsesdato. CloudMs supportdokumentation naevner denne adfard under "Possible Changes to Migrated Items", men specificerer ikke, hvad den aendrede dato bliver.

For en postkasse med 12.000 beskeder samlet over otte ar kan der vaere hundredvis af e-mails med let ikke-standard Date-headers (saerligt beskeder fra aeldre mailservere, automatiserede systemer eller internationale afsendere med tidszoneformateringsegenarter). Efter CloudMs aendring plus destinationsserverens Received-header-omskrivning ender disse beskeder med datoer, der ikke ligner virkeligheden.

Hvorfor manuelle rettelser ikke skalerer efter CloudM

Kunne du rette det selv? Teknisk set er den originale Date:-header stadig indlejret i de fleste beskeder (undtagen dem CloudM aendrede for RFC-overensstemmelse). Nogle administratorer har forsogt at skrive scripts til at rette datoer efter en CloudM-migrering.

Her er realiteten i den tilgang. Du skal forbinde til potentielt tusindvis af postkasser, hver med tusindvis af beskeder. For hver e-mail skal du parse den fulde headerkade, identificere hvilke Received:-headers CloudM eller destinationsserveren tilfoejede, handtere kanttilfaeldene (S/MIME-signerede beskeder hvor headeraendring bryder signaturen, PGP-krypteret indhold, multipart MIME-strukturer med indlejrede graenser, RFC 2047-kodede ikke-ASCII-headers fra japanske eller koreanske afsendere), og gore alt dette uden at miste en eneste vedhaeftning eller bryde e-mailthrading.

Et script, der virker pa 50 teste-mails fra en ren postkasse, overlever ikke kontakten med et produktionsmiljo med 40.000 beskeder over et arti. Hvad sker der, nar du rammer en 47 MB e-mail med seks indlejrede vedhaeftninger? Hvad med API-hastighedsgraenserne (250 kvotaenheder per bruger per sekund hos Google, Microsofts throttling ved omkring 10.000 anmodninger per 10 minutter)? Hvad er din rollbackplan, nar noget gar galt ved besked nummer 8.347?

Og det egentlige sporgsmal, som de fleste administratorer forst stiller, nar det er for sent: hvordan verificerer du, at hver rettet besked faktisk er intakt?

Ret CloudM-migreringsdatoer med Redate.io

Redate.io forbinder direkte til de berarte postkasser (Google Workspace, Microsoft 365 eller IMAP) og scanner for e-mails, der baerer CloudMs migreringsdatosignatur. Scanningen er gratis og tager et par minutter per postkasse og viser det praecise antal berarte beskeder for nogen forpligtelse.

Korrektionen bruger en proprietaer headerkadeanalysemotor, der identificerer CloudM-specifikke migreringsmonstre pa tvaers af Received-headerkaden. Redate.io udforer malrettet metadatakorrektion uden at aendre beskedindholdet og bevarer vedhaeftninger, threading, labels, mapper og digitale signaturer. Hver rettet besked gennemgar individuel verifikation, hvor beskedintegriteten kontrolleres mod originalen, for processen gar videre.

Originale e-mails opbevares i en synlig sikkerhedskopieringsmappe Redate.io - Originals i 30 dage. Hvis noget skal rulles tilbage, er originalerne lige der i postkassen, ikke begravet i et eksternt arkiv.

For MSP'er, der brugte CloudM pa kundemiljoer, handterer Redate.io korrektioner pa tvaers af flere postkasser i stor skala med den samme verifikation per besked, uanset om du retter 1 postkasse eller 500. Datoproblemet, som CloudM efterlod, behover ikke at blive et permanent traek ved din kundes e-mailmiljo.

Platformspecifikke vejledninger for CloudM-migreringer

Korrektionsprocessen tilpasser sig destinationsplatformen. Redate.io handterer hver platforms specifikationer automatisk, men for detaljer om dit setup:

• Ret CloudM-migreringsdatoer i Gmail
• Ret CloudM-migreringsdatoer i Outlook
• Ret CloudM-migreringsdatoer i Google Workspace
• Ret CloudM-migreringsdatoer i Microsoft 365

For en dybere forklaring af, hvorfor dette sker med alle migreringsvaerktojer (ikke kun CloudM), se hvorfor e-mails viser forkerte datoer efter migrering.

Migreret med CloudM og fast med forkerte datoer pa alle e-mails? Kor en gratis scanning for at se praecis, hvor mange beskeder der er berort, og hvad det koster at rette dem.