Хостинг до Microsoft 365: прихована проблема дат

Проблема, про яку Вам ніхто не сказав

Ви щойно завершили міграцію пошти з OVH, Infomaniak, Ionos або o2switch до Microsoft 365. Майстер міграції в EAC (Exchange Admin Center) пропрацював цілу ніч, все зелене, скриньки заповнені. Понеділок, перший тікет: "Усі мої старі листи мають сьогоднішню дату." Потім другий. Потім десять.

Це не баг Microsoft 365. І не збіг обставин. Це механічний результат IMAP-міграції, і у випадку спільного хостингу проблема часто виявляється вдвічі серйознішою, ніж при звичайній міграції. Ось чому.

Як IMAP працює з датами (і де все йде не так)

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

(До речі, якщо Ви колись намагалися читати необроблені заголовки листів в EAC, то знаєте, що це не найприємніше заняття. Там легко двадцять-тридцять рядків заголовків, перш ніж дістанешся до змісту.)

Коли інструмент IMAP-міграції переносить повідомлення з однієї скриньки до іншої, він має відтворити цей INTERNALDATE на цільовому сервері. Деякі інструменти роблять це коректно. Багато - ні, або роблять з обмеженнями. Сервер-одержувач, зі свого боку, зберігає те, що йому передають: якщо копія несе свою оригінальну дату, Exchange Online цю дату зберігає. Тож якщо дати виявляються неправильними, варто дивитися на інструмент, а не на Microsoft 365.

Результат: кожен перенесений лист виглядає так, ніби його "отримали" в день міграції. Незалежно від того, що він датований 2019 роком.

Двоетапне спотворення дат: чому спільний хостинг ускладнює все

Ось де ситуація стає справді проблематичною для міграцій з провайдерів спільного хостингу на зразок OVH, Infomaniak, Gandi, Ionos або o2switch.

Ці хостинги зазвичай використовують спільні сервери Postfix, Dovecot або cPanel зі стандартними IMAP-конфігураціями. Багато малих підприємств накопичували там листи роками, іноді починаючи з 2010 або 2012 року. Коли вони вирішують перейти на Microsoft 365, міграція нерідко відбувається у два етапи.

Етап 1: перше спотворення дати (ще до Microsoft 365)

У багатьох випадках листи вже пережили першу міграцію. Компанія за роки змінила хостинг один-два рази: з Gandi на OVH у 2018-му, потім з OVH на Infomaniak у 2022-му, наприклад. Кожне таке IMAP-перенесення могло замінити оригінальний INTERNALDATE на дату самого перенесення, якщо інструмент не передавав оригінальну дату, а деякі інструменти також залишають власні заголовки міграції з датою того дня.

Коли листи потрапляють до Microsoft 365, вони вже несуть на собі шрами. Оригінальний заголовок Date: залишається неушкодженим (він є частиною тіла повідомлення, ніхто його не чіпає), але метадані дати вже були порушені один раз.

Етап 2: друге спотворення дати під час переходу на Exchange Online

Інструмент IMAP-міграції в EAC або сторонній інструмент на зразок BitTitan MigrationWiz у режимі IMAP поглинає ці листи з уже неправильними датами. Якщо цей інструмент також не передає оригінальну дату кожного листа, Exchange Online записує лист під датою перенесення, і саме ця дата стає "датою отримання", яку показує Outlook.

Лист, надісланий у березні 2017 року, може нести два шари неправильних дат: заголовки міграції, залишені перенесенням 2022 року, і дату отримання від міграції до Microsoft 365 у 2024-му. Outlook показує 2024. Користувач бачить 2024. Це хибно одразу на двох рівнях.

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

Інструменти міграції і хостинги: небезпечні комбінації

Кілька комбінацій дуже часто зустрічаються при міграціях зі спільного хостингу:

