iCloud til Office 365-migrering: feil e-postdatoer

En migreringsscenario som systematisk ødelegger datoer

Du har nettopp fullført overføringen av iCloud-postboksen til Office 365. E-postene er der, mappene er på plass, alt ser perfekt ut. Mandag morgen kommer den første klagen: "Alle de gamle e-postene mine viser dagens dato." Så en til. Så ti.

Dette er ikke en isolert feil. Migrering fra iCloud Mail til Office 365 er et av de mest dokumenterte scenariene for datokorrupsjon i e-post, av svært presise tekniske årsaker som har å gjøre med Apple Mails oppførsel, IMAP-protokollen og måten Microsoft 365 behandler innkommende meldinger på.

Hvorfor iCloud til Office 365 ødelegger datoene

For å forstå problemet må du skille mellom tre ting som mange (inkludert erfarne IT-administratorer) blander sammen: Date:-headeren, IMAP INTERNALDATE og filens opprettelsesdato.

Date:-headeren (RFC 2822)

Hver e-post inneholder en Date:-header som angir når meldingen ble sendt. Denne headeren er innebygd i selve meldingsteksten og endres aldri, i teorien. Det er den "originale" datoen i streng forstand.

IMAP INTERNALDATE

IMAP-protokollen (definert i RFC 3501) knytter en egen metadataverdi til hver melding, kalt INTERNALDATE. Det er denne verdien de fleste e-postklienter bruker for å sortere og vise meldinger i innboksen, ikke Date:-headeren. Outlook er særlig avhengig av INTERNALDATE for visning og sortering.

Problemet? Når et migreringsverktøy kopierer en e-post fra én IMAP-server til en annen, burde det ideelt sett bevare denne INTERNALDATE-verdien. I praksis skjer ikke alltid det.

Apple Mails særegne oppførsel

Apple Mail bruker av og til filens opprettelsesdato på serversiden som referanse for INTERNALDATE når den synkroniserer meldinger fra iCloud. Dette er ikke en feil i streng forstand, men en tolkning av IMAP-spesifikasjonen som avviker fra det andre klienter gjør. (Forresten, hvis du noen gang har prøvd å feilsøke et INTERNALDATE-problem ved å lese råe IMAP-RFC-er, vet du at spesifikasjonen gir ganske stort tolkningsrom på dette punktet.)

Resultatet: når du eksporterer eller migrerer fra iCloud via Apple Mail, kan INTERNALDATE-verdiene allerede være feil før de i det hele tatt ankommer Office 365.

De tre migreringsmetodene fra iCloud og fallgruvene deres

Direkte IMAP-migrering

Den vanligste metoden er å sette opp iCloud som IMAP-kilde og Office 365 som destinasjon, og deretter bruke et migreringsverktøy (imapsync, MigrationWiz eller et egenutviklet verktøy). Verktøyet kobler seg til begge servere og kopierer meldingene.

Problemet er todelt. For det første har Apples IMAP-servere hastighetsbegrensninger som tvinger verktøyene til å ta pauser, noe som skaper tidsrom der tilkoblinger lukkes og gjenopprettes. Det kan generere parasittiske INTERNALDATE-verdier. For det andre mottar hver melding som kopieres via IMAP APPEND til Exchange Online som standard en innsettingsdato som tilsvarer migreringstidspunktet, med mindre verktøyet eksplisitt sender med den opprinnelige INTERNALDATE-verdien i innsettingskommandoen.

Noen verktøy gjør dette riktig. Andre, ikke konsekvent. Og på en postboks med 40 000 meldinger betyr selv en feilrate på 2 % at 800 e-poster har feil dato.

For migreringer via imapsync, se også: rett imapsync-migreringsdatoer i Microsoft 365.

Eksport til .mbox eller .eml og deretter import

Noen brukere eksporterer iCloud-e-postene sine via Apple Mail i .mbox-format og prøver deretter å importere dem i Outlook. Dette er en håndverksmessig metode som gir variable resultater.

.mbox-formatet koder e-poster som en sekvens av tekstmeldinger. Datoene finnes i individuelle Date:-headere, men skillelinjen mellom meldinger ("From ") inneholder en dato som noen importverktøy kan tolke som opprettelsesdato. Outlook bruker av og til denne skilledatoen fremfor meldingenes egne Date:-headere når det importerer en .mbox konvertert til .pst.

Dra og slipp via Outlook

Dette er metoden som forårsaker mest skade. En bruker setter opp begge kontoene i Outlook (iCloud og Office 365), og drar deretter meldingene fra én mappe til en annen. Det virker enkelt. Det er en katastrofe for datoene.

Når Outlook flytter en melding ved hjelp av dra og slipp mellom to IMAP-kontoer, oppretter det i realiteten en ny .EML-fil, setter den inn i destinasjonskontoen og sletter originalen. Denne nye filen arver Windows-filens opprettelsesdato, altså det nøyaktige tidspunktet for dra-og-slipp-operasjonen. Den originale Date:-headeren er fortsatt til stede i meldingskroppen, men INTERNALDATE som er registrert på Exchange Online-serveren, tilsvarer tidspunktet for operasjonen. Outlook viser deretter denne migrerungsdatoen for alle flyttede meldinger.

For å være presis: denne oppførselen varierer mellom Outlook-versjoner. Siden høst 2023-oppdateringen av Outlook har oppførselen blitt litt bedre i noen scenarioer, men dra og slipp mellom kontoer er fortsatt en dokumentert kilde til datokorrupsjon.

