CloudM Migrate: как исправить даты писем

Проблема дат CloudM Migrate, о которой никто не предупреждает

CloudM Migrate завершил работу. Панель управления показывает 100% выполнение, все пользователи перенесены, ноль ошибок. Вы закрываете тикет проекта и переходите к следующему клиенту.

Через неделю звонит ИТ-директор. "Почему каждое письмо во входящих показывает 2 апреля?"

Не некоторые письма. Все. Пять лет переписки с клиентами, юридические документы, кадровые записи, заказы на закупку 2020 года, все помечены датой запуска миграции CloudM. Сообщения на месте, содержание не повреждено, вложения в порядке. Но даты неправильные на каждом.

Это не баг CloudM. Документация поддержки CloudM открыто это признаёт. Проблема находится на пересечении способа передачи сообщений инструментами миграции и обработки метаданных входящей почты целевыми серверами. Но это знание не поможет Вашему клиенту, чей почтовый ящик стал непригодным для сортировки.

Как CloudM на самом деле переносит письма

CloudM Migrate подключается к исходной и целевой платформам через их API. Для Google Workspace это сервисный аккаунт с domain-wide delegation (настраивается в Google Admin Console, раздел Security > API Controls). Для Microsoft 365 используется Exchange Web Services или Microsoft Graph API в зависимости от пути миграции.

Когда CloudM читает сообщение из источника, он получает полное содержимое RFC 2822, включая все оригинальные заголовки и тело сообщения. Оригинальный заголовок Date: (тот, который почтовый сервер отправителя проставил при первой отправке) приходит нетронутым. Все оригинальные заголовки Received:, прослеживающие путь доставки сообщения, тоже.

Проблема возникает на стороне получателя. Когда CloudM записывает сообщение в целевой почтовый ящик, целевой сервер обрабатывает его как новую доставку. Он проставляет свежий заголовок Received: с текущей датой и временем, а INTERNALDATE (временную метку, используемую IMAP для сортировки) устанавливает на момент вставки.

Вот как выглядит цепочка заголовков после миграции CloudM в Microsoft 365:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

Заголовок 2019 года на месте. Оригинальный Date: по-прежнему показывает 23 сентября 2019. Но Outlook читает верхний Received: для определения порядка отображения, а там уже 2 апреля 2026.

Настройка "Strip Received Headers" в CloudM

CloudM предлагает настройку для решения этой проблемы. В Advanced Settings целевой платформы, в разделе Message Options, есть переключатель "Strip Received Headers". При включении CloudM удаляет заголовки received перед вставкой сообщения и заменяет их единственным заголовком, совпадающим с Date: заголовком письма.

Звучит как полное решение? Не совсем.

Во-первых, об этой настройке нужно знать до запуска миграции. Большинство администраторов обнаруживают проблему дат после завершения миграции. К этому моменту сообщения уже лежат в целевом ящике с неправильными датами. Повторный запуск CloudM с включённой настройкой только создаёт дубликаты, не исправляя существующие.

Во-вторых, у этой настройки жёсткое ограничение при использовании Google Workspace в качестве цели. Документация Google подтверждает: Gmail всегда перезаписывает заголовки Received: на сообщениях, вставленных через API, проставляя на них временную метку вставки. Это ограничение на уровне платформы, которое CloudM не может обойти. Даже с включённым "Strip Received Headers" Google Workspace добавляет собственный Received: заголовок с датой миграции.

Для целей Microsoft 365 настройка работает лучше в теории, но транспортный конвейер M365 имеет собственное поведение. Exchange Online может установить INTERNALDATE на основе собственной обработки доставки, в зависимости от способа поступления сообщения в систему.

Какие миграции CloudM портят даты (а какие нет)

Не каждая миграция CloudM приводит к неправильным датам. Результат зависит от комбинации источник-цель и конкретного API-пути, который использует CloudM:

• Google Workspace в Microsoft 365: Даты ломаются. CloudM читает через Gmail API и записывает в Exchange. Транспортный уровень M365 проставляет новые Received заголовки.
• Microsoft 365 в Google Workspace: Даты ломаются. Даже с Strip Received Headers API Google перезаписывает Received заголовок датой вставки. Документация поддержки CloudM называет это "строгим ограничением платформы".
• Google Workspace в Google Workspace: Даты ломаются. Смена домена, объединение тенантов, слияния после поглощений, целевой тенант Google всегда ставит дату миграции на входящие сообщения.
• Локальный Exchange в Microsoft 365: Обычно ломается через IMAP-путь. Если CloudM использует EWS на обеих сторонах, сохранение дат надёжнее, но не гарантировано.
• Общий IMAP-источник в любую цель: Даты ломаются. Когда CloudM подключается к обычному IMAP-серверу как источнику, целевой всё равно добавляет собственные заголовки доставки.

Сложность в том, что панель миграции CloudM ничего из этого не отмечает. Индикатор прогресса заполняется, столбец статуса показывает "Completed", количество элементов совпадает. С точки зрения CloudM миграция прошла успешно. Технически так и есть. Сообщения перенесены. Просто даты не пережили переезд.

CloudM Managed и Self-Service: одна и та же проблема

