CloudM Migrate: jak opravit špatná data e-mailů

Problém s daty CloudM Migrate, na který Vás nikdo neupozorní

CloudM Migrate dokončil práci. Dashboard ukazuje 100% dokončení, všichni uživatelé migrováni, nula chyb. Zavřete projektový ticket a přejdete k dalšímu klientovi.

O týden později volá IT ředitel. "Proč každý e-mail v mé schránce ukazuje 2. dubna?"

Ne některé e-maily. Všechny. Pět let klientské korespondence, právní dokumenty, HR záznamy, objednávky z roku 2020, všechno zobrazuje datum spuštění migrace CloudM. Zprávy jsou na místě, obsah neporušený, přílohy v pořádku. Ale data jsou špatně na každém e-mailu.

Nejde o chybu CloudM. Dokumentace podpory CloudM to otevřeně uznává. Problém leží na průsečíku způsobu přenosu zpráv migračními nástroji a způsobu zpracování metadat příchozích e-mailů cílovými poštovními servery. Ale znalost této skutečnosti nepomůže klientovi, jehož doručená pošta se stala nesetříditelnou.

Jak CloudM skutečně přenáší e-mailové zprávy

CloudM Migrate se připojuje ke zdrojové a cílové platformě přes jejich API. Pro Google Workspace to znamená servisní účet s domain-wide delegation (nakonfigurovaný v Google Admin Console pod Security > API Controls). Pro Microsoft 365 používá Exchange Web Services nebo Microsoft Graph API v závislosti na cestě migrace.

Když CloudM čte zprávu ze zdroje, získá úplný obsah RFC 2822, včetně všech původních hlaviček a těla zprávy. Původní hlavička Date: (ta, kterou poštovní server odesílatele orazítkoval při prvním odeslání) přichází nedotčená. Stejně tak všechny původní hlavičky Received:, sledující cestu doručení zprávy.

Problém nastává na straně cíle. Když CloudM zapíše zprávu do cílové schránky, cílový server ji zpracuje jako nové doručení. Přidá novou hlavičku Received: s aktuálním datem a časem a nastaví INTERNALDATE (časové razítko, které IMAP používá pro řazení) na okamžik vložení.

Takto vypadá řetězec hlaviček po migraci CloudM do 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

Hlavička z roku 2019 je přímo tam. Původní Date: stále říká 23. září 2019. Ale Outlook čte nejnovější hlavičku Received: pro určení pořadí zobrazení, a ta říká 2. dubna 2026.

Nastavení "Strip Received Headers" v CloudM

CloudM nabízí nastavení, které tento problém řeší. V Advanced Settings cílové platformy, v části Message Options, je přepínač "Strip Received Headers". Při zapnutí CloudM odstraní received hlavičky před vložením zprávy a nahradí je jedinou hlavičkou odpovídající hlavičce Date: e-mailu.

Zní to, jako by to vyřešilo všechno, že? Ne tak docela.

Zaprvé, musíte o tom vědět před spuštěním migrace. Většina správců objeví problém s daty po dokončení migrace. V tom okamžiku zprávy už leží v cílové schránce se špatnými daty. Opětovné spuštění CloudM se zapnutým nastavením jen vytvoří duplikáty, neopraví to, co už tam je.

Zadruhé, toto nastavení má tvrdé omezení, když je cílem Google Workspace. Dokumentace Google to potvrzuje: Gmail vždy přepíše hlavičky Received: u zpráv vložených přes API a orazítkuje je časovým razítkem vložení. Jde o omezení na úrovni platformy, které CloudM nemůže obejít. Dokonce i se zapnutým "Strip Received Headers" Google Workspace přidá vlastní hlavičku Received: s datem migrace.

Pro cíle Microsoft 365 nastavení funguje lépe teoreticky, ale transportní pipeline M365 má vlastní chování. Exchange Online může nastavit INTERNALDATE na základě vlastního zpracování doručení, v závislosti na tom, jak zpráva vstoupí do systému.

Které migrace CloudM rozbijí data (a které ne)

Ne každá migrace CloudM způsobí špatná data. Výsledek závisí na kombinaci zdroj-cíl a konkrétní API cestě, kterou CloudM použije:

• Google Workspace do Microsoft 365: Data se rozbijí. CloudM čte přes Gmail API a zapisuje do Exchange. Transportní vrstva M365 přidá nové Received hlavičky.
• Microsoft 365 do Google Workspace: Data se rozbijí. Dokonce i se Strip Received Headers API Google přepíše Received hlavičku datem vložení. Dokumentace podpory CloudM to nazývá "přísným omezením platformy".
• Google Workspace do Google Workspace: Data se rozbijí. Změny domén, konsolidace tenantů, fúze po akvizicích, cílový tenant Google vždy orazítkuje příchozí zprávy datem migrace.
• On-premises Exchange do Microsoft 365: Obvykle se rozbijí přes cestu IMAP. Pokud CloudM použije EWS na obou stranách, zachování dat je spolehlivější, ale ne zaručené.
• Obecný IMAP zdroj do jakéhokoli cíle: Data se rozbijí. Když se CloudM připojí k obecnému IMAP serveru jako zdroji, cíl i tak přidá vlastní doručovací hlavičky.

Složitá část? Dashboard migrace CloudM nic z toho nesignalizuje. Ukazatel průběhu se vyplní, sloupec stavu říká "Completed", počty položek sedí. Z pohledu CloudM migrace proběhla úspěšně. Technicky ano. Zprávy se přenesly. Data prostě cestu nepřežila.

