Špatná data e-mailů po migraci ze Zoho do Microsoft 365

Co se stalo s vaší poštovní schránkou

Právě jste dokončili migraci domény ze Zoho Mail do Microsoft 365. Infrastruktura Exchange Online je připravena, schránky jsou zřízeny, MX záznamy aktualizovány. A pak, v pondělí ráno, otevře jeden uživatel Outlook a zjistí, že všechny jeho e-maily z roku 2021 zobrazují dnešní datum. Jiný si všimne, že zprávy z loňského roku jsou seřazeny nahoře v doručené poště, jako by právě dorazily. Tikety se začínají hromadit.

Není to chyba Outlooku. Není to ani problém specifický pro Zoho. Jde o očekávané, ale špatně zdokumentované chování každé migrace IMAP do Exchange Online. Přesné pochopení toho, proč k tomu dochází, je prvním krokem ke správné nápravě.

Technická příčina: INTERNALDATE a hlavičky Received

E-mail uložený na serveru IMAP se skládá ze dvou odlišných věcí: surového obsahu zprávy (hlavičky RFC 2822, tělo zprávy, přílohy) a metadat úložiště spravovaných serverem IMAP, mezi která patří INTERNALDATE. Právě tato metadata používají poštovní klienti k zobrazení a řazení zpráv.

Hlavička Date: definovaná v surové zprávě (RFC 2822) představuje datum, kdy byla zpráva sestavena nebo odeslána odesílatelem. INTERNALDATE je naproti tomu datum, kdy server IMAP zprávu přijal nebo uložil. Na zdravém serveru jsou tyto dvě hodnoty obvykle blízké. Po migraci je to jiný příběh.

Jak migrace IMAP kazí data

Když nástroj pro migraci (Zoho Migration Wizard, imapsync, BitTitan nebo jakýkoli jiný) přenáší zprávu ze Zoho Mail do Exchange Online, dělá to prostřednictvím protokolu IMAP. Nástroj se připojí k Zoho, stáhne zprávu a vloží ji do Exchange Online pomocí příkazu IMAP APPEND. A tady to začíná jít špatně.

Exchange Online při přijetí každé zprávy vygeneruje novou hlavičku Received:, kterou přidá na začátek zprávy. Tato hlavička nese přesné datum a čas vložení, tedy datum migrace. Některé nástroje se pokoušejí zachovat původní INTERNALDATE předáním jako parametr příkazu APPEND. Jiné to nedělají, nebo to dělají nesprávně, a Exchange Online pak automaticky přiřadí datum přijetí jako INTERNALDATE.

Výsledek: ať jde o e-mail odeslaný v roce 2019 nebo 2022, jeho INTERNALDATE nyní ukazuje na týden migrace. Outlook čte tuto hodnotu přednostně. Řazení se rozpadne.

Specifické chování Zoho Migration Wizardu

Zoho nabízí vlastní nástroj pro opuštění své platformy: Zoho Migration Wizard. Tento nástroj je praktický pro jednoduché migrace, ale na správcovských fórech je zdokumentováno jeho konkrétní chování: ne vždy správně předává původní INTERNALDATE při vkládání na cílový server.

Přesněji řečeno, problém se týká hlavně migrací na servery, které systematicky přidávají hlavičku Received: ke každé příchozí zprávě, což je přesně chování Exchange Online. I když Zoho Migration Wizard předá původní datum jako parametr APPEND, hlavička Received: vygenerovaná Exchange Online se ocitne na prvním místě v řetězci hlaviček, a Outlook ji používá k určení toho, "kdy e-mail dorazil".

Správci, kteří používají generické IMAP nástroje jako imapsync k odchodu ze Zoho, narážejí na naprosto stejný problém, někdy ještě horší, protože výchozí konfigurace imapsync není optimalizována pro Exchange Online. (Mimochodem, pokud jste někdy procházeli log imapsync řádek po řádku a hledali chybu synchronizace ve dvě v noci, víte, že je to mocný nástroj, ale krajní případy mu odpuštění nezná.)

Proč Outlook zobrazuje špatné datum

Outlook nepoužívá pro zobrazení data e-mailu výhradně hlavičku Date:. Ve většině zobrazení se používá INTERNALDATE poskytnutý serverem IMAP/Exchange, zejména pro řazení doručené pošty. Původní hlavička Date: je ve zprávě přítomna, nedotčena, ale ignoruje se ve prospěch INTERNALDATE.

Proto možnost "Seřadit podle data odeslání" v Outlooku problém nevyřeší. Zobrazí sice jiné datum, ale chování řazení zůstane nestabilní v závislosti na verzi Outlooku a režimu zobrazení (seskupená konverzace nebo ne). Řazení podle data odeslání není řešení. Je to náplast, která odpadne při první aktualizaci klienta.

Skutečný rozsah problému

U migrace Zoho do Microsoft 365 střední velikosti se snadno bavíme o 50 000 až 500 000 dotčených zpráv, v závislosti na stáří schránek a velikosti organizace. Každý e-mail přenesený během okna migrace nese stejné poškozené datum, takže problém je pro uživatele viditelný ihned při prvním otevření Outlooku.

