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:, проследяващи пътя на доставка на съобщението.

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

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

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

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

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

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

За пощенска кутия с 12 000 съобщения, натрупани за осем години, може да има стотици имейли с леко нестандартни Date заглавия. След модификацията на CloudM плюс презаписването на Received заглавието от целевия сървър, тези съобщения завършват с дати, които нямат нищо общо с реалността.

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