Неверные даты писем после миграции с Zoho на Microsoft 365

Что происходит с вашей почтой

Вы только что завершили миграцию домена с Zoho Mail на Microsoft 365. Exchange Online настроен, ящики созданы, записи MX обновлены. И в понедельник утром один из пользователей открывает Outlook и видит, что все письма 2021 года отображаются с сегодняшней датой. Другой замечает, что сообщения прошлого года стоят в самом верху входящих, будто только что пришли. Тикеты начинают сыпаться.

Это не баг Outlook. И не специфическая проблема Zoho. Это происходит, когда инструмент миграции не передаёт оригинальную дату каждого письма. Понять, почему это происходит, - первый шаг к нормальному исправлению.

Техническая причина: 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. И вот тут начинаются проблемы.

Exchange Online сохраняет ту дату, которая ему передана: если инструмент передаёт оригинальный INTERNALDATE каждого сообщения через команду APPEND, копия сохраняет его. Некоторые инструменты миграции делают это. Другие этого не делают или делают неправильно, и тогда Exchange Online присваивает момент вставки, то есть дату миграции, в качестве INTERNALDATE.

Результат: будь то письмо 2019 или 2022 года, его INTERNALDATE теперь указывает на неделю миграции. Outlook читает именно это значение в первую очередь. Сортировка рассыпается.

Специфика Zoho Migration Wizard

Zoho предлагает собственный инструмент для переноса почты - Zoho Migration Wizard. Он удобен для простых миграций, но на форумах администраторов задокументировано его конкретное поведение: он не всегда корректно передаёт оригинальный INTERNALDATE при вставке на сервер назначения.

Если быть точным: когда Zoho Migration Wizard действительно передаёт оригинальную дату, Exchange Online сохраняет её, и Outlook показывает верную дату. Письма, которые показывают дату миграции, - это те, чья дата не была передана.

Администраторы, использующие для переноса с Zoho стандартные IMAP-инструменты вроде imapsync, могут столкнуться с той же проблемой: imapsync копирует дату, которую исходный сервер хранит для каждого сообщения, поэтому неверная дата на источнике становится неверной датой и на приёмнике. (Если вы когда-нибудь просматривали лог imapsync строчку за строчкой в 2 ночи в поисках ошибки синхронизации - вы знаете, что это мощный инструмент, но весьма негибкий в граничных ситуациях.)

Почему 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-обёртками могут повредить письмо.
• Заголовки в кодировке RFC 2047 с символами не-ASCII (имена отправителей со специальными символами), которые ломаются, если скрипт неправильно обрабатывает кодировку.
• Вложения в base64 с некорректными переносами строк, нестандартными MIME-границами или вложенными структурами multipart.
• Письма без действительного заголовка Date: (такое встречается, особенно в старых экспортах Zoho), где скрипт должен сам решить, что делать.

Скрипт, который работает на 50 тестовых письмах, не будет работать на производственном ящике Zoho с годами истории. И как проверить, письмо за письмом, что каждое исправление прошло корректно и вложения не обрезались? Верификация не менее сложна, чем само исправление.

Есть ещё вопрос квот. API Exchange Online через Microsoft Graph имеет жёсткие ограничения по частоте запросов (те самые ошибки 429 Too Many Requests). Неограниченный батч на 100 000 сообщений может спровоцировать временные блокировки или тихие ошибки, которые сложно диагностировать после. Без механизма возобновления при сбое придётся начинать заново.

Как Redate.io исправляет даты после миграции с Zoho

Каждый пользователь входит со своей учетной записью Microsoft, и Redate.io открывает именно тот ящик, к которому этот вход даёт доступ. Если организации требуется согласие администратора, Redate.io готовит ссылку, которую можно переслать администратору. Начальное сканирование бесплатно: Redate.io определяет затронутые ящики и оценивает объём писем с некорректными датами, сравнивая INTERNALDATE со значениями в цепочке заголовков сообщения.

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

Никакой повторной миграции. Никаких простоев. Пользователи продолжают работать в Outlook, пока исправление выполняется в фоновом режиме.

Стоимость - разовый платёж на основе объёма, без подписки. Подробности доступны на сайте.

Смежные сценарии, о которых стоит знать

Если вы ведёте несколько миграций параллельно или являетесь MSP, управляющим клиентами, покидающими Zoho, имейте в виду: та же проблема возникает при миграции с других платформ на Exchange Online. Механика идентична: копия получает ту дату, которую передаёт инструмент, независимо от источника.

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

Если ваша миграция затрагивает общие ящики или ресурсы Exchange (переговорные комнаты, оборудование), проблема та же, и те же инструменты исправления применимы. Руководства по исправлению на странице «Исправление дат миграции Exchange IMAP в Outlook» описывают шаги подключения к вашему тенанту.

Для команд, использующих imapsync специально для переноса с Zoho, страница «imapsync: даты не сохранились?» документирует параметры конфигурации imapsync и объясняет, откуда на самом деле берутся неправильные даты.

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