CloudM Migrate: Ret forkerte e-maildatoer

CloudM Migrates datoproblem, som ingen advarer dig om

CloudM Migrate har afsluttet opgaven. Dashboardet viser 100 % færdigt, alle brugere migreret, nul fejl. Du lukker projektsagen og går videre til den næste kunde.

Så, en uge senere, ringer it-chefen. "Hvorfor viser hver eneste e-mail i min indbakke den 2. april?"

Ikke nogle e-mails. Alle. Fem års kundekorrespondance, juridiske dokumenter, HR-optegnelser, indkøbsordrer fra 2020, alt sammen med den dato, hvor CloudM kørte migreringen. Beskederne er der, indholdet er intakt, vedhæftningerne er fine. Men datoerne er forkerte på hver eneste én.

Det er ikke en CloudM-fejl. CloudMs egen supportdokumentation anerkender det åbent. Problemet ligger i krydsfeltet mellem, hvordan migreringsværktøjer overfører beskeder, og hvordan destinationsmailservere håndterer indgående e-mailmetadata. Men den viden hjælper ikke din kunde, hvis indbakke pludselig blev umulig at sortere.

Hvordan CloudM egentlig overfører e-mailbeskeder

CloudM Migrate forbinder til kilde- og destinationsplatforme via deres API'er. For Google Workspace betyder det en servicekonto med domænedækkende delegering (konfigureret i Google Admin Console under Sikkerhed > API-styring). For Microsoft 365 bruger CloudM enten Exchange Web Services eller Microsoft Graph API, afhængigt af migreringsstien.

Når CloudM læser en besked fra kilden, får den det fulde RFC 2822-indhold, inklusive alle originale headers og beskedteksten. Den originale Date:-header (den som afsenderens mailserver stemplede, da e-mailen først blev sendt) følger intakt med. Det samme gælder alle originale Received:-headers, der sporer beskedens leveringssti.

Problemet opstår, når kopien skrives. Destinationen bevarer den dato, den får: Microsoft 365 og Gmail bevarer den originale dato, når kopien bærer den med. Når det ikke er tilfældet, får kopien indsættelsestidspunktet som sin dato. Og i Google Workspace får hver besked, der skrives via Gmail API, også en ny Received:-header dateret til indsættelsestidspunktet.

Her er, hvad headerne på en af disse e-mails stadig bærer efter en CloudM-migrering til 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

Den originale Date:-header fra 2019 er stadig der, og det er den originale Received:-kæde også. Men i Microsoft 365 er den dato, Outlook viser som modtaget, postkassens egen registrering af, hvornår hver e-mail ankom: hvis CloudM ikke overførte den originale dato, siger den registrering 2. april 2026.

CloudMs indstilling "Strip Received Headers"

CloudM tilbyder faktisk en indstilling til at løse dette. I destinationsplatformens avancerede indstillinger under Message Options er der en kontakt kaldet "Strip Received Headers". Når den er aktiveret, fjerner CloudM Received-headerne, før beskeden indsættes, og erstatter dem med en enkelt header, der matcher e-mailens Date:-header.

Det lyder som om det løser alt, ikke? Ikke helt.

For det første skal du kende til indstillingen, før du kører migreringen. De fleste administratorer opdager datoproblemet, efter migreringen er afsluttet. På det tidspunkt sidder beskederne allerede i destinationen med forkerte datoer. At køre CloudM igen med indstillingen aktiveret opretter bare dubletter, det retter ikke det, der allerede er der.

For det andet har denne indstilling en hård begrænsning, når Google Workspace er destinationen. Googles egen dokumentation bekræfter det: Gmail omskriver altid Received:-headers på beskeder, der indsættes via API, og stempler dem med indsættelsestidsstemplet. Det er en begrænsning på platformniveau, som CloudM ikke kan omgå. Selv med "Strip Received Headers" aktiveret tilføjer Google Workspace sin egen Received:-header med migreringsdatoen.

For Microsoft 365-destinationer betyder indstillingen mindre: Microsoft 365 bevarer den dato, den får, så det, der afgør den viste dato, er, om CloudM overfører hver e-mails originale dato.

Hvilke CloudM-migreringer giver forkerte datoer (og hvilke gør ikke)

Ikke alle CloudM-migreringer giver forkerte datoer. Resultatet afhænger af kilde-destinationskombinationen og den specifikke API-sti, CloudM bruger:

• Google Workspace til Microsoft 365: Datoerne bliver forkerte. CloudM læser via Gmail API og skriver til Exchange, og hver e-mail får kopiens dato.
• Microsoft 365 til Google Workspace: Datoerne bliver forkerte. Selv med Strip Received Headers omskriver Googles API Received-headeren med indsættelsesdatoen. CloudMs supportdokumentation kalder det en "streng platformsbegrænsning".
• Google Workspace til Google Workspace: Datoerne bliver forkerte. Domæneskift, tenant-konsolideringer, opkøbsfusioner: hver besked, der skrives via Gmail API, får en Received:-header dateret til migreringen.
• On-premises Exchange til Microsoft 365: Det afhænger helt af den dato, CloudM overfører, uanset om kopien går via IMAP eller EWS.
• IMAP-kilde (generisk) til enhver destination: Samme regel: når CloudM forbinder til en generisk IMAP-server som kilde, viser kopien migreringsdatoen, når den originale dato ikke overføres til destinationen.

Den vanskelige del? CloudMs migreringsdashboard signalerer ingenting af dette. Fremskridtslinjen fyldes op, statuskolonnen siger "Completed", antallet af elementer stemmer. Fra CloudMs perspektiv var migreringen en succes. Og teknisk set var den det. Beskederne blev overført. Datoerne overlevede bare ikke turen.

