Виправлення дат міграції 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 листів, кожен отримує ту саму дату міграції, впечатану в заголовки та метадані.

Уявіть, що ви кажете своєму IT-директору, що міграція, проведена на вихідних, щойно сплющила 6 років історії електронної пошти в одну дату. Це реальність, з якою стикаються адміністратори після міграції imapsync до Microsoft 365. I на відміну від 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 та застосовує свій аналіз ланцюжка заголовків i процес реконструкції метаданих дат до кожного ураженого повідомлення. Розпізнавання патернів у специфічних сигнатурах інструменту міграції imapsync визначає, які заголовки Received були впроваджені під час міграції, а які належать до оригінального ланцюжка доставки. Кожне повідомлення виправляється та перевіряється індивідуально, а оригінал зберігається в папці резервної копії. План Enterprise обробляє поштові скриньки до 100 000 листів, а адміністратори можуть обробляти кілька скриньок з однієї панелі управління.