Delt webhosting til M365: det skjulte datoproblem

Det problem, ingen fortalte dig om

Du har netop afsluttet migreringen af din mailopsætning fra OVH, Infomaniak, Ionos eller o2switch til Microsoft 365. Migreringsguiden i EAC (Exchange Admin Center) kørte natten igennem, alt lyser grønt, postkasserne er fyldt. Mandag morgen kommer den første ticket: "Alle mine gamle e-mails har fået dags dato." Så endnu en. Så ti.

Det er ikke en fejl i Microsoft 365. Det er heller ikke tilfældigt. Det er det mekaniske resultat af en IMAP-migrering, og når man migrerer fra delt webhosting, er problemet ofte to gange så slemt som ved en normal migrering. Her er hvorfor.

Sådan håndterer IMAP datoer (og hvor det går galt)

Hver e-mail, der er lagret på en IMAP-server, har to forskellige typer datostempling. På den ene side er der Date:-headeren (defineret af RFC 2822), som sidder inde i selve meddelelsen og angiver, hvornår beskeden blev sendt eller modtaget. På den anden side er der INTERNALDATE, en serverbaseret metadata der angiver, hvornår beskeden blev placeret i postkassen. Det er denne værdi, som e-mailklienter som Outlook som standard bruger til at sortere og vise e-mails.

(Har du nogensinde prøvet at læse de rå headers på en e-mail i EAC, ved du, at det ikke ligefrem er strandlæsning. Der er nemt tyve til tredive headerlinjer, inden du overhovedet kommer til indholdet.)

Når et IMAP-migreringsværktøj overfører en besked fra én postkasse til en anden, skal det genskabe INTERNALDATE på destinationen. Nogle værktøjer gør det korrekt. Mange gør det ikke, eller gør det med begrænsninger. Og de modtagende servere har også noget at skulle have sagt: Exchange Online beholder den dato, den får: hvis en kopi bærer sin oprindelige dato, beholder Exchange Online den dato. Så når datoerne bliver forkerte, er det værktøjet, der skal undersøges, ikke Microsoft 365.

Resultatet: hver migreret e-mail ser ud til at være "modtaget" på migreringstidspunktet. Ligegyldigt om den er fra 2019.

Scenariet i to trin: derfor forværrer delt webhosting alt

Her bliver situationen virkelig problematisk for migreringer fra delte webhostingudbydere som OVH, Infomaniak, Gandi, Ionos eller o2switch.

Disse udbydere bruger typisk delte Postfix-, Dovecot- eller cPanel-servere med standard IMAP-konfigurationer. Mange mindre virksomheder har opbygget årevis af e-mails der, nogle gange helt tilbage fra 2010 eller 2012. Når de beslutter sig for at skifte til Microsoft 365, foregår migreringen ofte i to omgange.

Trin 1: den første korruption (endnu inden Microsoft 365)

I mange tilfælde har e-mailene allerede gennemgået én migrering. Virksomheden har skiftet delt webhostingudbyder en eller to gange gennem årene: fra Gandi til OVH i 2018, og fra OVH til Infomaniak i 2022 for eksempel. Hver IMAP-overførsel kan have nulstillet den originale INTERNALDATE til overførselsdatoen, hvis værktøjet ikke overførte den oprindelige dato, og nogle værktøjer efterlader også deres egne migreringsheadere med dato fra netop den dag.

Når e-mailene ankommer til Microsoft 365, bærer de altså allerede ar. Den originale Date:-header er intakt (den er en del af selve meddelelsens indhold, ingen rører ved den), men datometadataene er allerede blevet forstyrret én gang.

Trin 2: den anden korruption ved overgangen til Exchange Online

EAC's IMAP-migreringsværktøj, eller et tredjepartsværktøj som BitTitan MigrationWiz konfigureret i IMAP-tilstand, indlæser nu disse allerede beskadigede e-mails. Hvis værktøjet heller ikke overfører hver e-mails oprindelige dato, journalfører Exchange Online e-mailen under overførselsdagen, og det er den "modtagelsesdato", Outlook viser.

En e-mail sendt i marts 2017 kan altså bære to lag af forkerte datoer: migreringsheadere efterladt af flytningen i 2022, og en modtagelsesdato fra migreringen til Microsoft 365 i 2024. Outlook viser 2024. Brugeren ser 2024. Det er forkert på to niveauer.

En præcisering her: det er ikke altid den nyeste Received:-header, der bruges direkte. Outlook bestemmer visningsdatoen ud fra en kombination af INTERNALDATE i Exchange Online-postkassen og de tilstedeværende headere. Men når migreringsværktøjet ikke overfører de oprindelige datoer, tilføjer flytningen til Exchange Online et nyt fejllag oven på det gamle.

Migreringsværktøjer og udbydere: de risikable kombinationer

Nogle kombinationer dukker meget hyppigt op ved migreringer fra delt webhosting:

