Міграція iCloud до Office 365: неправильні дати листів

Сценарій міграції, який системно руйнує дати

Ви щойно завершили перенесення пошти з iCloud до Office 365. Листи на місці, папки створені, все виглядає ідеально. У понеділок вранці надходить перша скарга: "Всі мої старі листи відображають сьогоднішню дату." Потім ще одна. Потім десять.

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

Чому міграція з iCloud до Office 365 ламає дати

Щоб зрозуміти проблему, потрібно розрізнити три речі, які багато хто плутає (зокрема досвідчені IT-адміністратори): заголовок Date:, IMAP INTERNALDATE і дату створення файлу.

Заголовок Date: (RFC 2822)

Кожен лист містить заголовок Date:, який вказує, коли повідомлення було надіслано. Цей заголовок вбудований у необроблене тіло листа і, теоретично, ніколи не змінюється. Це "оригінальна" дата у строгому розумінні слова.

IMAP INTERNALDATE

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

Проблема? Коли інструмент міграції копіює лист з одного IMAP-сервера на інший, він у ідеалі повинен зберігати цей INTERNALDATE. На практиці так буває не завжди.

Особлива поведінка Apple Mail

Apple Mail при синхронізації повідомлень з iCloud іноді використовує дату створення файлу на стороні сервера як орієнтир для INTERNALDATE. Це не баг у строгому сенсі - це інтерпретація специфікації IMAP, яка відрізняється від підходу інших клієнтів. (До речі, якщо ви коли-небудь намагалися налагодити проблему з INTERNALDATE, читаючи сирі RFC IMAP, то знаєте: специфікація залишає чималий простір для інтерпретації саме в цьому питанні.)

Результат: коли ви експортуєте або мігруєте з iCloud через Apple Mail, INTERNALDATE повідомлень може вже бути некоректним ще до того, як вони потраплять до Office 365.

Три методи міграції з iCloud і їхні підводні камені

Пряма IMAP-міграція

Найпоширеніший підхід - налаштувати iCloud як IMAP-джерело, а Office 365 як призначення, а потім скористатися інструментом міграції (imapsync, MigrationWiz або власним рішенням). Інструмент підключається до обох серверів і копіює повідомлення.

Тут проблема подвійна. По-перше, IMAP-сервери Apple мають ліміти швидкості, які змушують інструменти робити паузи: з'єднання закривається та відкривається знову, що може генерувати паразитні INTERNALDATE. По-друге, кожне повідомлення, скопійоване до Exchange Online, отримує за замовчуванням дату надходження, яка відповідає моменту міграції - якщо тільки інструмент явно не передає оригінальний INTERNALDATE у команді вставки.

Деякі інструменти роблять це правильно. Інші - не завжди. На поштовій скриньці з 40 000 повідомлень навіть 2 % помилок - це 800 листів із неправильною датою.

Для міграцій через imapsync дивіться також: виправлення дат міграції imapsync в Microsoft 365.

Експорт .mbox або .eml з подальшим імпортом

Деякі користувачі експортують листи з iCloud через Apple Mail у форматі .mbox, а потім намагаються імпортувати їх в Outlook. Це кустарний метод із непередбачуваними результатами.

Формат .mbox кодує листи як послідовність текстових повідомлень. Дати присутні в окремих заголовках Date:, але розділовий рядок між повідомленнями ("From ") містить дату, яку деякі програми імпорту можуть інтерпретувати як дату створення. Outlook при імпорті .mbox, конвертованого в .pst, іноді використовує саме цю дату-розділювач, а не заголовок Date: самого повідомлення.

Перетягування в Outlook

Ось метод, який завдає найбільше шкоди. Користувач налаштовує обидва облікові записи в Outlook (iCloud і Office 365), а потім перетягує повідомлення з однієї папки до іншої. Виглядає просто. Для дат це катастрофа.

Коли Outlook переміщує лист перетягуванням між двома IMAP-акаунтами, він насправді створює новий файл .EML, вставляє його в акаунт призначення та видаляє оригінал. Цей новий файл успадковує дату створення файлу Windows - тобто точний момент перетягування. Оригінальний заголовок Date: залишається в тілі повідомлення, але INTERNALDATE, записаний на сервері Exchange Online, відповідає даті виконаної операції. Outlook потім показує цю дату міграції для всіх переміщених повідомлень.

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

Що зрештою показують Office 365 та Outlook

Exchange Online зберігає листи разом із їхнім INTERNALDATE. Outlook Desktop зчитує цей INTERNALDATE для відображення дати в стовпці "Отримано" і для сортування папки вхідних. Якщо INTERNALDATE було перезаписано під час міграції - Outlook показує дату міграції, і крапка.