CloudM Managed vs. Self-Service: samme datoproblem

CloudM tilbyder to deployeringsmodeller. SaaS-versionen (CloudM Migrate hosted) kører fuldstændigt i CloudMs infrastruktur. Den selvhostede version lader dig deploye primære og sekundære migreringsservere på dit eget netværk, Google Cloud, Azure eller AWS.

Nogle MSP'er går ud fra, at den selvhostede mulighed giver mere kontrol over datohåndteringen, fordi man selv administrerer migreringsserverne direkte. Det gør den ikke. Det, der afgør datoen, er, hvad migreringsmotoren overfører sammen med hver besked, og den motor er den samme, uanset hvor den køres. Uanset om din migreringsfarm kører i CloudMs cloud eller på din egen Azure-VM, er resultatet for datoerne det samme.

CloudM tilbyder også en fuldt styret "Serviced Migration", hvor deres team håndterer projektet fra ende til anden. Samme resultat for datoerne. Teknikken er identisk, det er bare andre hænder på tastaturet. Har du nogensinde betalt for en premiumtjeneste og alligevel fået samme begrænsning som gratisniveauet? Sådan føles det.

Komplikationen med ugyldige Date-headers

Der er en anden CloudM-specifik adfærd, der gør tingene værre. Når CloudM møder en kilde-e-mail med en Date:-header, der ikke følger RFC 822 (fejlformateret tidszone, manglende ugedag, ikke-standardformat), ændrer CloudM headeren for at sikre, at beskeden kan migreres.

Det betyder, at nogle e-mails endda mister deres oprindelige datoreference. Den ændrede Date:-header matcher måske slet ikke den reelle afsendelsesdato. CloudMs supportdokumentation nævner denne adfærd som et kendt fænomen under "Possible Changes to Migrated Items", men angiver ikke, hvad den ændrede dato bliver.

For en postkasse med 12.000 beskeder samlet over otte år kan der være hundredvis af e-mails med lidt ikke-standardiserede Date-headers (især beskeder fra ældre mailservere, automatiserede systemer eller internationale afsendere med særheder i tidszoneformatering). Efter CloudMs ændring, kombineret med en kopi, der ikke bærer den originale dato, ender disse beskeder med datoer, der ikke ligner virkeligheden.

Hvorfor manuelle rettelser ikke skalerer efter CloudM

Kunne du selv rette det? Teknisk set er den originale Date:-header stadig indlejret i de fleste beskeder (undtagen de, CloudM ændrede for at overholde RFC). Nogle administratorer har forsøgt 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 hele headerkæden, identificere hvilke Received:-headers CloudM eller destinationsserveren tilføjede, håndtere særtilfældene (S/MIME-signerede beskeder, hvor headerændringer bryder signaturen, PGP-krypteret indhold, multipart MIME-strukturer med indlejrede grænser, RFC 2047-kodede ikke-ASCII-headers fra japanske eller koreanske afsendere), og gøre alt dette uden at tabe en enkelt vedhæftning eller bryde e-mailtrådene.

Et script, der virker på 50 test-e-mails fra en ren postkasse, overlever ikke mødet med et produktionsmiljø på 40.000 beskeder fordelt over et årti. Hvad sker der, når du rammer en 47 MB e-mail med seks indlejrede vedhæftninger? Hvad med API-hastighedsgrænserne (Googles 250 kvoteenheder per bruger per sekund, Microsofts throttling ved omkring 10.000 anmodninger per 10 minutter)? Hvad er din rollbackplan, når noget går galt ved besked nummer 8.347?

Og det egentlige spørgsmål, de fleste administratorer først stiller, når 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 berørte postkasser (Google Workspace, Microsoft 365 eller IMAP) og gennemgår dem for e-mails, hvis viste dato ikke stemmer med deres oprindelige dato. Gennemgangen er gratis og tager et par minutter per postkasse og viser det nøjagtige antal berørte beskeder, før du forpligter dig til noget.

Rettelsen bruger en proprietær analysemotor til headerkæder, og den behøver ikke at vide, hvilket værktøj der stod for migreringen. Redate.io udfører målrettet metadatarettelse uden at ændre beskedens indhold og bevarer vedhæftninger, tråde, labels, mapper og digitale signaturer. Hver rettet besked gennemgår individuel verifikation, hvor beskedens integritet kontrolleres mod originalen, før processen går videre.

Originale e-mails opbevares i en synlig backupmappe kaldet Redate.io - Originals, indtil du selv sletter den. Hvis noget skal rulles tilbage, er originalerne lige der i postkassen, ikke gemt væk i et eksternt arkiv.

For MSP'er, der har brugt CloudM i kundemiljøer, håndterer Redate.io rettelser af flere postkasser i stor skala, med samme verifikation per besked, uanset om du retter 1 postkasse eller 500. Datoproblemet, som CloudM efterlod, behøver ikke at blive en permanent del af din kundes e-mailmiljø.

Platformspecifikke vejledninger til CloudM-migreringer

Rettelsesprocessen tilpasser sig destinationsplatformen. Redate.io håndterer automatisk hver platforms særlige forhold, men for detaljer om din opsætning:

• 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 på, hvorfor dette sker med alle migreringsværktøjer, ikke kun CloudM, se hvorfor e-mails viser forkerte datoer efter migrering.

Migreret med CloudM og fastlåst med forkerte datoer på alle e-mails? Kør en gratis gennemgang for at se præcis, hvor mange beskeder der er berørt, og hvad det koster at rette dem.