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

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

Exchange Online запазва датата, която му е подадена: когато imapsync записва съобщение през IMAP, той предава вътрешната дата на всеки имейл заедно с него (--syncinternaldates е включен по подразбиране) и копието запазва тази дата. Това, което imapsync предава, е обаче датата, която ИЗХОДНИЯТ сървър пази за съответното съобщение, а не датата, на която имейлът е изпратен. При здрава пощенска кутия двете дати съвпадат. При пощенска кутия, която вече е била мигрирана веднъж или възстановена от резервно копие, изходният сървър може да пази датата на тази по-ранна операция, и imapsync я копира такава, каквато е.

Това не е бъг в Microsoft 365 или в imapsync. Всяко копие пренася добросъвестно датата, която му е дадена. Когато тази дата вече е била грешна в източника, независимо дали мигрирате 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 и прилага своя анализ на веригата от заглавни редове и процес на реконструкция на метаданните за дати към всяко засегнато съобщение. Не е нужно да се знае кой инструмент е извършил миграцията: Redate открива имейлите, чиято показана дата не съответства на оригиналната им дата. Всяко съобщение се коригира и проверява индивидуално, като оригиналът се запазва в папка за резервно копие. Redate обработва пощенската кутия без ограничение в размера, независимо дали съдържа 1 000 или 500 000 имейла.