Міграція GWS до GWS: чому дати листів ламаються

Сценарій, якого ніхто не підозрює

Ви щойно завершили міграцію одного тенанта Google Workspace до іншого. Поглинання компанії, зміна домену, злиття двох організацій, які роками співіснували на окремих акаунтах G Suite. Операція пройшла добре, поштові скриньки на місці, користувачі підключилися. У понеділок вранці - перший тікет: "Всі мої листи мають однакову дату." Потім другий. Потім десять.

Інстинктивно думаєш: це точно якась IMAP-проблема, погано налаштований інструмент, щось екзотичне. Але не міграція Google до Google. Проте саме тут усе і відбувається.

Цей сценарій, мабуть, найгірше задокументований у галузі. Більшість IT-адміністраторів, які з ним стикаються, витрачають кілька годин на пошук причини на стороні поштового клієнта, Outlook, налаштувань акаунта - і лише потім розуміють, що проблема в заголовках самих листів.

Чому міграція Google до Google ламає дати

Щоб зрозуміти, що відбувається, треба повернутися до механіки заголовків листів. Кожне повідомлення RFC 2822 містить оригінальне поле Date:, яке встановлює клієнт або сервер-відправник у момент відправки. Це "справжня" дата листа - та, що відповідає часу написання та відправлення.

Але є ще один механізм: INTERNALDATE в IMAP. Це метадані, що зберігаються на стороні сервера і вказують, коли повідомлення було доставлено в скриньку. І от тут починається цікаве.

Коли інструмент міграції переносить лист з одного тенанта Google Workspace до іншого, він використовує протокол IMAP (навіть якщо обидва сервери у Google). Повідомлення зчитується з джерела, а потім вставляється в скриньку призначення. У момент цієї вставки сервер-одержувач автоматично додає заголовок Received: з позначкою часу операції - тобто датою міграції.

А поштові клієнти на кшталт Outlook використовують перший Received: у ланцюжку для відображення дати повідомлення, а не обов'язково оригінальне поле Date:. Результат: усі листи показують дату дня міграції.

Які інструменти спричиняють проблему

Практично всі інструменти для міграції між тенантами Google Workspace потрапляють під це. Без винятків:

• GSMMO (Google Workspace Migration for Microsoft Outlook): спочатку розроблений для міграції з Exchange, але використовується в деяких потоках GWS до GWS.
• CloudM Migrate: дуже поширений у MSP-провайдерів для міжгугл-міграцій, систематично додає Received: міграції. Детальний аналіз - у статті про CloudM Migrate та дати листів.
• BitTitan MigrationWiz: аналогічна ситуація, поведінка описана в матеріалі про BitTitan MigrationWiz.
• imapsync: open-source інструмент для скриптових IMAP-міграцій, у тому числі між двома тенантами Google.
• Ручні експорти/імпорти через Takeout + IMAP-реімпорт: менш поширені, але дають точно такий само ефект.

Причина проста: всі ці інструменти працюють як стандартні IMAP-клієнти. Вони не мають доступу до "нативного" шляху Google, який зберігав би метадані. Навіть якщо обидва тенанти у Google, передача відбувається через IMAP-шар, а цей шар не знає, що спілкується сам із собою.

Механіка заголовків Received у деталях

(До речі, якщо Ви коли-небудь намагалися читати сирі заголовки листа в Gmail або Outlook, то знаєте: задоволення сумнівне. Але саме там захована вся правда.)

Лист, який пройшов нормальний маршрут, містить ланцюжок заголовків Received: у зворотному порядку: сервер, який торкнувся повідомлення останнім, знаходиться зверху. Після міграції заголовок міграції опиняється на самому верху стека.

Ось як це виглядає в повідомленні, що мігрувало через CloudM з одного тенанта GWS до іншого:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <user@new-domain.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

Поле Date: каже 2019 рік. Перший Received: каже жовтень 2024-го. Outlook читає перший Received:. Користувач бачить жовтень 2024 для листа з 2019 року.

Оригінальне поле Date: не зачеплене. Воно нікуди не ділося. Це добра новина: дані є, вони просто чекають, поки їх використають правильно.

Outlook і Gmail поводяться по-різному

Це важливий нюанс. Користувачі, які заходять до пошти через веб-інтерфейс Gmail, часто бачать правильні дати, тому що Gmail у першу чергу використовує поле Date: за RFC 2822 для відображення листів. На вебі проблема менш помітна.

Натомість користувачі, які налаштували скриньку Google Workspace в Outlook через IMAP (або через синхронізацію Exchange ActiveSync), отримують неправильну дату на повну силу - Outlook орієнтується на INTERNALDATE IMAP, а та відображає дату першого Received:, доданого під час міграції.

Насправді поведінка Outlook залежить від версії та способу підключення. Outlook 2019 і Microsoft 365 (актуальні версії) використовують INTERNALDATE при підключенні через IMAP. Старіші версії можуть поводитися трохи інакше. Але в усіх задокументованих виробничих випадках міграція GWS до GWS через IMAP дає неправильні дати в Outlook.

