Delt hosting til Microsoft 365: datoene er ødelagt

Problemet ingen advarte deg om

Du har nettopp fullført migreringen av e-posten din fra OVH, Infomaniak, Ionos eller o2switch til Microsoft 365. Migrerings-assistenten i EAC (Exchange Admin Center) kjørte hele natten, alt er grønt, postboksene er fulle. Mandag morgen, første ticket: "Alle de gamle e-postene mine har fått dagens dato." Så en til. Så ti.

Dette er ikke en feil i Microsoft 365. Det er heller ikke tilfeldig. Det er det mekaniske resultatet av en IMAP-migrering, og ved migrering fra en delt hostingleverandør er problemet ofte dobbelt så alvorlig som ved en vanlig migrering. Her er grunnen.

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

Hver e-post lagret på en IMAP-server har to forskjellige typer datoer. På den ene siden er Date:-headeren (definert av RFC 2822), som befinner seg i selve meldingskroppen og angir når meldingen ble sendt eller mottatt. På den andre siden er INTERNALDATE, en serverside-metadata som forteller når denne meldingen ble lagt inn i postboksen. Det er denne verdien e-postklienter som Outlook bruker som standard for sortering og visning.

(Forresten, hvis du noen gang har prøvd å lese rå e-postheadere i EAC, vet du at det ikke akkurat er strandlektyre. Det er gjerne tjue til tretti linjer med headere før du kommer til selve innholdet.)

Når et IMAP-migrerings-verktøy overfører en melding fra én postboks til en annen, må det gjenskape denne INTERNALDATE på destinasjonsserveren. Noen verktøy gjør dette riktig. Mange gjør det ikke, eller gjør det med begrensninger. Mottakerserveren, for sin del, beholder det den får: når en kopi bærer sin opprinnelige dato, beholder Exchange Online denne datoen. Så når datoene blir feil, er det verktøyet man skal se på, ikke Microsoft 365.

Resultatet: hver migrert e-post ser ut til å ha blitt "mottatt" den dagen migreringen skjedde. Uansett om den er fra 2019.

To-stegs-scenariet: hvorfor delte hostingleverandører gjør alt verre

Her blir situasjonen virkelig problematisk for migreringer fra delte hostingleverandører som OVH, Infomaniak, Gandi, Ionos eller o2switch.

Disse leverandørene bruker vanligvis delte Postfix-, Dovecot- eller cPanel-servere med standard IMAP-konfigurasjoner. Mange SMB-er har samlet år med e-poster der, noen ganger helt siden 2010 eller 2012. Når de bestemmer seg for å bytte til Microsoft 365, skjer migreringen ofte i to omganger.

Steg 1: den første korrupsjonen (før Microsoft 365)

I mange tilfeller har e-postene allerede gjennomgått én migrering. Selskapet har byttet delt hostingleverandør én eller to ganger gjennom årene: fra Gandi til OVH i 2018, så fra OVH til Infomaniak i 2022, for eksempel. Hver IMAP-overføring kan ha satt den opprinnelige INTERNALDATE tilbake til overføringsdatoen (når verktøyet ikke overførte den opprinnelige datoen), og noen verktøy legger også til sine egne migrerings-headere, datert samme dag.

Når e-postene ankommer Microsoft 365 bærer de altså allerede arr. Den opprinnelige Date:-headeren er intakt (den er en del av meldingskroppen, ingen rører den), men datometadataene er allerede blitt forstyrret én gang.

Steg 2: den andre korrupsjonen ved overgangen til Exchange Online

IMAP-migrerings-verktøyet i EAC, eller et tredjepartsverktøy som BitTitan MigrationWiz konfigurert i IMAP-modus, tar deretter inn disse allerede skadede e-postene. Hvis dette verktøyet heller ikke overfører hver e-posts opprinnelige dato, arkiverer Exchange Online e-posten under overføringsdatoen, og det er denne "mottaksdatoen" Outlook ender opp med å vise.

En e-post sendt i mars 2017 kan altså bære to lag med feil datoer: migrerings-headere som ble lagt til ved flyttingen i 2022, og en mottaksdato fra migreringen til Microsoft 365 i 2024. Outlook viser 2024. Brukeren ser 2024. Det er feil på to nivåer.

Egentlig, for å være helt presis: det er ikke alltid den nyeste Received:-headeren som brukes. Outlook bestemmer visningsdatoen ut fra en kombinasjon av INTERNALDATE i Exchange Online-postboksen og headerne som er til stede. Men når migreringsverktøyet ikke overfører de opprinnelige datoene, legger flyttingen til Exchange Online et nytt lag med feil oppå det gamle.

Migreringsverk-tøy og hostingleverandører: risikokombinasjonene

Noen kombinasjoner dukker svært ofte opp i migreringer fra delt hosting:

