CloudM Migrate: Rett feil e-postdatoer

CloudM Migrates datoproblem som ingen advarer om

CloudM Migrate har gjort jobben. Dashboardet viser 100 % fullfort, alle brukere migrert, null feil. Du lukker prosjektsaken og gar videre til neste kunde.

En uke senere ringer IT-sjefen. "Hvorfor viser hver eneste e-post i innboksen min 2. april?"

Ikke noen e-poster. Alle. Fem ar med kundekorrespondanse, juridiske dokumenter, HR-registreringer, innkjopsordre fra 2020, alt med datoen da CloudM kjorte migreringen. Meldingene er der, innholdet er intakt, vedleggene er fine. Men datoene er feil pa hver eneste en.

Dette er ikke en CloudM-feil. CloudMs egen supportdokumentasjon anerkjenner det apent. Problemet ligger i kryssingspunktet mellom hvordan migreringsverktoy overforer meldinger og hvordan destinasjonens e-postservere handterer innkommende e-postmetadata. Men den kunnskapen hjelper ikke kunden din, som plutselig har en innboks det er umulig a sortere kronologisk.

Hvordan CloudM faktisk overforer e-postmeldinger

CloudM Migrate kobler seg til kilde- og destinasjonsplattformer via deres API-er. For Google Workspace betyr det en tjenestekonto med domenebred delegering (konfigurert i Google Admin Console under Sikkerhet > API-kontroller). For Microsoft 365 bruker CloudM enten Exchange Web Services eller Microsoft Graph API, avhengig av migreringsveien.

Nar CloudM leser en melding fra kilden, far den det fullstendige RFC 2822-innholdet, inkludert alle originale headere og meldingsteksten. Den opprinnelige Date:-headeren (den som avsenderens e-postserver stemplet da e-posten forst ble sendt) folger med intakt. Det samme gjelder alle opprinnelige Received:-headere som sporer meldinggens leveringsvei.

Problemet oppstar ved destinasjonen. Nar CloudM skriver den meldingen inn i destinasjonspostkassen, behandler destinasjonsserveren den som en ny levering. Den stempler en fersk Received:-header med gjeldende dato og tid, og setter INTERNALDATE (tidsstempelet som IMAP bruker for sortering) til tidspunktet for innsetting.

Slik ser headerkjeden ut etter 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 fortsatt. Den opprinnelige Date:-headeren sier fortsatt 23. september 2019. Men Outlook leser den overste Received:-headeren for a bestemme visningsrekkefolgen, og den sier 2. april 2026.

CloudMs "Strip Received Headers"-innstilling

CloudM tilbyr en innstilling for a handtere dette. I destinasjonsplattformens avanserte innstillinger under Message Options er det en "Strip Received Headers"-bryter. Nar den er aktivert, fjerner CloudM Received-headerne for innsetting av meldingen og erstatter dem med en enkelt header som matcher e-postens Date:-header.

Hores ut som det loser alt, ikke sant? Ikke helt.

For det forste ma du kjenne til innstillingen for du kjorer migreringen. De fleste administratorer oppdager datoproblemet etter at migreringen er fullfort. Pa det tidspunktet sitter meldingene allerede pa destinasjonen med feil datoer. A kjore CloudM pa nytt med innstillingen aktivert skaper bare duplikater, det fikser ikke det som allerede er der.

For det andre har denne innstillingen en hard begrensning nar Google Workspace er destinasjonen. Googles egen dokumentasjon bekrefter det: Gmail skriver alltid om Received:-headere pa meldinger satt inn via API, og stempler dem med tidsstempelet for innsetting. Dette er en begrensning pa plattformniva som CloudM ikke kan komme rundt. Selv med "Strip Received Headers" aktivert legger Google Workspace til sin egen Received:-header med migreringsdatoen.

For Microsoft 365-destinasjoner fungerer innstillingen bedre i teorien, men M365-transportpipelinen har sin egen oppforsel. Exchange Online kan fortsatt sette INTERNALDATE basert pa sin egen leveringsbehandling, avhengig av hvordan meldingen kommer inn i systemet.