У підсумку в організаціях, що перейшли на новий тенант і мають гібридних користувачів (одні на Gmail в браузері, інші на Outlook), тікети надходять хаотично. IT-команди витрачають час на з'ясування, чому "одні постраждали, а інші ні", тоді як відповідь проста: різниця у поштовому клієнті.

Поглинання, злиття, зміна домену: найпоширеніші випадки

Цей тип міграції зовсім не рідкість. Ось сценарії, які генерують найбільше тікетів:

Поглинання компанії

Компанія, що потрапила під поглинання, мала власний тенант Google Workspace (домен @стараназва.com). Після угоди все треба перенести на тенант материнської компанії (@група.com). 250 скриньок, архіви, вісім років листування. BitTitan або CloudM виконує операцію. Результат: 2,4 млн листів з датою вихідних дня міграції.

Зміна домену

Компанія, що провела ребрендинг, переходить з @стараназва.ua на @нованазва.ua. Той самий тенант Google, але новий тенант створюється з нуля для чистого старту (поширений вибір, щоб уникнути артефактів конфігурації). Міграція скриньок через imapsync або GSMMO. Дати ламаються точно так само.

Консолідація філій

Група з чотирма філіями, кожна на своєму історичному тенанті G Suite, вирішує все об'єднати в одному тенанті. Чотири паралельні міграції, чотири партії листів із зіпсованими датами для обробки.

У всіх трьох сценаріях проблема однакова і рішення те саме. Чекліст міграції пошти допомагає передбачити цей тип проблем до запуску міграції.

Чому власний скрипт - не відповідь

Зрозуміти проблему - одна справа. Написати Python-скрипт, що "чистить заголовки", і запустити його на 30 000 листів у виробничому середовищі - зовсім інша.

Граничних випадків вистачає. Скрипт, який працює на 50 тестових листах у чистому середовищі, неминуче зіткнеться на реальній виробничій скриньці з:

• Повідомленнями з підписами S/MIME або PGP-шифруванням, де будь-яка зміна структури повідомлення анулює криптографічний підпис.
• Листами зі складними вкладеними MIME-структурами (multipart/alternative всередині multipart/mixed із вкладеннями в десятки мегабайтів).
• Заголовками в кодуванні RFC 2047 (не-ASCII символи), які погано налаштовані парсери беззвучно знищують.
• Помилками 429 Too Many Requests від Google API о другій ночі, посеред батча виправлення, що залишає процес у невизначеному стані.
• Листами, в яких ланцюжок Received: неоднозначний: кілька послідовних інструментів міграції кожен додав свій заголовок, і з'ясувати, який саме прибирати, зовсім не тривіально.

І найголовніше питання: як перевірити, лист за листом, що кожне виправлене повідомлення збережене цілком і нічого не втрачено? Власний скрипт таку перевірку, як правило, не робить. Redate.io виконує її автоматично, зберігаючи оригінали у видимій резервній папці протягом 30 днів.

Що робить Redate.io з таким типом міграцій

Redate.io підключається до тенанта Google Workspace призначення (через делегування домену, без ручного втручання в кожну скриньку) і сканує листи, щоб виявити ті, у яких метадані дати не відповідають вмісту повідомлення. Фаза сканування безкоштовна і дає точне уявлення про масштаб проблеми до будь-яких виправлень.

Власний рушій виправлень аналізує ланцюжок заголовків кожного повідомлення, застосовує розпізнавання сигнатур відомих інструментів міграції (BitTitan, CloudM, imapsync, GSMMO та інших) і виконує цільове виправлення метаданих без зміни вмісту повідомлення. Кожен виправлений лист перевіряється окремо. Оригінали зберігаються.

Для міграцій між тенантами Google Workspace зокрема, конвеєр обробляє випадки, коли відбувалося кілька хвиль міграції (наприклад, скринька мігрувала спочатку у 2021-му, потім знову у 2024-му), де потрібно розплутати кілька шарів паразитних заголовків.

Детальні інструкції зі з'єднання для цього типу конфігурацій описані на сторінках виправлення дат CloudM у Google Workspace та виправлення дат BitTitan у Google Workspace.

Виявити проблему до того, як на неї поскаржаться користувачі

Найкращий момент для виявлення зіпсованих дат - одразу після міграції, до запуску в роботу. Швидка перевірка на кількох пілотних скриньках через IMAP-клієнт на кшталт Thunderbird дозволяє порівняти відображувані дати з очікуваними. Якщо всі імпортовані листи, схоже, мають одну нещодавню дату - це характерна ознака проблеми.

Але на практиці проблему часто виявляють через кілька тижнів після міграції, коли користувач шукає старий договір і розуміє, що його скринька Gmail чудово відсортована... за датою міграції. Тисячі листів нагромаджені в одному часовому штампі. Пошук за датою більше не працює. Гілки листування у безладі. Здається, що вся історія зникла.

Для MSP-провайдерів, які регулярно виконують міграції між тенантами Google Workspace, включення сканування Redate.io в чекліст після міграції (до прийому замовником) дозволяє уникнути подібних сюрпризів.

Ви щойно мігрували між двома тенантами Google Workspace, і дати листів некоректні? Запустіть безкоштовне сканування на Redate.io, щоб оцінити масштаб до будь-яких виправлень.