Hva Office 365 og Outlook til slutt viser

Exchange Online lagrer e-poster med sin INTERNALDATE. Outlook Desktop leser denne INTERNALDATE-verdien for å vise datoen i "Mottatt"-kolonnen og for å sortere innboksen. Hvis INTERNALDATE ble overskrevet under migreringen, viser Outlook migrasjonsdatoen, punktum.

Outlook Web App (OWA) gjør det samme. Det finnes ingen "alternativ visning" som ville vist den originale datoen fra Date:-headeren. Det du ser i datokolonnen, er INTERNALDATE.

Den originale Date:-headeren er fortsatt der, intakt og lesbar hvis du viser rådata for en melding. Men ingen normal visning viser den. Det er der den sentrale frustrasjonen i dette problemet ligger: den korrekte informasjonen finnes, men er utilgjengelig uten teknisk korreksjon.

Det Microsoft-støtten ikke løser

Åpner du en sak hos Microsoft Support for dette problemet, får du sannsynligvis dette: en bekreftelse på at datoene som vises tilsvarer de lagrede INTERNALDATE-verdiene, et forslag om å sjekke sorteringsinnstillingene i Outlook, og muligens en viderehenvisning til migreringsverktøyet du brukte.

Det er ikke ond vilje. Microsoft har rett og slett ikke noe innebygd verktøy for å korrigere INTERNALDATE-verdiene retroaktivt for tusenvis av meldinger som allerede er inntatt i Exchange Online. Korreksjonen krever tilgang til individuelle meldinger, analyse av headerne og rekonstruksjon av datometadataene, noe som er utenfor omfanget av standard støtte.

iCloud-støtten på sin side mener at meldingene ble eksportert korrekt og at problemet er på destinasjonssiden. De to støtteapparatene skyver ansvaret over på hverandre, og brukeren sitter igjen med 12 000 e-poster datert til migrasjonsdagen.

Skalaproblemet

Å forstå hvorfor datoene er ødelagt er én ting. Å korrigere dem manuelt i en produksjonspostboks er noe helt annet.

Noen IT-administratorer forsøker å skripte korreksjonen. Grunnideen er ikke vanskelig å forstå, men utførelsen på reelle volumer byr på problemer som hjemmelagde skript ikke håndterer godt:

• S/MIME-signerte eller PGP-krypterte e-poster kan ikke endres uten å ugyldiggjøre den kryptografiske signaturen
• Meldinger med komplekse multipart/alternative-strukturer (HTML + ren tekst + nestede vedlegg) er skjøre å manipulere
• Headere kodet i ikke-ASCII (RFC 2047, særlig for japanske, arabiske eller kyrilliske tegn) kan bli ødelagt av verktøy som ikke håndterer disse kodingene riktig
• Microsoft Graph API-kvoter og Exchange Online-hastighetsbegrensninger (feil 429 Too Many Requests) stopper skript som ikke er designet for eksponentiell backoff-håndtering
• Et skript som kjører korrekt på 500 teste-poster, stopper klokken 3 om natten på den 8000. meldingen i en ekte postboks, uten gjenopptaksmekanisme

Og det avgjørende spørsmålet: hvordan verifiserer du at hver korrigert e-post er intakt etter korreksjonen? At vedlegget fortsatt er der? At diskusjonstråden ikke er brutt? Et hjemmelaget skript gjør vanligvis ikke denne verifiseringen.

Slik håndterer Redate.io iCloud-til-Office 365-migreringer

Redate.io kobler seg direkte til Office 365 via Microsoft 365-tillatelser (Azure AD), uten å trenge tilgang til iCloud-serverne. E-postene er allerede i Exchange Online når Redate griper inn.

Redates korreksjonsmotor analyserer header-kjeden i hver melding for å identifisere den originale datoen, og skiller mellom Received:-headere lagt til under migreringen og legitime datometadata. Denne analysen inkluderer mønstergjenkjenning mot signaturer fra kjente migreringsverktøy, noe som gjør det mulig å identifisere parasittiske headere selv når de ikke er umiddelbart åpenbare.

Hver korrigert e-post verifiseres individuelt etter behandling. Originalene bevares i en synlig sikkerhetskopieringsmappe i 30 dager, noe intet hjemmelaget skript gjør som standard. Det innledende skannet er gratis og gjør det mulig å tallfeste nøyaktig hvor mange e-poster som er berørt, før du bestemmer deg for å korrigere.

Redate støtter også migreringer fra Google Workspace til Office 365 og korreksjon etter cPanel-migrering. Se for eksempel: rett e-postdatoer etter Microsoft 365-migrering eller feil e-postdatoer etter migrering til Exchange Online.

Skann først, korriger etterpå

Det anbefalte utgangspunktet for enhver iCloud-til-Office 365-migrering som har produsert feil datoer: kjør Redate.ios gratis skann på de berørte postboksene. Skannet identifiserer nøyaktig hvor mange e-poster som har en mistenkelig INTERNALDATE-verdi og i hvilke mapper de befinner seg.

Det tar mellom 12 og 45 minutter avhengig av volumet, og gir et klart bilde av problemets omfang før noen inngrep. For MSP-er som håndterer flere postbokser etter en migrering, unngår dette batchskannet at man korrigerer postbokser som ikke trenger det.

Hvis e-postdatoene dine er feil etter en migrering fra iCloud, start med det gratis skannet på Redate.io for å måle problemets omfang i dine Office 365-postbokser.