Неверные даты писем после миграции с 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. И вот тут начинаются проблемы.

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 для определения "когда пришло письмо".

Администраторы, использующие для переноса с Zoho стандартные IMAP-инструменты вроде imapsync, сталкиваются с той же проблемой, а порой и в худшем виде: конфигурация imapsync по умолчанию не оптимизирована для Exchange Online. (Если вы когда-нибудь просматривали лог 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

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 (переговорные комнаты, оборудование), проблема та же, и те же инструменты исправления применимы. Руководства по исправлению на странице «Исправление дат миграции Exchange IMAP в Outlook» описывают шаги подключения к вашему тенанту.

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

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