• OVH / Infomaniak / Ionos + EAC sitt IMAP-verktøy: Microsofts innebygde verktøy er praktisk, men beryktet for å ikke bevare datoer riktig ved volumiøse IMAP-migreringer.
• cPanel (o2switch, LWS osv.) + BitTitan MigrationWiz i IMAP-modus: MigrationWiz i IMAP-modus legger til egne migreringshov-headere. Resultatet er dokumentert, blant annet på siden Rett BitTitan-migreringsdatoer i Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync er et kraftig verktøy, men INTERNALDATE-håndteringen avhenger av konfigurasjonen. Uten riktig alternativ bevares ikke datoene. Se også imapsync: datoer ikke bevart.
• Enhver manuell migrering via drag-and-drop i Outlook: hvis noen kopierte hele mapper ved å dra og slippe mellom to kontoer konfigurert i Outlook, er INTERNALDATE for hver e-post overskrevet med kopieringsdatoen. Uten unntak.

Fellesnevneren: alle disse metodene ender opp i Exchange Online med e-poster der den viste datoen i Outlook ikke lenger stemmer med noe reelt.

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

Å forstå problemet er én ting. Å rette 8000 e-poster fordelt på 40 Exchange Online-postbokser, på kontoer med komplekse mappestrukturer, S/MIME-signerte e-poster, store vedlegg og nestede tråder, er en helt annen sak.

Et PowerShell-skript som ser ut til å fungere på ti teste-poster kan stille feile på melding nummer 4237 på grunn av en ødelagt MIME-grense eller en RFC 2047-kodet header (det formatet =?UTF-8?B?...?= for ikke-ASCII-tegn i avsendernavn). Uten en mekanisme for individuell verifisering vil du ikke vite det. Du har bare en tapt e-post.

De konkrete risikoene ved DIY på denne typen migrering:

• Doble meldinger hvis innsettingslogikken feiler halvveis
• Manglende vedlegg hvis multipart-strukturen er dårlig gjenoppbygd
• Ødelagte tråder i Outlook (samtaler er basert på References:- og In-Reply-To:-headere som kan bli endret)
• 429-feil (Too Many Requests) fra Microsoft Graph API klokken 03:00, som avbryter behandlingen uten rollback
• Ingen enkel måte å verifisere at alle 8000 rettingene ble anvendt korrekt

Og i det spesifikke tilfellet med migreringer fra delt hosting, er det en ekstra vanskelighet: e-postene bærer flere lag med parasittiske Received:-headere, ikke bare ett. Et enkelt skript som fjerner "den siste Received:" er ikke nok. Man må analysere hele headerkjeden for å identifisere hvilken header som tilsvarer hvilken migrering, og hvilken som egentlig representerer den opprinnelige mottaksdatoen.

Det Redate.io gjør annerledes

Hver bruker logger inn med sin egen Microsoft-konto, og Redate.io åpner den ene postboksen med tilgangen som innloggingen gir. Ingen portal, ingen applikasjon å registrere. Det første skannet er gratis: Redate.io identifiserer alle e-postene der den viste datoen ikke stemmer med den faktiske datoen, og gir et nøyaktig estimat per postboks.

Rettingen er basert på en proprietær korreksjonsmotor som analyserer den komplette headerkjeden for hver melding, uansett hvilket migreringsverktøy som ble brukt, og rekonstruerer datometadataene korrekt, selv når flere lag med feil ligger oppå hverandre. Hver rettet e-post verifiseres individuelt. Originalene slettes aldri av Redate.io. De ligger i en synlig mappe i din egen postboks til du selv velger å fjerne dem.

For migreringer fra delt hosting håndterer Redate.io sitt flertrinns analysepipeline eksplisitt dobbelt-korrupsjons-scenariene: det nøyer seg ikke med å se på den siste Received:-headeren, det går gjennom hele historikken for å finne den faktiske mottaksdatoen. Se også hvordan du retter e-postdatoer etter Microsoft 365-migrering generelt, og den spesifikke veiledningen om ødelagte INTERNALDATE i IMAP for å forstå den underliggende mekanikken.

Før eller etter migrering: to tidspunkter for å handle

To situasjoner, to tilnærminger.

Du har ikke migrert ennå. Den gode nyheten: det er mulig å begrense skaden. Noen migrerings-verktøy (MigrationWiz i Exchange-modus, CloudM med riktige innstillinger) bevarer datoer bedre enn andre. Men selv i beste fall vil en migrering fra en delt hostingleverandør uten en ren historikk sannsynligvis etterlate spor. Planlegg et gjennomløp via Redate.io etter migreringen, før du leverer postboksene til brukerne.

Du har allerede migrert og tickets strømmer inn. Redate.io retter eksisterende postbokser i Microsoft 365, uavhengig av hvor gammel migreringen er. Skannet gir deg et nøyaktig bilde av den faktiske tilstanden til hver postboks før du gjør noe som helst. Se også sjekkliste for e-postmigrering for å unngå de samme problemene fremover.

Migrerte du fra OVH, Infomaniak, Ionos eller o2switch til Microsoft 365, og datoene er feil? Opprett en Redate.io-konto for å skanne postboksene dine gratis og se nøyaktig omfanget av skaden før du beslutter deg for noe.