• OVH / Infomaniak / Ionos + EAC's IMAP-værktøj: Microsofts native værktøj er praktisk, men berygtet for ikke at bevare datoerne korrekt ved voluminøse IMAP-migreringer.
• cPanel (o2switch, LWS osv.) + BitTitan MigrationWiz i IMAP-tilstand: MigrationWiz i IMAP-tilstand tilføjer sine egne migreringsheadere. Resultatet er dokumenteret, blandt andet på siden Ret BitTitan-migreringsdatoer i Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync er et kraftfuldt værktøj, men håndteringen af INTERNALDATE afhænger af konfigurationen. Uden de rette indstillinger bevares datoerne ikke. Se også imapsync: datoer ikke bevaret.
• Enhver manuel migrering via træk-og-slip i Outlook: hvis nogen har kopieret hele mapper ved at trække og slippe mellem to konti konfigureret i Outlook, bliver INTERNALDATE for hver e-mail overskrevet med kopieringsdatoen. Uden undtagelse.

Den røde tråd: alle disse metoder ender med Exchange Online-postkasser, hvor den viste dato i Outlook ikke længere svarer til noget reelt.

Hvorfor det er en dårlig idé at "ordne det selv" i stor skala

At forstå problemet er én ting. At rette 8000 e-mails fordelt på 40 Exchange Online-postkasser, på konti med komplekse mappestrukturer, S/MIME-signerede e-mails, store vedhæftede filer og indlejrede tråde, er noget helt andet.

Et PowerShell-script, der ser ud til at fungere på ti test-e-mails, kan stille og roligt fejle på besked nummer 4237 på grund af en korrupt MIME-grænse eller en RFC 2047-kodet header (det der format =?UTF-8?B?...?= for ikke-ASCII-tegn i afsendernavne). Uden en mekanisme til individuel verifikation opdager du det ikke. Du har bare én tabt e-mail.

De konkrete risici ved DIY på denne type migrering:

• Dobbelte beskeder, hvis indsætningslogikken fejler halvvejs
• Manglende vedhæftede filer, hvis multipart-strukturen rekonstrueres forkert
• Ødelagte e-mailtråde i Outlook (samtaler er baseret på References:- og In-Reply-To:-headere, der kan blive ændret)
• 429-fejl (Too Many Requests) fra Microsoft Graph API klokken 3 om natten, der afbryder behandlingen uden rollback
• Ingen nem måde at verificere, at alle 8000 rettelser er blevet anvendt korrekt

Og i det specifikke tilfælde med migreringer fra delt webhosting er der en ekstra vanskelighed: e-mailene bærer flere lag af parasitiske Received:-headere, ikke kun ét. Et simpelt script, der fjerner "den sidste Received:-header", er ikke nok. Man skal analysere hele kæden for at identificere, hvilken header der svarer til hvilken migrering, og hvilken der reelt repræsenterer den originale modtagelsesdato.

Hvad Redate.io gør anderledes

Hver bruger logger ind med sin egen Microsoft-konto, og Redate.io åbner netop den postkasse med den adgang, dette login giver. Det indledende scan er gratis: Redate.io identificerer alle e-mails, hvor den viste dato ikke svarer til den reelle dato, og giver et præcist estimat per postkasse.

Rettelsen bygger på en proprietær korrektionsmotor, der analyserer den komplette headerkæde i hver besked, uanset hvilket migreringsværktøj der er brugt, og rekonstruerer datometadataene korrekt, selv når flere korruptionslag overlapper hinanden. Hver rettet e-mail verificeres individuelt. Originalerne opbevares i en synlig backup-mappe i din egen postkasse, indtil du selv fjerner dem.

For migreringer fra delt webhosting håndterer Redate.io's flertrinede analysepipeline eksplicit scenarierne med dobbelt korruption: den nøjes ikke med at se på den nyeste Received:-header, men går hele historikken igennem for at finde den reelle originale modtagelsesdato. Se også, hvordan man generelt retter e-maildatoer efter migrering til Microsoft 365, og den specifikke guide om ødelagte IMAP INTERNALDATE-værdier for at forstå den underliggende mekanik.

Før eller efter migrering: to tidspunkter at handle på

To situationer, to tilgange.

Du har endnu ikke migreret. Den gode nyhed: det er muligt at begrænse skaden. Nogle migreringsværktøjer (MigrationWiz i Exchange-tilstand, CloudM med de rette indstillinger) bevarer datoerne bedre end andre. Men selv i det bedste tilfælde vil en migrering fra delt webhosting uden en ren historik sandsynligvis efterlade spor. Planlæg et gennemløb med Redate.io efter migreringen, inden postkasserne udleveres til brugerne.

Du har allerede migreret og tickets begynder at indgå. Redate.io retter eksisterende postkasser i Microsoft 365, uanset hvor gammel migreringen er. Scannet giver dig et præcist billede af den reelle tilstand i hver postkasse, inden der gøres noget. Se også tjeklisten til e-mailmigrering for at undgå de samme problemer fremover.

Migrerede du fra OVH, Infomaniak, Ionos eller o2switch til Microsoft 365 og datoerne er forkerte? Opret en Redate.io-konto og scan dine postkasser gratis for at se præcis omfanget af skaden, inden du beslutter noget som helst.