CloudM предлагает две модели развёртывания. SaaS-версия (hosted CloudM Migrate) работает полностью в инфраструктуре CloudM. Self-hosted версия позволяет развернуть primary и secondary серверы миграции в собственной сети, Google Cloud, Azure или AWS.

Некоторые MSP полагают, что self-hosted вариант даёт больше контроля над обработкой дат, поскольку серверы миграции управляются напрямую. Это не так. Проблема дат возникает на целевом сервере, а не на обрабатывающих узлах CloudM. Независимо от того, работает ли ферма миграции в облаке CloudM или на Вашей собственной Azure VM, целевой почтовый сервер ставит дату миграции на каждое полученное сообщение.

CloudM также предлагает полностью управляемую "Serviced Migration", где их команда ведёт проект от начала до конца. Результат для дат тот же. Инженерия идентична, просто руки на клавиатуре другие.

Осложнение с невалидными заголовками Date

Есть ещё одно поведение, специфичное для CloudM, которое усугубляет ситуацию. Когда CloudM встречает исходное письмо с заголовком Date:, не соответствующим RFC 822 (неправильный формат часового пояса, отсутствующий день недели, нестандартный формат), он модифицирует заголовок для обеспечения возможности миграции.

Это означает, что некоторые письма теряют даже оригинальную ссылку на дату. Модифицированный заголовок Date: может вообще не соответствовать реальной дате отправки. Документация поддержки CloudM упоминает это как известное поведение в разделе "Possible Changes to Migrated Items", но не уточняет, какой становится изменённая дата.

Для почтового ящика с 12 000 сообщениями, накопленными за восемь лет, могут быть сотни писем с немного нестандартными заголовками Date (особенно сообщения от старых почтовых серверов, автоматизированных систем или международных отправителей с особенностями форматирования часовых поясов). После модификации CloudM плюс перезаписи Received заголовка целевым сервером эти сообщения оказываются с датами, не имеющими ничего общего с реальностью.

Почему ручное исправление не масштабируется после CloudM

Можно ли исправить это самостоятельно? Технически, оригинальный заголовок Date: всё ещё встроен в большинство сообщений (кроме тех, которые CloudM модифицировал для RFC-совместимости). Некоторые администраторы пробовали писать скрипты для исправления дат после миграции CloudM.

Реальность такого подхода: Вам нужно подключиться к потенциально тысячам почтовых ящиков, в каждом из которых тысячи сообщений. Для каждого письма нужно разобрать полную цепочку заголовков, определить, какие Received: заголовки добавил CloudM или целевой сервер, обработать крайние случаи (S/MIME подписанные сообщения, где модификация заголовков ломает подпись, PGP-зашифрованный контент, многосоставные MIME-структуры с вложенными boundaries, закодированные по RFC 2047 не-ASCII заголовки от японских или корейских отправителей), и сделать всё это без потери единого вложения или нарушения цепочек писем.

Скрипт, работающий на 50 тестовых письмах, не выдержит столкновения с production-средой из 40 000 сообщений за десятилетие. Что произойдёт, когда встретится письмо на 47 МБ с шестью вложенными файлами? А лимиты API (250 единиц квоты Google на пользователя в секунду, троттлинг Microsoft на уровне 10 000 запросов за 10 минут)? Какой план отката, когда что-то пойдёт не так на сообщении номер 8 347?

Исправление дат миграции CloudM с помощью Redate.io

Redate.io подключается непосредственно к затронутым почтовым ящикам (Google Workspace, Microsoft 365 или IMAP) и сканирует письма с признаками даты миграции CloudM. Сканирование бесплатно и занимает пару минут на один ящик, показывая точное количество затронутых сообщений до любых обязательств.

Исправление использует проприетарный движок анализа цепочки заголовков, который распознаёт характерные для CloudM паттерны миграции в цепочке Received заголовков. Redate.io выполняет точечную коррекцию метаданных без изменения содержимого сообщений, сохраняя вложения, цепочки писем, метки, папки и цифровые подписи. Каждое исправленное сообщение проходит индивидуальную верификацию, проверяя целостность по сравнению с оригиналом.

Оригинальные письма хранятся в видимой папке резервных копий Redate.io - Originals в течение 30 дней. Если что-то нужно откатить, оригиналы прямо там, в почтовом ящике.

Для MSP, использовавших CloudM в клиентских средах, Redate.io обрабатывает массовые исправления с той же поштучной верификацией, будь то 1 ящик или 500.

Руководства по платформам для миграций CloudM

Процесс исправления адаптируется к целевой платформе. Redate.io автоматически учитывает специфику каждой платформы, но для подробностей о Вашей конфигурации:

• Исправить даты миграции CloudM в Gmail
• Исправить даты миграции CloudM в Outlook
• Исправить даты миграции CloudM в Google Workspace
• Исправить даты миграции CloudM в Microsoft 365

Для более глубокого объяснения, почему это происходит со всеми инструментами миграции (не только CloudM), смотрите статью почему письма показывают неправильные даты после миграции.

Мигрировали через CloudM и застряли с неправильными датами? Запустите бесплатное сканирование, чтобы увидеть, сколько сообщений затронуто и сколько стоит исправление.