imapsync-migratiedatums in Microsoft 365 herstellen

Migreren naar Microsoft 365 met imapsync klinkt redelijk. Het is gratis, scriptbaar en verwerkt IMAP-naar-IMAP-overdrachten goed in de meeste scenario's. Maar Exchange Online is niet "de meeste scenario's."

De IMAP-gateway van Exchange Online is een compatibiliteitslaag die is vastgeschroefd aan een systeem dat is ontworpen rond EWS en MAPI. Wanneer imapsync een bericht door deze gateway duwt via het standaard e-mailoverdrachtsprotocol, komt het bericht in de volledige transportpijplijn van Exchange Online - dezelfde pijplijn die binnenkomende post van het internet verwerkt. Die pijplijn voegt transportheaders toe, voert Data Loss Prevention-controles uit, past complianceregels toe en stempelt een verse Received-header met het exacte moment waarop het bericht de server bereikte. De --syncinternaldates vlag? De transportpijplijn van Exchange Online trekt zich er niets van aan. De INTERNALDATE wordt overschreven om overeen te komen met het afleveringstijdstempel.

Dit is geen bug die Microsoft van plan is te repareren. Zo werkt de architectuur van Exchange Online. De transportpijplijn behandelt elke verzending via het standaard e-mailoverdrachtsprotocol als een nieuwe berichtaflevering, punt. Of u nu 500 of 500.000 e-mails migreert, elke afzonderlijke krijgt dezelfde migratiedatum in de headers en metadata gestempeld.

Stel u voor dat u uw IT-directeur moet vertellen dat de migratie die u in het weekend hebt uitgevoerd zojuist 6 jaar e-mailgeschiedenis heeft platgeslagen tot een enkele datum. Dat is de realiteit waarmee beheerders worden geconfronteerd na een imapsync-migratie naar Microsoft 365. En in tegenstelling tot Google Workspace (waar de Gmail-webclient het probleem kan maskeren), toont Microsoft 365 de verkeerde datum overal - Outlook desktop, OWA, Outlook mobiel, Microsoft Search. Er is geen ontsnapping aan de clientzijde.

In Microsoft 365 is de schade totaal en zichtbaar. Elke client - Outlook voor Windows, Outlook voor Mac, OWA, Outlook mobiel op iOS en Android - toont het migratietijdstempel. Gebruikers kunnen niet op datum sorteren, kunnen e-mails niet chronologisch vinden, kunnen zoekresultaten gefilterd op datumbereik niet vertrouwen. Een mailbox met 80.000 e-mails die allemaal "12 november 2024" tonen, is functioneel kapot voor dagelijks werk.

De compliance-gevolgen zijn erger. Exchange Online Protection, Microsoft Purview en bewaarbeleid indexeren allemaal het beschadigde afleveringstijdstempel. Een bewaarbeleid dat is ingesteld om e-mails ouder dan 7 jaar te verwijderen, werkt op de verkeerde datum - wat betekent dat e-mails uit 2018 die bijna verwijderd zouden moeten worden nu lijken te dateren uit 2024. Organisaties onder AVG, HIPAA of SEC-regelgeving lopen een reeel regelgevingsrisico wanneer hun e-mailbewaring niet betrouwbaar is. En als er een juridisch bewaarverzoek binnenkomt voor "alle e-mails uit Q3 2023", betekenen de beschadigde datums dat Purview niets teruggeeft - want volgens de metadata bestaan er geen e-mails uit die periode.

Redate.io maakt verbinding met Microsoft 365 en past zijn headerketenanalyse en datummetadatareconstructieproces toe op elk getroffen bericht. Patroonherkenning over de specifieke migratiesignaturen van imapsync identificeert welke Received-headers werden geïnjecteerd tijdens de migratie versus welke tot de oorspronkelijke afleveringsketen behoren. Elk bericht wordt individueel gecorrigeerd en geverifieerd, waarbij het origineel wordt bewaard in een back-upmap. Het Enterprise-plan verwerkt mailboxen tot 100.000 e-mails, en beheerders kunnen meerdere mailboxen verwerken vanuit een enkel dashboard.