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:, що простежують шлях доставки повідомлення, теж.

Проблема виникає в момент запису копії. Отримувач зберігає ту дату, яку йому передають: 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-версія (hosted CloudM Migrate) працює повністю в інфраструктурі CloudM. Self-hosted версія дозволяє розгорнути primary і secondary сервери міграції у власній мережі, Google Cloud, Azure або AWS.

Деякі MSP вважають, що self-hosted варіант дає більше контролю над обробкою дат, оскільки сервери міграції керуються безпосередньо. Це не так. Дату визначає те, що механізм міграції передає разом із кожним повідомленням, а цей механізм однаковий незалежно від місця роботи. Незалежно від того, чи працює ферма міграції в хмарі CloudM або на вашій Azure VM, результат для дат однаковий.

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

Посібники за платформами для міграцій CloudM

Процес виправлення адаптується до цільової платформи. Redate.io автоматично враховує специфіку кожної платформи, але для деталей щодо Вашої конфігурації:

• Виправити дати міграції CloudM у Gmail
• Виправити дати міграції CloudM в Outlook
• Виправити дати міграції CloudM у Google Workspace
• Виправити дати міграції CloudM у Microsoft 365

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

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