CloudM Migrate: как да поправите датите на имейли

Проблемът с датите на CloudM Migrate, за който никой не предупреждава

CloudM Migrate завърши работата си. Таблото показва 100% завършеност, всички потребители мигрирани, нула грешки. Затваряте тикета на проекта и преминавате към следващия клиент.

Седмица по-късно се обажда ИТ директорът. "Защо всеки имейл в пощата ми показва 2 април?"

Не някои имейли. Всички. Пет години кореспонденция с клиенти, юридически документи, HR записи, поръчки за покупка от 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) работи изцяло в инфраструктурата на CloudM. Self-hosted версията позволява разполагане на основни и вторични миграционни сървъри в собствената мрежа, Google Cloud, Azure или AWS.

Някои MSP-та приемат, че self-hosted опцията дава повече контрол върху обработката на дати, тъй като управлявате миграционните сървъри директно. Не дава. Решаващото за датата е това, което миграционният механизъм предава заедно с всяко съобщение, а този механизъм е един и същ, независимо къде работи. Независимо дали миграционната ферма работи в облака на CloudM или на собствена Azure VM, резултатът за датите е един и същ.

CloudM предлага и напълно управлявана "Serviced Migration", при която екипът им управлява проекта от начало до край. Същият резултат за датите. Инженерията е идентична, само ръцете на клавиатурата са различни.

Усложнението с невалидното Date заглавие

Има още едно поведение, специфично за CloudM, което влошава нещата. Когато CloudM срещне изходен имейл с Date: заглавие, което не отговаря на RFC 822 (неправилен формат на часова зона, липсващ ден от седмицата, нестандартен формат), модифицира заглавието, за да осигури възможността за миграция на съобщението.

Това означава, че някои имейли губят дори оригиналната си референция за дата. Модифицираното Date: заглавие може изобщо да не съответства на реалната дата на изпращане.

За пощенска кутия с 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 обработва корекции на множество пощенски кутии в мащаб, със същата проверка на съобщение, независимо дали поправяте 1 кутия или 500.

Ръководства по платформи за миграции с CloudM

Процесът на корекция се адаптира към целевата платформа. Redate.io автоматично обработва спецификата на всяка платформа, но за подробности относно вашата конфигурация:

• Поправка на дати от миграция с CloudM в Gmail
• Поправка на дати от миграция с CloudM в Outlook
• Поправка на дати от миграция с CloudM в Google Workspace
• Поправка на дати от миграция с CloudM в Microsoft 365

За по-задълбочено обяснение защо това се случва с всички инструменти за миграция (не само CloudM), вижте защо имейлите показват грешни дати след миграция.

Мигрирахте с CloudM и останахте с грешни дати на всеки имейл? Стартирайте безплатно сканиране, за да видите колко съобщения са засегнати и колко струва корекцията.