CloudM Migrate: Rett feil e-postdatoer

CloudM Migrate-datoproblemet ingen advarer deg om

CloudM Migrate fullførte jobben. Dashbordet viser 100 % fullført, alle brukere migrert, null feil. Du lukker prosjektsaken og går videre til neste kunde.

En uke senere ringer IT-direktøren. "Hvorfor viser hver e-post i innboksen min 2. april?"

Ikke noen e-poster. Alle. Fem år med kundekorrespondanse, juridiske dokumenter, HR-poster, kjøpsordre fra 2020, alt viser datoen CloudM kjørte migreringen på. Meldingene er der, innholdet er intakt, vedleggene er fine. Men datoene er feil på hver eneste en.

Dette er ikke en feil i CloudM. CloudMs egen supportdokumentasjon erkjenner det åpent. Problemet ligger i skjæringspunktet mellom hvordan migreringsverktøy overfører meldinger og hvordan mottakende e-postservere håndterer innkommende e-postmetadata. Men det hjelper ikke kunden din, som nettopp fikk en innboks som er umulig å sortere.

Hvordan CloudM faktisk overfører e-postmeldinger

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

Når CloudM leser en melding fra kilden, får den hele RFC 2822-innholdet, inkludert alle opprinnelige headere og meldingsteksten. Den opprinnelige Date:-headeren (den avsenderens e-postserver stemplet da e-posten først ble sendt) følger med intakt. Det samme gjør alle opprinnelige Received:-headere som viser meldingens leveringsvei.

Problemet oppstår når kopien skrives. Målplattformen holder på datoen den får: Microsoft 365 og Gmail holder på den opprinnelige datoen når kopien bærer den. Når den ikke gjør det, får kopien tidspunktet for innsetting som sin dato. Og i Google Workspace får hver melding som skrives via Gmail API, også en fersk Received:-header datert til tidspunktet for innsetting.

Slik ser headerne til en av disse e-postene fortsatt ut etter 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 opprinnelige Date:-headeren fra 2019 er fortsatt der, og det samme er den opprinnelige Received:-kjeden. Men i Microsoft 365 er datoen Outlook viser som mottatt, postboksens egen oppføring av når hver e-post kom inn: hvis CloudM ikke overførte den opprinnelige datoen, sier den oppføringen 2. april 2026.

CloudMs "Strip Received Headers"-innstilling

CloudM tilbyr faktisk en innstilling for å håndtere dette. I målplattformens avanserte innstillinger, under Message Options, finnes en "Strip Received Headers"-bryter. Når den er aktivert, fjerner CloudM de mottatte headerne før meldingen settes inn, og erstatter dem med en enkelt header som samsvarer med e-postens Date:-header.

Høres ut som det løser alt, ikke sant? Ikke helt.

Først må du vite om den før du kjører migreringen. De fleste administratorer oppdager datoproblemet etter at migreringen er fullført. På det tidspunktet ligger meldingene allerede i målplattformen med feil datoer. Å kjøre CloudM på nytt med innstillingen aktivert skaper bare duplikater, det retter ikke det som allerede er der.

For det andre har denne innstillingen en klar begrensning når Google Workspace er målet. Googles egen dokumentasjon bekrefter det: Gmail skriver alltid om Received:-headere på meldinger satt inn via API, og stempler dem med tidspunktet for innsetting. Dette er en begrensning på plattformnivå som CloudM ikke kan overstyre. Selv med "Strip Received Headers" aktivert legger Google Workspace til sin egen Received:-header med migreringsdatoen.

For Microsoft 365 som mål betyr innstillingen mindre: Microsoft 365 holder på datoen den får, så det som avgjør den viste datoen er om CloudM overfører hver e-posts opprinnelige dato.

Hvilke CloudM-migreringer ødelegger datoer (og hvilke gjør det ikke)

Ikke alle CloudM-migreringer gir feil datoer. Resultatet avhenger av kilde-mål-kombinasjonen og den spesifikke API-veien CloudM bruker:

• Google Workspace til Microsoft 365: Datoene ødelegges. CloudM leser via Gmail API og skriver til Exchange, og hver e-post får datoen for kopieringen.
• Microsoft 365 til Google Workspace: Datoene ødelegges. Selv med Strip Received Headers skriver Googles API om Received-headeren med innsettingsdatoen. CloudMs supportdokumentasjon kaller dette en "streng plattformbegrensning".
• Google Workspace til Google Workspace: Datoene ødelegges. Domenebytter, tenant-konsolideringer, oppkjøpssammenslåinger: hver melding som skrives via Gmail API, får en Received:-header datert til migreringen.
• Lokal Exchange til Microsoft 365: Det avhenger helt av datoen CloudM overfører, uansett om kopien går via IMAP eller EWS.
• IMAP-kilde (generisk) til et hvilket som helst mål: Samme regel: når CloudM kobler seg til en generisk IMAP-server som kilde, viser kopien migreringsdatoen når den opprinnelige datoen ikke overføres til målet.

Det vanskelige er at CloudMs migreringsdashbord ikke markerer noe av dette. Fremdriftslinjen fylles opp, statuskolonnen sier "Completed", antall elementer stemmer. Fra CloudMs perspektiv var migreringen vellykket. Og teknisk sett var den det. Meldingene ble overført. Datoene overlevde bare ikke reisen.

