Неправильні дати після міграції з Zoho до Microsoft 365

Що сталося з вашою поштовою скринькою

Ви щойно завершили міграцію домену з Zoho Mail до Microsoft 365. Інфраструктура Exchange Online налаштована, скриньки підготовлені, MX-записи оновлені. І от у понеділок вранці користувач відкриває Outlook і бачить, що всі листи з 2021 року показують сьогоднішню дату. Інший помічає, що повідомлення за минулий рік відсортовані нагорі вхідних, наче щойно надійшли. Заявки в підтримку починають сипатися.

Це не баг Outlook. І не специфічна проблема Zoho. Це очікувана, але погано задокументована поведінка будь-якої IMAP-міграції до Exchange Online. Зрозуміти, чому саме це відбувається, - перший крок до правильного виправлення.

Технічна причина: INTERNALDATE та заголовки Received

Лист, збережений на IMAP-сервері, складається з двох окремих речей: необробленого вмісту повідомлення (заголовки RFC 2822, тіло, вкладення) і метаданих зберігання, якими керує IMAP-сервер, зокрема INTERNALDATE. Саме цей параметр поштові клієнти використовують для відображення та сортування листів.

Заголовок Date: у необробленому повідомленні (RFC 2822) вказує дату, коли повідомлення було складено або надіслано відправником. INTERNALDATE - це дата, коли IMAP-сервер отримав або зберіг повідомлення. Зазвичай на справному сервері ці значення збігаються. Після міграції - зовсім інша картина.

Як IMAP-міграція псує дати

Коли інструмент міграції (Zoho Migration Wizard, imapsync, BitTitan або будь-який інший) переносить лист із Zoho Mail до Exchange Online, він робить це через протокол IMAP. Інструмент підключається до Zoho, отримує повідомлення, а потім вставляє його в Exchange Online через команду IMAP APPEND. Ось тут і починається проблема.

Exchange Online під час отримання кожного повідомлення генерує новий заголовок Received: і додає його на початок листа. Цей заголовок містить точну дату й час вставки, тобто дату міграції. Деякі інструменти міграції намагаються зберегти оригінальний INTERNALDATE, передаючи його як параметр команди APPEND. Інші цього не роблять або роблять неправильно, і тоді Exchange Online автоматично присвоює дату отримання як INTERNALDATE.

Результат: незалежно від того, чи лист було надіслано в 2019, чи в 2022 році, його INTERNALDATE тепер вказує на тиждень міграції. Outlook зчитує саме це значення в першу чергу. Сортування ламається.

Специфічна поведінка Zoho Migration Wizard

Zoho пропонує власний інструмент для виходу з платформи: Zoho Migration Wizard. Він зручний для простих міграцій, але на адмінських форумах задокументована його конкретна поведінка: він не завжди правильно передає оригінальний INTERNALDATE під час вставки на сервер призначення.

Якщо бути точним, проблема стосується насамперед міграцій на сервери, які систематично додають заголовок Received: до кожного вхідного повідомлення, а саме так і поводиться Exchange Online. Навіть якщо Zoho Migration Wizard передає оригінальну дату через параметр APPEND, заголовок Received:, згенерований Exchange Online, опиняється на першому місці в ланцюжку заголовків, і Outlook використовує його, щоб визначити "коли лист надійшов".

Адміни, які використовують універсальні IMAP-інструменти на кшталт imapsync для виходу з Zoho, стикаються рівно з тією ж проблемою, іноді навіть гіршою, бо стандартна конфігурація imapsync не оптимізована для Exchange Online. (До речі, якщо ви хоч раз переглядали лог imapsync рядок за рядком о другій ночі в пошуках помилки синхронізації, то знаєте: інструмент потужний, але аж ніяк не поблажливий до крайніх випадків.)

Чому Outlook показує неправильну дату

Outlook використовує не лише заголовок Date: для відображення дати листа. У більшості режимів відображення застосовується INTERNALDATE, наданий IMAP/Exchange-сервером, зокрема для сортування вхідних. Оригінальний заголовок Date: присутній у повідомленні та залишається недоторканим, але ігнорується на користь INTERNALDATE.

Саме тому опція "Сортувати за датою надсилання" в Outlook насправді не вирішує проблему. Вона показує іншу дату, так, але поведінка сортування залишається нестабільною залежно від версії Outlook та режиму перегляду (згруповані розмови чи ні). Сортування за датою надсилання - це не рішення. Це пластир, який відклеїться після першого ж оновлення клієнта.

Реальний масштаб проблеми

У середній за розміром міграції з Zoho до Microsoft 365 легко набирається від 50 000 до 500 000 уражених повідомлень, залежно від давності скриньок і розміру організації. Кожен лист, перенесений під час вікна міграції, має однакову пошкоджену дату, і проблема відразу помітна користувачам після першого відкриття Outlook.

