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

Problém s datem 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ý tiket 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 je neporušený, přílohy jsou v pořádku. Ale datum je špatně u každé jedné z nich.

Nejde o chybu CloudM. Dokumentace podpory CloudM to otevřeně uznává. Problém leží na průsečíku toho, jak migrační nástroje přenášejí zprávy, a toho, jak cílové poštovní servery zpracovávají metadata příchozích e-mailů. Ale znalost této skutečnosti nepomůže Vašemu klientovi, jehož schránka se právě stala nesetříditelnou.

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

CloudM Migrate se připojuje ke zdrojové a cílové platformě prostřednictvím 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á při zápisu kopie. Cíl zachová datum, které dostane: Microsoft 365 a Gmail zachovají původní datum, pokud ho kopie nese. Pokud ho nenese, kopie získá jako své datum okamžik vložení. A na Google Workspace každá zpráva zapsaná přes Gmail API navíc získá novou hlavičku Received: datovanou okamžikem vložení.

Takto vypadají hlavičky jednoho z těchto e-mailů, které zůstávají po migraci CloudM do 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

Původní hlavička Date: z roku 2019 tam stále je, stejně jako původní řetězec Received:. Ale v Microsoft 365 je datum, které Outlook zobrazuje jako datum přijetí, vlastním záznamem schránky o tom, kdy každý e-mail dorazil: pokud CloudM nepředal původní datum, tento záznam říká 2. 4. 2026.

Nastavení "Strip Received Headers" v CloudM

CloudM nabízí nastavení, které se tímto problémem zabývá. V Advanced Settings cílové platformy, v části Message Options, je přepínač "Strip Received Headers". Při zapnutí CloudM odstraní hlavičky Received 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 datem po dokončení migrace. V tom okamžiku zprávy už leží v cílové schránce se špatným datem. 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 má toto nastavení menší význam: Microsoft 365 zachová datum, které dostane, takže o zobrazeném datu rozhoduje to, zda CloudM předá původní datum každého e-mailu.

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

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

• Google Workspace do Microsoft 365: E-maily skončí se špatným datem. CloudM čte přes Gmail API a zapisuje do Exchange, a každý e-mail dostane datum kopie.
• Microsoft 365 do Google Workspace: E-maily skončí se špatným datem. I se zapnutým Strip Received Headers přepíše API Google hlavičku Received datem vložení. Dokumentace podpory CloudM to nazývá "přísným omezením platformy".
• Google Workspace do Google Workspace: E-maily skončí se špatným datem. Přechody domén, konsolidace tenantů, fúze po akvizicích: každá zpráva zapsaná přes Gmail API dostane hlavičku Received: datovanou migrací.
• On-premises Exchange do Microsoft 365: Vše závisí na datu, které CloudM předá, ať kopie proběhne přes IMAP nebo EWS.
• Obecný zdroj IMAP do jakéhokoli cíle: Stejné pravidlo: když se CloudM připojí k obecnému serveru IMAP jako zdroji, kopie zobrazuje datum migrace vždy, když se původní datum nepředá cíli.

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. Datum ale cestu nepřežilo.

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

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ří poskytovatelé IT služeb předpokládají, že self-hosted varianta dá větší kontrolu nad zpracováním data, protože migrační servery spravujete přímo. Nedá. O datu rozhoduje to, co migrační engine předá společně s každou zprávou, a tento engine je stejný, ať běží kdekoli. Ať Vaše migrační farma běží v cloudu CloudM nebo na vlastním Azure VM, výsledek pro datum je stejný.

CloudM také nabízí plně spravovanou "Serviced Migration", kde jejich tým řídí projekt od začátku do konce. Stejný výsledek pro datum. Inženýrství je identické, jen ruce na klávesnici jsou jiné. Zaplatili jste si někdy prémiovou službu a stejně jste dostali stejné omezení jako v bezplatné verzi? Přesně takový pocit to je.

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 (zejména zprávy ze starších poštovních serverů, automatizovaných systémů nebo mezinárodních odesílatelů s neobvyklým formátováním časové zóny). Po úpravě CloudM, a navíc s kopií, která nenese původní datum, tyto zprávy skončí s datem, které nemá 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, které by opravily datum 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é hlavičky Received: 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, hlavičky non-ASCII kódované podle RFC 2047 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 z čisté schránky, 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?

A ta skutečná otázka, kterou si většina správců neklade, dokud není pozdě: jak ověříte, že je každá opravená zpráva skutečně neporušená?

Jak Redate.io opravuje datum po migraci CloudM

Redate.io se připojí přímo k postiženým schránkám (Google Workspace, Microsoft 365 nebo IMAP) a hledá e-maily, jejichž zobrazené datum neodpovídá jejich původnímu datu. Kontrola 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 a nepotřebuje znát nástroj, kterým byla migrace provedena. Redate.io provádí cílenou opravu metadat bez změny obsahu zprávy, 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, kontrolou integrity zprávy oproti originálu, než proces pokračuje dál.

Původní e-maily jsou uchovávány ve viditelné záložní složce Redate.io - Originals, dokud ji sami nesmažete. Pokud je potřeba něco vrátit zpět, originály jsou přímo tam, ve schránce, ne schované v nějakém externím archivu.

Pro poskytovatele IT služeb, kteří použili CloudM v prostředích klientů, Redate.io zpracovává opravy více schránek najednou, se stejným ověřením každé zprávy, ať opravujete 1 schránku nebo 500. Problém s datem, který po sobě CloudM zanechal, se nemusí stát trvalou součástí e-mailového prostředí Vašeho klienta.

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í:

• Jak opravit datum e-mailů po migraci CloudM v Gmailu
• Jak opravit datum e-mailů po migraci CloudM v Outlooku
• Jak opravit datum e-mailů po migraci CloudM v Google Workspace
• Jak opravit datum e-mailů po migraci CloudM v Microsoft 365

Pro hlubší vysvětlení, proč k tomu dochází u všech migračních nástrojů, nejen u CloudM, viz proč e-maily ukazují špatné datum po migraci.

Migrovali jste s CloudM a zůstalo Vám špatné datum na každém e-mailu? Spusťte bezplatnou kontrolu a zjistěte přesně, kolik zpráv je postižených a kolik stojí jejich oprava.