Outlook Web App (OWA) робить те саме. Жодного "альтернативного перегляду", який показував би оригінальну дату з заголовка Date:, не існує. Те, що ви бачите у стовпці дати - це INTERNALDATE.

Оригінальний заголовок Date: завжди присутній, цілий, читабельний, якщо відкрити необроблені заголовки повідомлення. Але жоден стандартний інтерфейс його не відображає. В цьому і полягає головна frustрація цієї проблеми: правильна інформація існує, вона просто недоступна без технічного виправлення.

Що підтримка Microsoft не вирішує

Якщо відкрити тікет у підтримці Microsoft із цією проблемою, найімовірніше отримаєте: підтвердження, що відображувані дати відповідають збереженим INTERNALDATE, пропозицію перевірити параметри сортування в Outlook, і, можливо, переадресацію до інструменту міграції, який використовувався.

Це не зловмисність. У Microsoft просто немає вбудованого інструменту для ретроактивного виправлення INTERNALDATE тисяч повідомлень, вже завантажених до Exchange Online. Виправлення вимагає доступу до кожного повідомлення окремо, аналізу його заголовків і відновлення метаданих дати - це поза межами стандартної підтримки.

Підтримка iCloud, зі свого боку, вважає, що повідомлення були правильно експортовані, а проблема знаходиться на стороні призначення. Обидві служби підтримки перекидають відповідальність одна на одну, і користувач залишається з 12 000 листів, датованих днем міграції.

Проблема масштабу

Зрозуміти, чому дати зламані - це одне. Виправити їх вручну на робочій поштовій скриньці - зовсім інше.

Деякі IT-адміністратори намагаються написати скрипт для виправлення. Базова ідея не така складна для розуміння, але виконання на реальних обсягах породжує проблеми, з якими кустарні скрипти справляються погано:

• Листи з підписом S/MIME або шифруванням PGP не можна змінювати без анулювання криптографічного підпису
• Повідомлення зі складними структурами multipart/alternative (HTML + простий текст + вкладені файли) дуже чутливі до маніпуляцій
• Заголовки в не-ASCII-кодуванні (RFC 2047, зокрема для японських, арабських або кириличних символів) можуть бути пошкоджені інструментами, які неправильно обробляють ці кодування
• Квоти API Microsoft Graph і ліміти швидкості Exchange Online (помилка 429 Too Many Requests) зупиняють скрипти, не розраховані на керування експоненційним відкатом
• Скрипт, який нормально працює на 500 тестових листах, зупиняється о третій ночі на 8000-му повідомленні реальної скриньки - без механізму відновлення

І головне питання: як перевірити, що кожен виправлений лист залишився цілим після виправлення? Що вкладення на місці? Що ланцюжок листування не зламаний? Кустарний скрипт зазвичай цього не перевіряє.

Як Redate.io обробляє міграції з iCloud до Office 365

Redate.io підключається безпосередньо до Office 365 через дозволи Microsoft 365 (Azure AD), без необхідності доступу до серверів iCloud. На момент втручання Redate листи вже знаходяться в Exchange Online.

Механізм виправлення Redate аналізує ланцюжок заголовків кожного повідомлення для визначення оригінальної дати, розрізняючи заголовки Received:, додані під час міграції, і легітимні метадані дати. Цей аналіз включає зіставлення сигнатур із сотнями відомих інструментів міграції, що дозволяє ідентифікувати паразитні заголовки навіть тоді, коли вони не є очевидними.

Кожен виправлений лист перевіряється окремо після обробки. Оригінали зберігаються у видимій резервній папці протягом 30 днів - чого жоден кустарний скрипт не робить за замовчуванням. Початкове сканування безкоштовне і дозволяє точно підрахувати кількість листів із проблемними датами до прийняття рішення про виправлення.

Redate.io підтримує також міграції з Google Workspace до Office 365 і виправлення після міграції cPanel. Дивіться, наприклад: виправлення дат листів після міграції Microsoft 365 або неправильні дати листів після міграції на Exchange Online.

Спочатку сканування, потім виправлення

Рекомендована відправна точка для будь-якої міграції з iCloud до Office 365, після якої з'явились некоректні дати: запустити безкоштовне сканування Redate.io на уражених скриньках. Сканування точно визначає, скільки листів мають підозрілий INTERNALDATE і в яких папках вони знаходяться.

Залежно від обсягу це займає від 12 до 45 хвилин і дає чітку картину масштабів проблеми до будь-якого втручання. Для MSP, які одночасно керують кількома скриньками після міграції, пакетне сканування дозволяє не витрачати час на виправлення скриньок, яким це не потрібно.

Якщо дати Ваших листів некоректні після міграції з iCloud, почніть із безкоштовного сканування на Redate.io, щоб оцінити масштаб проблеми на Ваших скриньках Office 365.