English
Français
Deutsch
Español
Português
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Türkçe
Ελληνικά
Русский
Polski
Čeština
Українська
Magyar
Română
Български
Hrvatski
Srpski
Slovenčina
Slovenščina
Lietuvių
Latviešu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
Проблема с датами в CloudM Migrate, о которой никто не предупреждает
CloudM Migrate завершил работу. Панель показывает 100% выполнения, все пользователи перенесены, ноль ошибок. Вы закрываете тикет проекта и переходите к следующему клиенту.
Через неделю звонит ИТ-директор. "Почему каждое письмо в моем почтовом ящике показывает 2 апреля?"
Не некоторые письма. Все. Пять лет переписки с клиентами, юридические документы, кадровые записи, заказы на закупку от 2020 года, и все они показывают дату, когда CloudM запустил миграцию. Сообщения на месте, содержимое не тронуто, вложения в порядке. Но даты неправильные на каждом письме.
Это не ошибка CloudM. Собственная документация поддержки CloudM открыто признаёт это. Проблема находится на пересечении того, как инструменты миграции переносят письма, и того, как целевые почтовые серверы обрабатывают метаданные входящей почты. Но это знание не поможет вашему клиенту, чей почтовый ящик стал непригодным для сортировки.
Как CloudM на самом деле переносит письма
CloudM Migrate подключается к исходной и целевой платформам через их API. Для Google Workspace это сервисная учетная запись с делегированием прав на уровне домена (настраивается в Google Admin Console, в разделе Security > API Controls). Для Microsoft 365 используется либо Exchange Web Services, либо Microsoft Graph API, в зависимости от пути миграции.
Когда CloudM читает письмо из источника, он получает полное содержимое по RFC 2822, включая все оригинальные заголовки и текст письма. Оригинальный заголовок Date: (тот, который почтовый сервер отправителя проставил при первой отправке письма) переносится без изменений. Также переносятся все оригинальные заголовки Received:, отражающие путь доставки письма.
Проблема возникает при записи копии. Целевая платформа сохраняет ту дату, которую ей передают: Microsoft 365 и Gmail сохраняют оригинальную дату, если копия её несёт. Если нет, копия получает дату момента вставки. А в Google Workspace каждое письмо, записанное через Gmail API, дополнительно получает новый заголовок Received:, датированный моментом вставки.
Вот что несут заголовки одного из таких писем после миграции CloudM в Microsoft 365:
Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200
Оригинальный заголовок Date: от 2019 года по-прежнему на месте, и оригинальная цепочка Received: тоже. Но в Microsoft 365 дата, которую Outlook показывает как дату получения, - это собственная запись почтового ящика о том, когда каждое письмо поступило: если CloudM не передал оригинальную дату, эта запись показывает 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 эта настройка значит меньше: Microsoft 365 сохраняет ту дату, которую ей передают, поэтому отображаемую дату определяет то, передаёт ли CloudM оригинальную дату каждого письма.
Какие миграции CloudM портят даты (а какие нет)
Не каждая миграция CloudM приводит к неправильным датам. Результат зависит от сочетания источника и цели, а также от конкретного пути API, который использует CloudM:
- Google Workspace в Microsoft 365: Даты ломаются. CloudM считывает через Gmail API и записывает в Exchange, и каждое письмо получает дату копии.
- Microsoft 365 в Google Workspace: Даты ломаются. Даже с включенным Strip Received Headers API Google перезаписывает заголовок Received датой вставки. Документация поддержки CloudM называет это "строгим ограничением платформы".
- Google Workspace в Google Workspace: Даты ломаются. Смена домена, объединение тенантов, слияния после поглощений: каждое письмо, записанное через Gmail API, получает заголовок
Received:, датированный миграцией. - Локальный Exchange в Microsoft 365: Всё зависит от даты, которую передаёт CloudM, независимо от того, идёт ли копия через IMAP или EWS.
- Источник IMAP (общий) в любую цель: Правило то же: когда CloudM подключается к обычному серверу IMAP как источнику, копия показывает дату миграции всякий раз, когда оригинальная дата не передается цели.
Сложность в том, что панель миграции CloudM ничего из этого не отмечает. Индикатор прогресса заполняется, столбец статуса показывает "Completed", количество элементов совпадает. С точки зрения CloudM миграция прошла успешно. И технически это так. Письма перенесены. Просто даты не пережили переезд.
CloudM Managed и Self-Service: одна и та же проблема с датами
CloudM предлагает две модели развертывания. SaaS-версия (CloudM Migrate hosted) полностью работает в инфраструктуре CloudM. Self-hosted версия позволяет развернуть основные и вторичные серверы миграции в собственной сети, Google Cloud, Azure или AWS.
Некоторые MSP полагают, что self-hosted вариант даёт больше контроля над обработкой дат, поскольку серверы миграции управляются напрямую. Это не так. Дату определяет то, что механизм миграции передаёт вместе с каждым письмом, а этот механизм остается одним и тем же независимо от места запуска. Работает ли ферма миграции в облаке CloudM или на вашей собственной виртуальной машине Azure, результат для дат один и тот же.
CloudM также предлагает полностью управляемую услугу "Serviced Migration", где их команда ведёт проект от начала до конца. Результат для дат тот же. Инженерия идентична, просто руки на клавиатуре другие. Приходилось ли вам платить за премиум-услугу и всё равно получать то же ограничение, что и в бесплатном тарифе? Именно так это и ощущается.
Осложнение с невалидными заголовками Date
Есть ещё одна особенность поведения CloudM, которая усугубляет ситуацию. Когда CloudM встречает исходное письмо с заголовком Date:, не соответствующим RFC 822 (неправильный формат часового пояса, отсутствующий день недели, нестандартный формат), он изменяет заголовок, чтобы обеспечить возможность миграции письма.
Это означает, что некоторые письма теряют даже оригинальную ссылку на дату. Измененный заголовок Date: может вообще не соответствовать реальной дате отправки. Документация поддержки CloudM упоминает это как известное поведение в разделе "Possible Changes to Migrated Items", но не указывает, во что превращается измененная дата.
Для почтового ящика с 12 000 писем, накопленных за восемь лет, могут найтись сотни писем с немного нестандартными заголовками Date (особенно письма со старых почтовых серверов, от автоматизированных систем или от международных отправителей с особенностями форматирования часовых поясов). После изменения CloudM, плюс копия, не несущая оригинальную дату, эти письма получают даты, не имеющие ничего общего с реальностью.
Почему ручное исправление не масштабируется после CloudM
Можно ли исправить это самостоятельно? Технически оригинальный заголовок Date: всё ещё встроен в большинство писем (кроме тех, что CloudM изменил для соответствия RFC). Некоторые администраторы пытались писать скрипты для исправления дат после миграции CloudM.
Вот реальность такого подхода. Вам предстоит подключиться к потенциально тысячам почтовых ящиков, в каждом из которых тысячи писем. Для каждого письма нужно разобрать полную цепочку заголовков, определить, какие заголовки Received: добавил CloudM или целевой сервер, обработать крайние случаи (письма с подписью S/MIME, где изменение заголовков ломает подпись, содержимое, зашифрованное PGP, многосоставные структуры MIME с вложенными границами, закодированные по RFC 2047 не-ASCII заголовки от японских или корейских отправителей), и сделать всё это без потери хотя бы одного вложения и без разрыва цепочек писем.
Скрипт, работающий на 50 тестовых письмах из чистого почтового ящика, не выдержит столкновения с производственной средой из 40 000 писем за десять лет. Что произойдет, когда встретится письмо на 47 МБ с шестью вложенными файлами? А лимиты API (250 единиц квоты Google на пользователя в секунду, ограничение Microsoft на уровне около 10 000 запросов за 10 минут)? Какой у вас план отката, если что-то пойдет не так на письме номер 8 347?
И настоящий вопрос, который большинство администраторов не задают, пока не становится слишком поздно: как проверить, что каждое исправленное письмо действительно осталось целым?
Исправление дат миграции CloudM с помощью Redate.io
Redate.io подключается напрямую к затронутым почтовым ящикам (Google Workspace, Microsoft 365 или IMAP) и сканирует письма, чья отображаемая дата не совпадает с оригинальной. Сканирование бесплатно и занимает пару минут на почтовый ящик, показывая точное количество затронутых писем до принятия каких-либо обязательств.
Исправление использует проприетарный механизм анализа цепочки заголовков, которому не нужно знать, какой инструмент выполнял миграцию. Redate.io выполняет точечное исправление метаданных без изменения содержимого писем, сохраняя вложения, цепочки писем, метки, папки и цифровые подписи. Каждое исправленное письмо проходит индивидуальную проверку, сверяющую целостность письма с оригиналом перед тем, как процесс продолжится.
Оригинальные письма хранятся в видимой папке резервных копий Redate.io - Originals, пока вы сами не удалите её. Если что-то нужно откатить, оригиналы находятся прямо там, в почтовом ящике, а не спрятаны во внешнем архиве.
Для MSP, использовавших CloudM в клиентских средах, Redate.io обрабатывает исправления сразу для множества почтовых ящиков в масштабе, с той же поштучной проверкой писем, независимо от того, исправляете вы один почтовый ящик или пятьсот. Проблема с датами, оставленная CloudM, не обязана становиться постоянной особенностью почтовой среды вашего клиента.
Руководства по платформам для миграций CloudM
Процесс исправления адаптируется к целевой платформе. Redate.io автоматически учитывает особенности каждой платформы, но для подробностей о вашей конфигурации:
- Исправить даты миграции CloudM в Gmail
- Исправить даты миграции CloudM в Outlook
- Исправить даты миграции CloudM в Google Workspace
- Исправить даты миграции CloudM в Microsoft 365
Для более глубокого объяснения того, почему это происходит со всеми инструментами миграции, а не только с CloudM, смотрите статью почему письма показывают неправильные даты после миграции.
Мигрировали с помощью CloudM и застряли с неправильными датами на каждом письме? Запустите бесплатное сканирование, чтобы увидеть точное количество затронутых писем и сколько будет стоить их исправление.