iCloud til Office 365-migrering: forkerte e-maildatoer

Et migreringsscenarie der systematisk ødelægger datoer

Du er lige færdig med at flytte din iCloud-mailboks til Office 365. E-mails er der, mapper er på plads, alt ser perfekt ud. Mandag morgen kommer den første klage: "Alle mine gamle e-mails viser dags dato." Så en til. Så ti.

Det er ikke en isoleret fejl. Migrering fra iCloud Mail til Office 365 er et af de mest dokumenterede scenarier for ødelagte e-maildatoer, af meget præcise tekniske årsager der hænger sammen med Apple Mails adfærd, IMAP-protokollen og den måde Microsoft 365 behandler indgående beskeder på.

Hvorfor iCloud til Office 365 ødelægger datoer

For at forstå problemet skal man skelne mellem tre ting som mange (også erfarne IT-admins) blander sammen: Date:-headeren, IMAP INTERNALDATE og filens oprettelsesdato.

Date:-headeren (RFC 2822)

Hver e-mail indeholder en Date:-header der angiver hvornår beskeden blev sendt. Denne header er indlejret i beskedens rå indhold og ændres aldrig, i teorien. Det er den "originale" dato i ordets egentlige forstand.

IMAP INTERNALDATE

IMAP-protokollen (defineret i RFC 3501) knytter en separat metadata-værdi til hver besked: INTERNALDATE. Det er denne værdi de fleste e-mailklienter bruger til at sortere og vise beskeder i indbakken, ikke Date:-headeren. Outlook i særdeleshed læner sig meget tungt op ad INTERNALDATE til visning og sortering.

Problemet? Når et migreringsværktøj kopierer en e-mail fra en IMAP-server til en anden, burde det ideelt set bevare denne INTERNALDATE. I praksis er det ikke altid det der sker.

Apple Mails særlige adfærd

