Ret imapsync-migreringsdatoer i Microsoft 365
Hvorfor imapsync-migreringer viser forkert dato i Microsoft 365
imapsync-migreringer til Microsoft 365 (Exchange Online) står over for en dobbelt udfordring med datobevaring. For det første har Exchange Onlines IMAP-gateway specifikke adfærdsmønstre der kan overskrive den INTERNALDATE der leveres af imapsyncs --syncinternaldates-flag. For det andet tilføjer Exchange Online sin egen Received-header under IMAP APPEND-processen, som stempler hver besked med migreringstidsstemplet.
Microsoft 365's IMAP-implementering er begrænset sammenlignet med fulde Exchange-protokoller (EWS, MAPI). Når imapsync uploader via IMAP, passerer beskeden Exchange Onlines transportpipeline, som behandler den på samme måde som en ny indgående besked. Denne pipeline tilføjer transportheaders, kører compliance-kontroller og stempler beskeden med leveringsmetadata der afspejler den faktiske uploadtid i stedet for den anmodede INTERNALDATE.
Administratorer der vælger imapsync til Microsoft 365-migreringer (ofte fordi det er gratis og scriptbart) opdager efter migreringen, at datobevaring ikke fungerede som forventet. --syncinternaldates-flaget, som fungerer korrekt med mange standard IMAP-servere, producerer ikke de forventede resultater med Exchange Onlines specifikke IMAP-implementering. Hele den migrerede postkasse viser migreringsdatoen i alle Microsoft 365-klienter.
Hvordan dette påvirker Microsoft 365
I Microsoft 365 vises migreringsdatoen ensartet i Outlook desktop, OWA, Outlook mobil og Microsoft Search. I modsætning til Gmail (hvor webklienten kan maskere problemet) refererer alle Microsoft 365-klienter til det samme leveringstidsstempel. Brugere har ingen løsning og ingen klient der viser den korrekte dato, indtil de underliggende Received-headers og INTERNALDATE rettes på serverniveau.
Microsoft 365's administrative og compliance-funktioner er lige så påvirkede. Exchange Online Protection, Data Loss Prevention-politikker og Microsoft Purview-compliance-søgninger indekserer alle migreringstidsstemplet. For organisationer underlagt datalagringsregler betyder de beskadigede datoer, at opbevaringspolitikker baseret på beskedens alder opererer på forkerte data, hvilket potentielt fører til for tidlig sletning af beskeder der burde opbevares eller ubegrænset opbevaring af beskeder der burde have været slettet.
Ofte stillede spørgsmål
Hvorfor fejler imapsync --syncinternaldates med Microsoft 365?
Exchange Onlines IMAP-implementering behandler uploadede beskeder gennem sin transportpipeline, som kan overskrive den anmodede INTERNALDATE. Derudover tilføjer Exchange Online Received-headers der bærer uploadtidsstemplet. Disse serversidige adfærdsmønstre er uden for imapsyncs kontrol.
Burde jeg have brugt et andet migreringsværktøj til Microsoft 365?
De fleste migreringsværktøjer (inklusive kommercielle som BitTitan og CloudM) producerer det samme datoproblem, fordi grundårsagen ligger i hvordan Exchange Online behandler uploadede beskeder. Valget af migreringsværktøj forhindrer ikke problemet. Redate.io løser det uanset hvilket værktøj der blev brugt.
Kan Redate.io rette imapsync-migrerede postkasser i bulk?
Ja. Redate.io understøtter bulkbehandling af postkasser til Microsoft 365. Administratorer kan scanne og rette flere postkasser fra ét dashboard. Enterprise-planen understøtter op til 100.000 e-mails per postkasse.