Hvilke CloudM-migreringer odelegger datoer (og hvilke gjor det ikke)

Ikke alle CloudM-migreringer produserer feil datoer. Resultatet avhenger av kilde-destinasjonskombinasjonen og den spesifikke API-veien CloudM bruker:

• Google Workspace til Microsoft 365: Datoer ryker. CloudM leser via Gmail API og skriver til Exchange. M365-transportlaget stempler nye Received-headere.
• Microsoft 365 til Google Workspace: Datoer ryker. Selv med Strip Received Headers skriver Googles API om Received-headeren med innsettingsdatoen. CloudMs supportdokumentasjon kaller dette en "streng plattformsbegrensning".
• Google Workspace til Google Workspace: Datoer ryker. Domenebytte, tenantkonsolideringer, oppkjopssammenslaainger, destinasjonens Google-tenant stempler alltid migreringsdatoen pa innkommende meldinger.
• Lokal Exchange til Microsoft 365: Gar vanligvis i stykker via IMAP-veien. Hvis CloudM bruker EWS pa begge sider, er datobevaring mer palitelig, men ikke garantert.
• IMAP-kilde (generisk) til en hvilken som helst destinasjon: Datoer ryker. Nar CloudM kobler seg til en generisk IMAP-server som kilde, legger destinasjonen fortsatt til sine egne leveringsheadere.

Den vanskelige delen? CloudMs migreringsdashboard signaliserer ingenting av dette. Fremdriftslinjen fylles opp, statuskolonnen sier "Completed", elementtellinger stemmer. Fra CloudMs perspektiv var migreringen vellykket. Og teknisk sett var den det. Meldingene ble overfort. Datoene overlevde rett og slett ikke turen.

CloudM Managed vs. Self-Service: samme datoproblem

CloudM tilbyr to distribusjonsmodeller. SaaS-versjonen (CloudM Migrate hostet) kjorer helt i CloudMs infrastruktur. Den selvhostede versjonen lar deg distribuere primaere og sekundaere migreringsservere pa ditt eget nettverk, Google Cloud, Azure eller AWS.

Noen MSP-er antar at den selvhostede varianten gir mer kontroll over datohaldtering fordi du administrerer migreringsserverne direkte. Det gjor den ikke. Datoproblemet skjer pa destinasjonsserveren, ikke pa CloudMs behandlingsnoder. Enten migreringfarmen din kjorer i CloudMs sky eller pa din egen Azure-VM, stempler destinasjonens e-postserver fortsatt migreringsdatoen pa hver melding den mottar.

CloudM tilbyr ogsa en fullt administrert "Serviced Migration" der teamet deres handterer prosjektet fra start til slutt. Samme resultat for datoer. Teknikken er identisk, egentlig er det bare andre hender pa tastaturet. Har du noen gang betalt for en premiumtjeneste og likevel fatt den samme begrensningen som gratisnivaaet? Det er akkurat den folelsen.

Komplikasjonen med ugyldige Date-headere

Det er enna en CloudM-spesifikk oppforsel som gjor ting verre. Nar CloudM stater pa en kilde-e-post med en Date:-header som ikke folger RFC 822 (feilformatert tidssone, manglende ukedag, ikke-standardformat), endrer CloudM headeren slik at meldingen kan migreres.

Det betyr at noen e-poster til og med mister sin opprinnelige datoreferanse. Den endrede Date:-headeren matcher kanskje ikke den faktiske sendedatoen i det hele tatt. CloudMs supportdokumentasjon nevner denne oppforselen under "Possible Changes to Migrated Items", men spesifiserer ikke hva den endrede datoen blir.

