Миграция iCloud на Office 365: неверные даты писем

Сценарий миграции, который ломает даты

Вы только что перенесли почту с iCloud на Office 365. Письма на месте, папки на месте, всё выглядит нормально. В понедельник утром приходит первая жалоба: «Все мои старые письма показывают сегодняшнюю дату.» Потом вторая. Потом десять.

Это не единичный баг. Миграция с iCloud Mail на Office 365 - один из наиболее задокументированных сценариев повреждения дат писем. Причины сугубо технические и связаны одновременно с поведением Apple Mail, протоколом IMAP и тем, как Microsoft 365 обрабатывает входящие сообщения.

Почему миграция с iCloud на Office 365 ломает даты

Чтобы разобраться в проблеме, нужно различать три вещи, которые многие путают (в том числе опытные IT-администраторы): заголовок Date:, INTERNALDATE IMAP и дату создания файла.

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

Каждое письмо содержит заголовок Date:, указывающий, когда сообщение было отправлено. Этот заголовок встроен в тело письма и теоретически никогда не меняется. Это «оригинальная» дата в строгом смысле слова.

INTERNALDATE в IMAP

Протокол IMAP (определённый в RFC 3501) связывает с каждым сообщением отдельный метаданные под названием INTERNALDATE. Именно это значение большинство почтовых клиентов использует для сортировки и отображения писем во входящих, а не заголовок Date:. Outlook особенно сильно опирается на INTERNALDATE при отображении и сортировке.

Проблема в том, что когда инструмент миграции копирует письмо с одного IMAP-сервера на другой, он в идеале должен сохранять INTERNALDATE. На практике это происходит не всегда.

Особенность поведения Apple Mail

Apple Mail при синхронизации сообщений с iCloud иногда использует дату создания файла на стороне сервера как ориентир для INTERNALDATE. Это не баг в строгом смысле - просто интерпретация спецификации IMAP, которая расходится с тем, как поступают другие клиенты. (Кстати, если Вы когда-нибудь пытались разобраться с INTERNALDATE, читая сырые RFC, Вы знаете, что спецификация оставляет довольно широкое поле для интерпретации именно в этом месте.)

Результат: когда Вы экспортируете или мигрируете почту из 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. Начиная с обновления осенью 2023 года, ситуация немного улучшилась в некоторых сценариях, но перетаскивание между аккаунтами по-прежнему остаётся задокументированным источником повреждения дат.

Что в итоге показывают Office 365 и Outlook

Exchange Online хранит письма вместе с их INTERNALDATE. Outlook Desktop читает именно INTERNALDATE для отображения даты в столбце «Получено» и сортировки входящих. Если INTERNALDATE был перезаписан во время миграции, Outlook показывает дату миграции - и точка.

Outlook Web App (OWA) ведёт себя так же. Никакой «альтернативной view», которая показывала бы оригинальную дату из заголовка Date:, не существует. То, что Вы видите в столбце дат, это INTERNALDATE.

Оригинальный заголовок Date: по-прежнему на месте, нетронутый, читаемый при просмотре сырых заголовков сообщения. Но ни один стандартный интерфейс его не показывает. В этом и состоит главная frustration: нужная информация есть, она просто недоступна без технического исправления.

Что не решит поддержка Microsoft

Если Вы откроете тикет в Microsoft Support по этой проблеме, скорее всего получите: подтверждение того, что отображаемые даты соответствуют хранящимся INTERNALDATE, предложение проверить параметры сортировки в Outlook, и возможно - отсылку к инструменту миграции, который Вы использовали.

Это не злой умысел. У Microsoft просто нет нативного инструмента для ретроактивного исправления INTERNALDATE тысяч сообщений, уже загруженных в Exchange Online. Исправление требует доступа к каждому сообщению индивидуально, анализа заголовков и реконструкции метаданных даты - что выходит за рамки стандартной поддержки.

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

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

Понять, почему даты сломаны, - это одно. Исправить их вручную на рабочем почтовом ящике - совсем другое.

Некоторые IT-администраторы пытаются написать скрипт для исправления. Идея в целом несложна для понимания, но выполнение на реальных объёмах порождает проблемы, с которыми кустарные скрипты справляются плохо:

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

И убийственный вопрос: как проверить, что каждое исправленное письмо осталось целым? Что вложение на месте? Что цепочка переписки не сломана? Кустарный скрипт обычно такую проверку не проводит.

Как Redate.io обрабатывает миграции с iCloud на Office 365

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

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

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

Redate также работает с миграциями с Google Workspace на Office 365 и исправляет даты после миграции cPanel. Подробнее: исправление дат писем после миграции Microsoft 365 или неверные даты после миграции на Exchange Online.

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

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

Это займёт от 12 до 45 минут в зависимости от объёма и даст чёткое представление о масштабе проблемы до любого вмешательства. Для MSP, которые управляют несколькими ящиками после миграции, пакетное сканирование позволяет не исправлять ящики, которые в этом не нуждаются.

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