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 på Microsoft 365 er det én detalj som avgjør datoen hver e-post ender opp med.

Exchange Online beholder datoen den får: når imapsync skriver en melding over IMAP, sender den med hver e-posts interne dato (--syncinternaldates er slått på som standard), og kopien beholder den datoen. Det imapsync sender med er derimot datoen KILDEserveren har lagret for hver melding, ikke datoen e-posten ble sendt. På en sunn postboks er de to like. På en postboks som allerede er migrert en gang tidligere eller gjenopprettet fra en sikkerhetskopi, kan kilden ha datoen fra den forrige operasjonen, og imapsync kopierer den slik den er.

Dette er ikke en feil i Microsoft 365 eller i imapsync. Hver kopi bærer trofast den datoen den fikk. Når denne datoen allerede var feil ved kilden, viser alle de påvirkede e-postene datoen for den tidligere operasjonen i stedet for mottaksdatoen, enten du migrerer 500 e-poster eller 500 000.

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. Redate.io trenger ikke å vite hvilket verktøy som utførte migreringen: det finner e-postene der den viste datoen ikke stemmer med den opprinnelige datoen. Hver melding korrigeres og verifiseres individuelt, og originalen bevares i en sikkerhetskopimappe. Redate.io har ingen grense for postboksens størrelse, en postboks med flere hundre tusen e-poster rettes på samme måte som en liten.