Apple Mail bruger indimellem filens oprettelsesdato på serversiden som reference for INTERNALDATE når det synkroniserer beskeder fra iCloud. Det er ikke en fejl i streng forstand, det er en fortolkning af IMAP-specifikationen der afviger fra hvad andre klienter gør. (Og hvis du nogensinde har prøvet at debugge et INTERNALDATE-problem ved at læse rå IMAP-RFC'er, ved du at specifikationen efterlader ret bred fortolkningsmargen på det punkt.)

Resultatet: når du eksporterer eller migrerer fra iCloud via Apple Mail, kan INTERNALDATE på beskederne allerede være forkert før de overhovedet lander i Office 365.

De tre migreringsmetoder fra iCloud og deres faldgruber

Direkte IMAP-migrering

Den mest udbredte metode er at konfigurere iCloud som IMAP-kilde og Office 365 som destination, og derefter bruge et migreringsværktøj (imapsync, MigrationWiz eller et hjemmebygget værktøj). Værktøjet forbinder sig til begge servere og kopierer beskederne.

Problemet her er dobbelt. Apples IMAP-servere har hastighedsbegrænsninger der tvinger værktøjer til at holde pauser, hvilket skaber tidsvindue hvor forbindelser lukkes og genåbnes, og det kan generere parasitiske INTERNALDATE-værdier. Desuden får hver besked der kopieres via IMAP APPEND til Exchange Online som standard en indsættelsdato svarende til migreringstidspunktet, medmindre værktøjet eksplicit sender den originale INTERNALDATE med i indsættelseskommandoen.

Nogle værktøjer gør det korrekt. Andre ikke konsekvent. Og på en mailboks med 40.000 beskeder betyder selv en fejlrate på 2 % 800 e-mails med den forkerte dato.

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

Eksport som .mbox eller .eml og derefter import

Nogle brugere eksporterer deres iCloud-e-mails via Apple Mail i .mbox-format og forsøger derefter at importere dem i Outlook. Det er en håndværksmæssig metode der giver varierende resultater.

.mbox-formatet koder e-mails som en sekvens af tekstbeskeder. Datoer er til stede i de individuelle Date:-headere, men separationslinjen mellem beskeder ("From ") indeholder en dato som nogle importører kan fortolke som oprettelsesdato. Outlook bruger indimellem denne separationsdato frem for beskedens egen Date:-header når den importerer et .mbox konverteret til .pst.

Træk-og-slip via Outlook

Her er metoden der skaber mest skade. En bruger konfigurerer begge konti i Outlook (iCloud og Office 365) og trækker derefter sine beskeder fra en mappe til en anden. Det lyder enkelt. Det er en katastrofe for datoerne.

Når Outlook flytter en besked via træk-og-slip mellem to IMAP-konti, genererer det reelt en ny .EML-fil, indsætter den i destinationskontoen og sletter originalen. Denne nye fil arver Windows-filens oprettelsesdato, altså det præcise tidspunkt for træk-og-slip. Den originale Date:-header er stadig til stede i beskedens indhold, men INTERNALDATE registreret på Exchange Online-serveren svarer til manipulationstidspunktet. Outlook viser derefter denne migrationsdato for alle de flytte beskeder.

For at være præcis varierer denne adfærd afhængigt af Outlook-versionen. Siden Outlook-opdateringen i efteråret 2023 er adfærden forbedret lidt for visse scenarier, men træk-og-slip mellem konti er stadig en dokumenteret kilde til datokorruption.

Hvad Office 365 og Outlook til sidst viser

Exchange Online gemmer e-mails med deres INTERNALDATE. Outlook Desktop læser denne INTERNALDATE for at vise datoen i kolonnen "Modtaget" og til sortering af indbakken. Hvis INTERNALDATE blev overskrevet under migreringen, viser Outlook migrationsdatoen, punktum.

Outlook Web App (OWA) gør det samme. Der er ingen "alternativ visning" der ville vise den originale dato fra Date:-headeren. Det du ser i datokolonnen, er INTERNALDATE.

Den originale Date:-header er stadig der, intakt, læsbar hvis du viser en beskeds rå headers. Men ingen normal visning viser den. Det er den centrale frustration ved dette problem: den rigtige information eksisterer, den er bare utilgængelig uden teknisk korrektion.

Hvad Microsoft-support ikke løser

Hvis du åbner en sag hos Microsoft Support om dette problem, er her hvad du sandsynligvis får: en bekræftelse af at de viste datoer svarer til de gemte INTERNALDATE-værdier, et forslag om at kontrollere sorteringsindstillingerne i Outlook og muligvis en henvisning til det migreringsværktøj du brugte.

Det er ikke dårlig vilje. Microsoft har simpelthen ikke et indbygget værktøj til retroaktivt at rette INTERNALDATE på tusindvis af beskeder der allerede er indsat i Exchange Online. Korrektionen kræver individuel adgang til beskederne, analyse af deres headers og rekonstruktion af datometadata, hvilket ligger uden for standardsupportens rammende.

iCloud-support mener på sin side at beskederne blev eksporteret korrekt og at problemet er på destinationssiden. De to supportafdelinger sender bolden til hinanden, og brugeren sidder tilbage med 12.000 e-mails dateret til migrationsdagen.

Skalaproblemet

At forstå hvorfor datoerne er ødelagte er én ting. At rette dem manuelt på en produktionsmailboks er noget helt andet.

Nogle IT-admins forsøger at scripte rettelsen. Grundidéen er ikke svær at begribe, men udførelsen på reelle volumener skaber problemer som hjemmelavede scripts ikke håndterer godt:

• S/MIME-signerede eller PGP-krypterede e-mails kan ikke ændres uden at den kryptografiske signatur ugyldiggøres
• Beskeder med komplekse multipart/alternative strukturer (HTML + ren tekst + indlejrede vedhæftede filer) er skrøbelige at manipulere
• Non-ASCII-kodede headers (RFC 2047, især for japanske, arabiske eller kyrilliske tegn) kan blive ødelagt af værktøjer der ikke håndterer disse kodninger korrekt
• Microsoft Graph API-kvoter og Exchange Online-hastighedsbegrænsninger (fejl 429 Too Many Requests) stopper scripts der ikke er bygget til eksponentiel backoff-håndtering
• Et script der kører korrekt på 500 test-e-mails stopper klokken 3 om natten på den 8.000. besked i en reel mailboks, uden genoptagelsesmekanisme

Og det afgørende spørgsmål: hvordan verificerer du at hver rettet e-mail er intakt efter korrektionen? At vedhæftningen stadig er der? At tråden ikke er brudt? Et hjemmelavet script foretager typisk ikke denne verifikation.

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

Redate.io forbinder sig direkte til Office 365 via Microsoft 365-tilladelser (Azure AD), uden at kræve adgang til iCloud-servere. E-mails er allerede i Exchange Online når Redate behandler dem.

Redates korrektionsmotor analyserer header-kæden i hver besked for at identificere den originale dato, ved at skelne de Received:-headere der blev tilføjet under migreringen fra legitime datometadata. Denne analyse inkluderer mønstermatchning på signaturer fra kendte migreringsværktøjer, hvilket gør det muligt at identificere parasitiske headers selv når de ikke er umiddelbart tydelige.

Hver rettet e-mail verificeres individuelt efter behandling. Originalerne gemmes i en synlig backup-mappe i 30 dage, hvilket intet hjemmelavet script gør som standard. Det indledende scan er gratis og giver mulighed for præcist at opgøre antallet af berørte e-mails før du beslutter om de skal rettes.

Redate understøtter også migreringer fra Google Workspace til Office 365 og rettelser efter cPanel-migrering. Se fx: ret e-maildatoer efter migrering til Microsoft 365 eller forkerte e-maildatoer efter migration til Exchange Online.

Scan først, ret bagefter

Det anbefalede udgangspunkt for enhver iCloud til Office 365-migrering der har produceret forkerte datoer: kør Redate.ios gratis scan på de berørte mailbokse. Scannet identificerer præcist hvor mange e-mails der har en mistænkelig INTERNALDATE og i hvilke mapper de befinder sig.

Det tager mellem 12 og 45 minutter afhængigt af volumen, og det giver et klart billede af problemets omfang før enhver intervention. For MSPs der administrerer flere mailbokse på én gang efter en migrering, undgår dette batch-scan at rette mailbokse der ikke har brug for det.

Hvis dine e-maildatoer er forkerte efter en migrering fra iCloud, start med det gratis scan på Redate.io for at måle problemets omfang på dine Office 365-mailbokse.