For en postkasse med 12 000 meldinger samlet over atte ar, kan det vaere hundrevis av e-poster med litt ustandard Date-headere (saerlig meldinger fra eldre e-postservere, automatiserte systemer eller internasjonale avsendere med tidssoneformateringssaeregenheter). Etter CloudMs endring pluss destinasjonsserverens Received-header-omskriving ender disse meldingene med datoer som ikke har noen likhet med virkeligheten.

Hvorfor manuelle rettelser ikke skalerer etter CloudM

Kunne du fikset det selv? Teknisk sett er den opprinnelige Date:-headeren fortsatt innebygd i de fleste meldinger (bortsett fra dem CloudM endret for RFC-overholdelse). Noen administratorer har forsokt a skrive skript for a rette datoer etter en CloudM-migrering.

Her er realiteten med den tilnaermingen. Du maa koble deg til potensielt tusenvis av postkasser, hver med tusenvis av meldinger. For hver e-post ma du parse den fullstendige headerkjeden, identifisere hvilke Received:-headere CloudM eller destinasjonsserveren la til, handtere kanttilfellene (S/MIME-signerte meldinger der headerendring bryter signaturen, PGP-kryptert innhold, multipart MIME-strukturer med nestede grenser, RFC 2047-kodede ikke-ASCII-headere fra japanske eller koreanske avsendere), og gjore alt dette uten a miste et eneste vedlegg eller bryte e-posttradingen.

Et skript som fungerer pa 50 teste-poster fra en ren postkasse overlever ikke kontakten med et produksjonsmiljo med 40 000 meldinger over et tiar. Hva skjer nar du treffer en 47 MB e-post med seks nestede vedlegg? Hva med API-hastighetsgrensene (250 kvotaenheter per bruker per sekund hos Google, Microsofts begrensning pa rundt 10 000 foresporsler per 10 minutter)? Hva er tilbakerullingsplanen din nar noe gar galt pa melding nummer 8 347?

Og det egentlige sporsmalet som de fleste administratorer ikke stiller for det er for sent: hvordan verifiserer du at hver rettet melding faktisk er intakt?

Rett CloudM-migreringsdatoer med Redate.io

Redate.io kobler seg direkte til de berarte postkassene (Google Workspace, Microsoft 365 eller IMAP) og skanner etter e-poster som baerer CloudMs migreringsdatosignatur. Skanningen er gratis og tar et par minutter per postkasse, og viser det eksakte antallet berarte meldinger for noen forpliktelse.

Korreksjonen bruker en proprietaer headerkjedeanalysemotor som identifiserer CloudM-spesifikke migreringsmoanstre pa tvers av Received-headerkjeden. Redate.io utforer malrettet metadatakorrigerig uten a endre meldingsinnholdet, og bevarer vedlegg, trading, etiketter, mapper og digitale signaturer. Hver rettet melding gjennomgar individuell verifisering, der meldingsintegriteten kontrolleres mot originalen for prosessen gar videre.

Originale e-poster oppbevares i en synlig sikkerhetskopieringsmappe Redate.io - Originals i 30 dager. Hvis noe ma rulles tilbake, er originalene der i postkassen, ikke begravd i et eksternt arkiv.

For MSP-er som brukte CloudM pa kundemiljoer, handterer Redate.io korreksjoner pa tvers av flere postkasser i stor skala, med den samme verifiseringen per melding uansett om du retter 1 postkasse eller 500. Datoproblemet som CloudM etterlot behover ikke a bli et permanent trekk ved kundens e-postmiljo.

Plattformspesifikke veiledninger for CloudM-migreringer

Korrigeringsprosessen tilpasser seg destinasjonsplattformen. Redate.io handterer hver plattforms spesifikasjoner automatisk, men for detaljer om ditt oppsett:

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

For en dypere forklaring pa hvorfor dette skjer med alle migreringsverktoy (ikke bare CloudM), se hvorfor e-poster viser feil datoer etter migrering.

Migrert med CloudM og fast med feil datoer pa alle e-poster? Kjor en gratis skanning for a se noyaktig hvor mange meldinger som er beroart og hva det koster a rette dem.