Коригиране на датите от миграция с imapsync в Microsoft 365

Миграцията към Microsoft 365 с imapsync изглежда разумно. Инструментът е безплатен, поддържа скриптове и се справя добре с IMAP-към-IMAP трансфери в повечето сценарии. Но Exchange Online не е "повечето сценарии."

IMAP шлюзът на Exchange Online е слой за съвместимост, добавен към система, проектирана около EWS и MAPI. Когато imapsync изпраща съобщение през този шлюз чрез стандартния протокол за пренос на поща, съобщението влиза в пълния транспортен конвейер на Exchange Online - същия конвейер, който обработва входящата поща от интернет. Този конвейер добавя транспортни заглавни редове, извършва проверки за предотвратяване на загуба на данни, прилага правила за съответствие и маркира нов Received заглавен ред с точния момент, в който съобщението е достигнало сървъра. Флагът --syncinternaldates? Транспортният конвейер на Exchange Online не се съобразява с него. INTERNALDATE се презаписва, за да съвпадне с времевия маркер на доставката.

Това не е бъг, който Microsoft планира да поправи. Така е проектирана архитектурата на Exchange Online. Транспортният конвейер третира всяко изпращане чрез стандартния протокол за пренос на поща като ново доставяне на съобщение, без изключение. Независимо дали мигрирате 500 или 500 000 имейла, всеки един получава същата дата на миграция в заглавните редове и метаданните.

Представете си да кажете на ИТ директора си, че миграцията, която сте извършили през уикенда, е превърнала 6 години имейл история в една-единствена дата. Това е реалността, с която се сблъскват администраторите след миграция с imapsync към Microsoft 365. И за разлика от Google Workspace (където уеб клиентът на Gmail може да маскира проблема), Microsoft 365 показва грешната дата навсякъде - Outlook десктоп, OWA, Outlook мобилно приложение, Microsoft Search. Няма изходен вариант от страната на клиента.

В Microsoft 365 щетите са пълни и видими. Всеки клиент - Outlook за Windows, Outlook за Mac, OWA, Outlook мобилно приложение за iOS и Android - показва времевия маркер на миграцията. Потребителите не могат да сортират по дата, не могат да намират имейли хронологично, не могат да се доверят на резултати от търсене, филтрирани по период. Пощенска кутия с 80 000 имейла, всички показващи "12 ноември 2024", е функционално повредена за ежедневна работа.

Последиците за съответствието са още по-тежки. Exchange Online Protection, Microsoft Purview и политиките за задържане индексират повредения времеви маркер на доставката. Политика за задържане, настроена да изтрива имейли по-стари от 7 години, работи с грешната дата - което означава, че имейли от 2018, които би трябвало да наближават изтриване, сега изглеждат сякаш са от 2024. Организации, подчинени на GDPR, HIPAA или регулации на SEC, са изложени на реален регулаторен риск, когато задържането на имейли е ненадеждно. А ако постъпи заявка за правно задържане за "всички имейли от Q3 2023", повредените дати означават, че Purview не връща нищо - защото според метаданните от този период не съществуват имейли.

Redate.io се свързва с Microsoft 365 и прилага своя анализ на веригата от заглавни редове и процес на реконструкция на метаданните за дати към всяко засегнато съобщение. Разпознаването на шаблони в специфичните сигнатури на инструмента за миграция imapsync идентифицира кои Received заглавни редове са били добавени по време на миграцията и кои принадлежат към оригиналната верига на доставка. Всяко съобщение се коригира и проверява индивидуално, като оригиналът се запазва в папка за резервно копие. Планът Enterprise обработва пощенски кутии до 100 000 имейла, а администраторите могат да обработват множество кутии от едно табло.