CloudM Managed a Self-Service: stejný problém s daty

CloudM nabízí dva modely nasazení. SaaS verze (hostovaný CloudM Migrate) běží kompletně v infrastruktuře CloudM. Self-hosted verze umožňuje nasadit primární a sekundární migrační servery ve vlastní síti, Google Cloud, Azure nebo AWS.

Někteří MSP předpokládají, že self-hosted varianta dá větší kontrolu nad zpracováním dat, protože migrační servery spravujete přímo. Nedá. Problém s daty nastává na cílovém serveru, ne na zpracovávajících uzlech CloudM. Ať už Vaše migrační farma běží v cloudu CloudM nebo na vlastním Azure VM, cílový poštovní server orazítkuje datem migrace každou zprávu, kterou přijme.

CloudM také nabízí plně spravovanou "Serviced Migration", kde jejich tým řídí projekt od začátku do konce. Stejný výsledek pro data. Inženýrství je identické, jen ruce na klávesnici jsou jiné.

Komplikace s neplatnou hlavičkou Date

Existuje další chování specifické pro CloudM, které situaci zhoršuje. Když CloudM narazí na zdrojový e-mail s hlavičkou Date:, která nevyhovuje RFC 822 (chybně formátovaná časová zóna, chybějící den v týdnu, nestandardní formát), upraví hlavičku, aby zajistil možnost migrace zprávy.

To znamená, že některé e-maily ztratí dokonce i původní odkaz na datum. Upravená hlavička Date: nemusí vůbec odpovídat skutečnému datu odeslání. Dokumentace podpory CloudM to zmiňuje jako známé chování v části "Possible Changes to Migrated Items", ale nespecifikuje, jaké je upravené datum.

U schránky s 12 000 zprávami nashromážděnými za osm let může být stovky e-mailů s mírně nestandardními Date hlavičkami. Po úpravě CloudM plus přepsání Received hlavičky cílovým serverem tyto zprávy skončí s daty, která nemají nic společného s realitou.

Proč ruční opravy nefungují ve velkém měřítku po CloudM

Dá se to opravit vlastními silami? Technicky je původní hlavička Date: stále vložená ve většině zpráv (kromě těch, které CloudM upravil kvůli shodě s RFC). Někteří správci zkusili napsat skripty pro opravu dat po migraci CloudM.

Realita tohoto přístupu: potřebujete se připojit k potenciálně tisícům schránek, každá s tisíci zpráv. Pro každý e-mail je třeba analyzovat úplný řetězec hlaviček, identifikovat které Received: hlavičky přidal CloudM nebo cílový server, ošetřit okrajové případy (S/MIME podepsané zprávy kde úprava hlavičky rozbije podpis, PGP šifrovaný obsah, vícedílné MIME struktury s vnořenými hranicemi, RFC 2047 kódované non-ASCII hlavičky od japonských nebo korejských odesílatelů), a udělat to vše bez ztráty jediné přílohy nebo rozbití vláken e-mailů.

Skript, který funguje na 50 testovacích e-mailech, nepřežije střet s produkčním prostředím 40 000 zpráv za deset let. Co se stane, když narazíte na e-mail o 47 MB se šesti vnořenými přílohami? A co API limity (250 kvótních jednotek Google na uživatele za sekundu, throttling Microsoft kolem 10 000 požadavků za 10 minut)? Jaký je Váš plán pro rollback, když se něco pokazí u zprávy číslo 8 347?

Oprava dat migrace CloudM s Redate.io

Redate.io se připojí přímo k postiženým schránkám (Google Workspace, Microsoft 365 nebo IMAP) a hledá e-maily nesoucí signaturu data migrace CloudM. Skenování je zdarma a trvá pár minut na schránku, ukazuje přesný počet postižených zpráv před jakýmkoli závazkem.

Oprava využívá proprietární engine analýzy řetězce hlaviček, který identifikuje migrační vzory specifické pro CloudM v řetězci Received hlaviček. Redate.io provádí cílenou korekci metadat bez změny obsahu zpráv, zachovává přílohy, vlákna, štítky, složky a digitální podpisy. Každá opravená zpráva prochází individuálním ověřením integrity oproti originálu.

Původní e-maily jsou uchovávány ve viditelné záložní složce Redate.io - Originals po dobu 30 dnů. Pokud je potřeba cokoli vrátit zpět, originály jsou přímo tam, ve schránce.

Pro MSP, kteří používali CloudM v klientských prostředích, Redate.io zpracovává hromadné opravy se stejným ověřením per zpráva, ať opravujete 1 schránku nebo 500.

Průvodci podle platforem pro migrace CloudM

Proces opravy se přizpůsobuje cílové platformě. Redate.io automaticky řeší specifika každé platformy, ale pro podrobnosti o Vašem nastavení:

• Oprava dat migrace CloudM v Gmailu
• Oprava dat migrace CloudM v Outlooku
• Oprava dat migrace CloudM v Google Workspace
• Oprava dat migrace CloudM v Microsoft 365

Pro hlubší vysvětlení, proč se to děje u všech migračních nástrojů (nejen CloudM), viz proč e-maily ukazují špatná data po migraci.

Migrovali jste s CloudM a zůstali Vám špatná data na každém e-mailu? Spusťte bezplatné skenování a zjistěte, kolik zpráv je postiženo a kolik stojí oprava.