Nejproblematičtější jsou obvykle složky Odeslaná pošta. Obchodní zástupce hledající nabídku odeslanou v březnu 2022 musí prohledat stovky e-mailů, které všechny zobrazují datum migrace. Provozní dopad je reálný, ne jen kosmetický.

A na rozdíl od toho, co by se dalo myslet, problém časem nezmizí. INTERNALDATE se nastaví v okamžiku vložení. Neopraví se sám od sebe. Bez aktivního zásahu si e-maily uchovají poškozené datum donekonečna.

Proč je vlastní oprava riskantnější, než se zdá

Pokušení je pochopitelné: protože původní hlavička Date: je ve zprávě stále přítomna, stačí jen... opravit metadata. Na papíře to dává smysl. V praxi, na produkční schránce s 80 000 e-maily, je to operace, která může dopadnout katastrofálně.

Tady jsou krajní případy, se kterými si domácí skript pravděpodobně neporadí:

• E-maily podepsané S/MIME, jejichž podpis pokrývá všechny hlavičky. Jakákoli změna struktury zprávy zneplatní kryptografický podpis.
• Zprávy šifrované PGP, kde je obsah neprůhledný a jakákoli manipulace s MIME obálkami může zprávu poškodit.
• Hlavičky v ne-ASCII kódování podle RFC 2047 (jména odesílatelů se speciálními znaky), které se rozbijí, pokud skript nesprávně zachází s kódováním.
• Přílohy kódované v base64 s nesprávně ukončenými řádky, nestandardními MIME hranicemi nebo vnořenými multipart strukturami.
• E-maily bez platné hlavičky Date: (to existuje, zejména ve starých exportech ze Zoho), kde skript musí rozhodnout, co s nimi.

Skript, který funguje na 50 testovacích e-mailech, nebude fungovat na produkční schránce ze Zoho s lety historie. A jak ověřit, zprávu po zprávě, že každá oprava je v pořádku a přílohy nebyly zkráceny? Ověřování je přinejmenším stejně složité jako samotná oprava.

Je tu také otázka kvót. API Exchange Online prostřednictvím Microsoft Graph ukládá přísné limity rychlosti (proslulé chyby 429 Too Many Requests). Nekontrolovaný batch na 100 000 zpráv může způsobit dočasné blokování nebo tiché chyby, které je obtížné diagnostikovat zpětně. Bez mechanismu obnovení po chybě začínáte znovu od nuly.

Jak Redate.io opravuje data po migraci ze Zoho

Redate.io se připojí k vašemu tenantovi Microsoft 365 prostřednictvím standardních oprávnění Azure AD bez globálního administrátorského přístupu. Úvodní sken je zdarma: Redate.io identifikuje dotčené schránky a odhadne objem e-mailů s nesprávnými daty porovnáním INTERNALDATE s hodnotami obsaženými v řetězci hlaviček zprávy.

Oprava používá proprietární engine, který analyzuje kompletní řetězec hlaviček každé zprávy, identifikuje specifické signatury nástrojů pro migraci ze Zoho (ať už jde o Zoho Migration Wizard nebo imapsync nakonfigurovaný pro odchod ze Zoho) a rekonstruuje datová metadata prostřednictvím víceúrovňového validačního pipeline. Každý opravený e-mail je ověřen individuálně: integrita obsahu, zachování příloh, soulad s RFC. Originály jsou uchovány v zálohovací složce přístupné po dobu 30 dní.

Žádná opakovaná migrace. Žádný výpadek. Uživatelé pokračují v práci s Outlookem, zatímco oprava probíhá na pozadí.

Cena je jednorázová platba závislá na objemu, bez předplatného. Podrobnosti jsou k dispozici přímo na webu.

Příbuzné scénáře, které stojí za pozornost

Pokud spravujete více migrací souběžně, nebo jste MSP a administrujete klienty opouštějící Zoho, vězte, že stejný problém nastává i při migracích z jiných platforem do Exchange Online. Mechanismus je identický: hlavička Received: vygenerovaná Exchange přepíše INTERNALDATE bez ohledu na zdrojovou platformu.

Pro migrace z Google Workspace, z on-premises Exchange nebo prostřednictvím nástrojů jako BitTitan MigrationWiz nebo CloudM popisují dedikované články na blogu Redate.io chování specifické pro každý nástroj. Stránka Špatná data e-mailů po migraci do Exchange Online poskytuje přehled všech scénářů, které na tento tenant vedou.

Pokud vaše migrace zahrnuje sdílené schránky nebo prostředky Exchange (místnosti, vybavení), problém je stejný a platí stejné opravné nástroje. Průvodci opravami v sekci oprava migrace Exchange IMAP v Outlooku na webu Redate.io popisují kroky připojení k vašemu tenantovi.

Pro týmy, které používají imapsync specificky k odchodu ze Zoho, stránka imapsync: data se nezachovala dokumentuje možnosti konfigurace imapsync a proč nestačí k tomu, aby se problému na Exchange Online zabránilo.

Datum migrace ze Zoho se vám stále zobrazuje v Outlooku? Proveďte bezplatný sken schránek na Redate.io a zjistěte přesný rozsah problému, než se rozhodnete, jak postupovat.