Папки "Надіслані" зазвичай найбільш проблематичні. Менеджер, який шукає комерційну пропозицію, надіслану в березні 2022 року, змушений перебирати сотні листів, де у всіх стоїть дата міграції. Операційний вплив реальний, а не суто косметичний.

І всупереч тому, у що хочеться вірити, проблема не зникне з часом. INTERNALDATE фіксується в момент вставки. Сам по собі він не виправляється. Без активного втручання листи зберігатимуть пошкоджену дату безстроково.

Чому самостійне виправлення ризикованіше, ніж здається

Спокуса зрозуміла: якщо оригінальний заголовок Date: досі є в повідомленні, то достатньо... виправити метадані. На папері логічно. На практиці, на робочій скриньці з 80 000 листів, це операція, яка може закінчитися катастрофою.

Ось кілька крайніх випадків, які самописний скрипт, найімовірніше, не обробить коректно:

• Листи з підписом S/MIME, де підпис охоплює всі заголовки. Будь-яка зміна структури повідомлення анулює криптографічний підпис.
• Повідомлення з шифруванням PGP, де вміст непрозорий і будь-яка маніпуляція з MIME-оболонками може пошкодити лист.
• Заголовки не у форматі ASCII, закодовані за RFC 2047 (імена відправників зі спеціальними символами), які ламаються, якщо скрипт не обробляє кодування правильно.
• Вкладення, закодовані у base64 з неправильно завершеними рядками, нестандартними MIME-межами або вкладеними структурами multipart.
• Листи без дійсного заголовка Date: (таке буває, особливо у старих експортах Zoho), де скрипт мусить сам вирішити, що робити.

Скрипт, який працює на 50 тестових листах, не запрацює на робочій скриньці Zoho з багаторічною історією. І як перевірити, повідомлення за повідомленням, що кожне виправлення збережено і вкладення не обрізані? Перевірка щонайменше така ж складна, як і саме виправлення.

Є ще питання квот. API Exchange Online через Microsoft Graph має суворі обмеження швидкості (ті самі помилки 429 Too Many Requests). Batch без контролю навантаження на 100 000 повідомлень може спричинити тимчасові блокування або тихі помилки, які важко діагностувати після завершення. Без механізму відновлення після збою доведеться починати спочатку.

Як Redate.io виправляє дати після міграції з Zoho

Redate.io підключається до вашого тенанта Microsoft 365 через стандартні дозволи Azure AD без прав глобального адміна. Початкове сканування безкоштовне: Redate.io визначає уражені скриньки та оцінює кількість листів з некоректними датами, порівнюючи INTERNALDATE зі значеннями в ланцюжку заголовків повідомлення.

Виправлення виконується за допомогою власного рушія, який аналізує повний ланцюжок заголовків кожного повідомлення, визначає специфічні сигнатури інструментів міграції Zoho (як Zoho Migration Wizard, так і imapsync, налаштований для виходу з Zoho), і відновлює метадані дати через багатоетапний конвеєр валідації. Кожен виправлений лист перевіряється окремо: цілісність вмісту, збереження вкладень, відповідність RFC. Оригінали зберігаються в резервній папці, доступній протягом 30 днів.

Жодної повторної міграції. Жодного простою. Користувачі продовжують працювати в Outlook, поки виправлення виконується у фоновому режимі.

Тарифікація передбачає разовий платіж залежно від обсягу, без підписки. Деталі доступні безпосередньо на сайті.

Суміжні сценарії, які варто знати

Якщо ви керуєте кількома міграціями паралельно або є MSP і адмініструєте клієнтів, які виходять з Zoho, майте на увазі: та ж проблема виникає під час міграцій з інших платформ до Exchange Online. Механіка однакова: заголовок Received:, згенерований Exchange, перезаписує INTERNALDATE незалежно від джерела.

Для міграцій з Google Workspace, Exchange on-premises або через такі інструменти, як BitTitan MigrationWiz чи CloudM, у блозі Redate.io є окремі статті з детальним описом поведінки кожного інструменту. Стаття Неправильні дати листів після міграції на Exchange Online дає загальний огляд усіх сценаріїв, які виникають на цьому тенанті.

Якщо ваша міграція охоплює спільні скриньки або ресурси Exchange (кімнати, обладнання), проблема та сама, і ті самі інструменти виправлення застосовуються. Докладна інформація про підключення до тенанта є на сторінці Виправлення дат міграції Exchange IMAP в Outlook на сайті Redate.io.

Для команд, які використовують imapsync саме для виходу з Zoho, стаття imapsync: дати не збереглися? Як виправити описує параметри конфігурації imapsync і пояснює, чому їх недостатньо, щоб уникнути проблеми на Exchange Online.

Дати міграції з Zoho досі відображаються в Outlook? Відскануйте свої скриньки безкоштовно на Redate.io, щоб точно оцінити масштаб проблеми перед тим, як вирішувати, як діяти.