Rett imapsync-migreringsdatoer i Microsoft 365

Migrering til Microsoft 365 med imapsync høres fornuftig ut. Det er gratis, det er skriptbart, og det håndterer IMAP-til-IMAP-overføringer godt i de fleste scenarioer. Men Exchange Online er ikke "de fleste scenarioer".

Exchange Onlines IMAP-gateway er et kompatibilitetslag boltet fast på et system laget for EWS og MAPI. Når imapsync skyver en melding gjennom denne gatewayen via standard e-postoverføringsprotokollen, går meldingen inn i Exchange Onlines fulle transportpipeline - den samme pipelinen som behandler innkommende e-post fra internett. Den pipelinen legger til transportheadere, kjører kontroller for datatap, bruker samsvarsregler og stempler en fersk Received-header med det nøyaktige øyeblikket meldingen traff serveren. --syncinternaldates-flagget? Exchange Onlines transportpipeline bryr seg ikke om det. INTERNALDATE overskrives for å samsvare med leveringstidsstempelet.

Dette er ikke en feil Microsoft planlegger å rette. Det er slik Exchange Onlines arkitektur fungerer. Transportpipelinen behandler alle APPEND-operasjoner som en ny meldingslevering, punktum. Enten du migrerer 500 e-poster eller 500 000, får alle sammen den samme migreringsdatoen stemplet inn i headere og metadata.

Se for deg å fortelle IT-sjefen at migreringen du kjørte i helgen nettopp flatet ut 6 års e-posthistorikk til en enkelt dato. Det er virkeligheten administratorer møter etter en imapsync-migrering til Microsoft 365. Og i motsetning til Google Workspace (der Gmails nettklient kan skjule problemet) viser Microsoft 365 feil dato overalt - Outlook på skrivebordet, OWA, Outlook mobil, Microsoft Search. Det finnes ingen klientsideløsning.

I Microsoft 365 er skaden total og synlig. Alle klienter - Outlook for Windows, Outlook for Mac, OWA, Outlook mobil på iOS og Android - viser migreringstidsstempelet. Brukere kan ikke sortere etter dato, kan ikke finne e-poster kronologisk, kan ikke stole på søkeresultater som filtrerer etter datointervall. En postboks med 80 000 e-poster som alle viser "12. november 2024" er funksjonelt ødelagt for daglig arbeid.

Samsvarskonsekvensene er verre. Exchange Online Protection, Microsoft Purview og oppbevaringspolicyer indekserer alle det ødelagte leveringstidsstempelet. En oppbevaringspolicy satt til å slette e-poster eldre enn 7 år opererer på feil dato - noe som betyr at e-poster fra 2018 som bør nærme seg sletting nå fremstår som fra 2024. Organisasjoner under GDPR, HIPAA eller SEC-forskrifter møter reell regulatorisk risiko når e-postoppbevaringen ikke kan stoles på. Og hvis en juridisk forespørsel om hold kommer inn for "alle e-poster fra Q3 2023", betyr de ødelagte datoene at Purview returnerer ingenting - fordi ifølge metadataene finnes det ingen e-poster fra den perioden.

Redate.io kobler seg til Microsoft 365 og bruker sin headerkjedeanalyse og rekonstruksjon av datometadata på alle berørte meldinger. Mønstergjenkjenning på tvers av imapsyncs spesifikke migreringsverktøysignaturer identifiserer hvilke Received-headere som ble injisert under migrering kontra hvilke som tilhører den opprinnelige leveringskjeden. Hver melding korrigeres og verifiseres individuelt, og originalen bevares i en sikkerhetskopimappe. Enterprise-planen håndterer postbokser med opptil 100 000 e-poster, og administratorer kan behandle flere postbokser fra ett dashbord.