CloudM administrert vs. selvbetjent: samme datoproblem

CloudM tilbyr to distribusjonsmodeller. SaaS-versjonen (CloudM Migrate hostet) kjører helt i CloudMs infrastruktur. Den selvhostede versjonen lar deg distribuere primære og sekundære migreringsservere på ditt eget nettverk, Google Cloud, Azure eller AWS.

Noen MSP-er antar at det selvhostede alternativet gir mer kontroll over datohåndteringen siden du administrerer migreringsserverne direkte. Det gjør det ikke. Det som avgjør datoen, er hva migreringsmotoren overfører sammen med hver melding, og den motoren er den samme uansett hvor den kjører. Enten migreringsfarmen din kjører i CloudMs sky eller på din egen Azure-VM, er resultatet for datoene det samme.

CloudM tilbyr også en fullt administrert "Serviced Migration" der teamet deres håndterer prosjektet fra start til slutt. Samme resultat for datoene. Teknikken er identisk, det er bare hendene på tastaturet som er forskjellige. Har du noen gang betalt for en premiumtjeneste og likevel fått samme begrensning som gratisnivået? Det er akkurat den følelsen dette gir.

Komplikasjonen med ugyldige Date-headere

Det finnes enda en CloudM-spesifikk oppførsel som gjør ting verre. Når CloudM møter en kilde-e-post med en Date:-header som ikke følger RFC 822 (feilformatert tidssone, manglende ukedag, ikke-standard format), endrer den headeren for å sikre at meldingen kan migreres.

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

For en postboks med 12 000 meldinger samlet over åtte år kan du ha hundrevis av e-poster med litt ikke-standard Date-headere (særlig meldinger fra eldre e-postservere, automatiserte systemer eller internasjonale avsendere med tidssoneformateringsfeil). Etter CloudMs endring, pluss en kopi som ikke bærer den opprinnelige datoen, ender disse meldingene med datoer som ikke har noen likhet med virkeligheten.

Hvorfor manuell retting ikke skalerer etter CloudM

Kunne du rettet dette selv? Teknisk sett er den opprinnelige Date:-headeren fortsatt innebygd i de fleste meldinger (unntatt de CloudM endret for RFC-samsvar). Noen administratorer har forsøkt å skrive skript for å rette datoer etter en CloudM-migrering.

Her er realiteten i den tilnærmingen. Du ser på å koble til potensielt tusenvis av postbokser, hver med tusenvis av meldinger. For hver e-post må du analysere hele headerkjeden, identifisere hvilke Received:-headere CloudM eller målserveren la til, håndtere spesialtilfellene (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 gjøre alt dette uten å miste et eneste vedlegg eller bryte e-posttrådingen.

Et skript som fungerer på 50 testmeldinger fra en ren postboks, overlever ikke møtet med et produksjonsmiljø på 40 000 meldinger fordelt over et tiår. Hva skjer når du treffer en e-post på 47 MB med seks nestede vedlegg? Hva med API-hastighetsgrensene (Googles 250 kvoteenheter per bruker per sekund, Microsofts begrensning på rundt 10 000 forespørsler per 10 minutter)? Hva er tilbakerullingsplanen din når noe går galt på melding nummer 8 347?

Og det egentlige spørsmålet de fleste administratorer ikke stiller før det er for sent: hvordan bekrefter du at hver rettet melding faktisk er intakt?

Rett CloudM-migreringsdatoer med Redate.io

Redate.io kobler seg direkte til de berørte postboksene (Google Workspace, Microsoft 365 eller IMAP) og skanner etter e-poster hvor den viste datoen ikke stemmer med den opprinnelige datoen. Skanningen er gratis og tar et par minutter per postboks, og viser det eksakte antallet berørte meldinger før noen forpliktelse.

Rettingen bruker en egenutviklet motor for analyse av headerkjeder, og den behøver ikke å vite hvilket verktøy som utførte migreringen. Redate.io utfører målrettet metadataretting uten å endre meldingsinnholdet, og bevarer vedlegg, tråding, etiketter, mapper og digitale signaturer. Hver rettet melding går gjennom individuell verifisering, der meldingens integritet kontrolleres mot originalen før prosessen går videre.

Opprinnelige e-poster oppbevares i en synlig sikkerhetskopimappe, Redate.io - Originals, til du selv sletter den. Hvis noe må rulles tilbake, ligger originalene rett der i postboksen, ikke gjemt i et eksternt arkiv.

For MSP-er som brukte CloudM på kundemiljøer, håndterer Redate.io retting av flere postbokser i stor skala, med samme verifisering per melding uansett om du retter 1 postboks eller 500. Datoproblemet CloudM etterlot seg behøver ikke bli en permanent del av kundens e-postmiljø.

Plattformspesifikke veiledninger for CloudM-migreringer

Rettingsprosessen tilpasser seg målplattformen. Redate.io håndterer hver plattforms særegenheter 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 på hvorfor dette skjer med alle migreringsverktøy, ikke bare CloudM, se hvorfor e-poster viser feil datoer etter migrering.

Migrert med CloudM og sitter fast med feil datoer på hver e-post? Kjør en gratis skanning for å se nøyaktig hvor mange meldinger som er berørt, og hva det koster å rette dem.