• OVH / Infomaniak / Ionos + IMAP-інструмент EAC: рідний інструмент Microsoft зручний, але відомий тим, що не зберігає коректно дати при великих IMAP-міграціях.
• cPanel (o2switch, LWS тощо) + BitTitan MigrationWiz у режимі IMAP: MigrationWiz у режимі IMAP додає власні заголовки міграції. Результат задокументований, зокрема, на сторінці виправлення дат BitTitan в Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync - потужний інструмент, але його робота з INTERNALDATE залежить від конфігурації. Без відповідного параметра дати не зберігаються. Дивіться також imapsync: дати не збереглися.
• Будь-яка ручна міграція перетягуванням в Outlook: якщо хтось копіював цілі папки через drag-and-drop між двома акаунтами, налаштованими в Outlook, INTERNALDATE кожного листа перезаписується датою копіювання. Без винятків.

Спільний знаменник: усі ці методи дають Exchange Online листи, дата відображення яких в Outlook більше не відповідає реальності.

Чому виправляти це самостійно - погана ідея у великому масштабі

Розуміти проблему - одне. Виправити 8000 листів, розкиданих по 40 скриньках Exchange Online, на акаунтах зі складними структурами папок, листами, підписаними S/MIME, великими вкладеннями й вкладеними ланцюжками відповідей, - зовсім інше.

PowerShell-скрипт, що, здається, працює на десяти тестових листах, може тихо зламатися на повідомленні номер 4237 через пошкоджену MIME-границю або заголовок, закодований за RFC 2047 (той формат =?UTF-8?B?...?= для не-ASCII символів у іменах відправників). Без механізму індивідуальної перевірки Ви про це не дізнаєтесь. Просто буде втрачений лист.

Конкретні ризики DIY-підходу при такому типі міграції:

• Дублікати повідомлень, якщо логіка вставки дає збій посередині
• Відсутні вкладення, якщо multipart-структура відновлена неправильно
• Зламані ланцюжки листів в Outlook (розмови базуються на заголовках References: і In-Reply-To:, які можуть бути змінені)
• Помилки 429 (Too Many Requests) від Microsoft Graph API о третій ночі, що переривають обробку без можливості відкату
• Жодного простого способу перевірити, що всі 8000 виправлень застосовано коректно

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

Що Redate.io робить інакше

Кожен користувач заходить під власним обліковим записом Microsoft, і Redate.io відкриває саме цю скриньку з тими правами доступу, які дає цей вхід. Початкове сканування безкоштовне: Redate.io ідентифікує всі листи, у яких відображувана дата не відповідає реальній, і дає точну оцінку по кожній скриньці.

Виправлення спирається на власний рушій, що аналізує повний ланцюжок заголовків кожного повідомлення, незалежно від використаного інструменту міграції та коректно відновлює метадані дати навіть там, де кілька шарів спотворення дати накладаються один на одний. Кожен виправлений лист перевіряється індивідуально. Оригінали залишаються у видимій папці резервних копій, і Redate.io їх не видаляє.

Для міграцій зі спільного хостингу багатоетапний аналітичний конвеєр Redate.io явно обробляє сценарії подвійного спотворення дат: він не просто дивиться на останній заголовок Received:, а проходить повну історію, щоб знайти реальну дату отримання. Дивіться також, як виправити дати після міграції Microsoft 365 у загальному випадку, і спеціальний посібник щодо зламаних INTERNALDATE в IMAP для розуміння механіки.

До або після міграції: два моменти для дій

Дві ситуації, два підходи.

Ви ще не мігрували. Гарна новина: можна обмежити збитки. Деякі інструменти міграції (MigrationWiz у режимі Exchange, CloudM з правильними параметрами) краще зберігають дати. Але навіть у найкращому разі міграція зі спільного хостингу без чистої історії, швидше за все, залишить сліди. Плануйте запуск Redate.io після міграції, до того як передати скриньки користувачам.

Ви вже мігрували і тікети надходять. Redate.io виправляє наявні скриньки в Microsoft 365 незалежно від того, коли відбулася міграція. Сканування дасть точну картину реального стану кожної скриньки до будь-якого втручання. Зверніться також до чекліста міграції пошти, щоб уникнути таких самих проблем у майбутньому.

Ви мігрували з OVH, Infomaniak, Ionos або o2switch до Microsoft 365 і дати хибні? Створіть акаунт Redate.io, щоб безкоштовно просканувати скриньки і побачити точний масштаб проблеми, перш ніж щось вирішувати.