Ret imapsync-migreringsdatoer i Microsoft 365

Migrering til Microsoft 365 med imapsync lyder fornuftigt. Det er gratis, scriptbart og håndterer IMAP-til-IMAP overførsler godt i de fleste scenarier. Men Exchange Online er ikke "de fleste scenarier."

Exchange Onlines IMAP-gateway er et kompatibilitetslag boltet på et system designet omkring EWS og MAPI. Når imapsync skubber en besked gennem denne gateway via standardprotokollen for postoverførsel, kommer beskeden ind i Exchange Onlines fulde transportpipeline - den samme pipeline der behandler indgående post fra internettet. Den pipeline tilføjer transportheaders, kører Data Loss Prevention-tjek, anvender compliance-regler og stempler en frisk Received-header med det præcise øjeblik beskeden ramte serveren. Flaget --syncinternaldates? Exchange Onlines transportpipeline er ligeglad med det. INTERNALDATE overskrives til at matche leveringstidsstemplet.

Dette er ikke en fejl Microsoft planlægger at rette. Det er sådan Exchange Onlines arkitektur fungerer. Transportpipelinen behandler enhver standardprotokol for postoverførsel som en ny beskedlevering, punktum. Uanset om du migrerer 500 eller 500.000 e-mails, får hver eneste den samme migreringsdato stemplet i headers og metadata.

Forestil dig at fortælle din IT-direktør, at migreringen du kørte i weekenden lige har fladtrykt 6 års e-mailhistorik til en enkelt dato. Det er virkeligheden administratorer står overfor efter en imapsync-migrering til Microsoft 365. Og i modsætning til Google Workspace (hvor Gmails webklient kan maskere problemet), viser Microsoft 365 den forkerte dato overalt - Outlook desktop, OWA, Outlook mobil, Microsoft Search. Der er ingen klientside-flugtluge.

I Microsoft 365 er skaden total og synlig. Enhver klient - Outlook til Windows, Outlook til Mac, OWA, Outlook mobil på iOS og Android - viser migreringstidsstemplet. Brugere kan ikke sortere efter dato, kan ikke finde e-mails kronologisk, kan ikke stole på søgeresultater filtreret efter datointerval. En postkasse med 80.000 e-mails der alle viser "12. november 2024" er funktionelt ødelagt til dagligt arbejde.

Compliance-konsekvenserne er værre. Exchange Online Protection, Microsoft Purview og opbevaringspolitikker indekserer alle det beskadigede leveringstidsstempel. En opbevaringspolitik indstillet til at slette e-mails ældre end 7 år opererer på den forkerte dato - hvilket betyder at e-mails fra 2018 der burde nærme sig sletning nu ser ud til at være fra 2024. Organisationer under GDPR, HIPAA eller SEC-regulering står over for reel regulatorisk eksponering når deres e-mailopbevaring ikke kan stoles på. Og hvis en juridisk tilbageholdelsesanmodning kommer ind for "alle e-mails fra Q3 2023", betyder de beskadigede datoer at Purview returnerer intet - fordi ifølge metadata eksisterer ingen e-mails fra den periode.

Redate.io forbinder til Microsoft 365 og anvender sin header-kæde-analyse og dato-metadata-rekonstruktionsproces på hver berørt besked. Mønstergenkendelse på tværs af imapsyncs specifikke migreringssignaturer identificerer hvilke Received-headers der blev injiceret under migrering i forhold til hvilke der tilhører den originale leveringskæde. Hver besked rettes og verificeres individuelt, med originalen bevaret i en backup-mappe. Enterprise-planen håndterer postkasser op til 100.000 e-mails, og administratorer kan behandle flere postkasser fra eet dashboard.