Миграция 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-та за миграции между Google тенанти, систематично добавя Received: заглавие от миграцията. Вижте подробния анализ на CloudM.
• BitTitan MigrationWiz: поведението е описано подробно в статията за BitTitan.
• imapsync: инструментът с отворен код, който позволява скриптиране на 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 <потребител@нов-домейн.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 тенант (домейн @stara-kompaniya.com). След придобиването, всичко трябва да мигрира към тенанта на майката (@grupata.com). 250-те пощенски кутии, архивите, 8-те години имейл история. BitTitan или CloudM са наети за операцията. Резултат: 2,4 милиона имейла с датата на уикенда на миграцията.

Смяна на домейн

Ребрандирана компания преминава от @staroime.bg към @novoime.bg. Същият Google тенант, но се създава нов тенант за чисто начало (честа практика за избягване на артефакти в конфигурацията). Миграцията на кутиите минава през imapsync или GSMMO. Датите се чупят по абсолютно същия начин.

Консолидация на дъщерни дружества

Група с 4 дъщерни дружества, всяко на собствен исторически G Suite тенант, решава да обедини всичко в един тенант. Четири паралелни миграции, четири партиди имейли с повредени дати за обработка.

И в трите сценария проблемът е идентичен, а решението е едно и също. Чеклистът за имейл миграция помага да се предвиди този тип проблем преди стартиране на миграцията.

Защо домашен скрипт не е отговорът

Да разберете проблема е едно. Да си кажете "ще напиша Python скрипт, който почиства заглавията" и да го приложите върху 30 000 производствени имейла е съвсем друго.

Граничните случаи са безброй. Скрипт, работещ перфектно върху 50 тестови имейла в чиста среда, неизбежно ще срещне в реална производствена кутия:

• Съобщения с S/MIME подписи или PGP криптирано съдържание, при които всяка промяна в структурата на съобщението анулира криптографския подпис.
• Имейли с комплексни вложени MIME структури (multipart/alternative в multipart/mixed с прикачени файлове от десетки мегабайта).
• Заглавия, кодирани по RFC 2047 (не-ASCII символи), които лошо конфигурираните парсъри "изяждат" безшумно.
• Грешки 429 Too Many Requests от Google API в 2 часа сутринта, по средата на корекционна партида, оставяйки процеса в неопределено състояние.
• Имейли, при които веригата от Received: заглавия е неясна: няколко последователни инструмента за миграция са добавили всеки свое заглавие, и не е тривиално да определите кое да премахнете.

И най-важният въпрос: как да проверите, имейл по имейл, че всяко коригирано съобщение е непокътнато и нищо не е загубено или повредено? Домашен скрипт обикновено не прави тази проверка. Redate.io я прави автоматично, с опазване на оригиналите в видима резервна папка за 30 дни.

Какво прави Redate.io при такъв тип миграция

Redate.io се свързва с целевия Google Workspace тенант (чрез делегиране на домейн, без ръчна намеса кутия по кутия) и сканира имейлите, за да идентифицира тези, чиито метаданни за дата са несъвместими с съдържанието на съобщението. Тази фаза на сканиране е безплатна и дава точна картина на мащаба на проблема преди всякаква корекция.

Proprietary корекционният механизъм след това анализира веригата от заглавия на всяко съобщение, прилага разпознаване на шаблони спрямо известните сигнатури на инструменти за миграция (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 и измерете мащаба на проблема преди всякаква корекция.