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-структури з вкладеними межами, закодовані за 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 і застрягли з хибними датами? Запустіть безкоштовне сканування, щоб побачити, скільки повідомлень уражено і скільки коштує виправлення.