Nesprávne dátumy emailov po migrácii Zoho do Microsoft 365

Čo sa stalo s vašou poštou

Práve ste dokončili migráciu domény z Zoho Mail do Microsoft 365. Exchange Online beží, schránky sú zriadené, MX záznamy aktualizované. A potom, v pondelok ráno, jeden používateľ otvorí Outlook a zistí, že všetky jeho emaily z roku 2021 zobrazujú dnešný dátum. Iný si všimne, že správy spred roka sú zoradené úplne hore v doručenej pošte, akoby práve prišli. Tikety začínajú pribúdať.

Nie je to chyba Outlooku. Nie je to ani problém špecifický pre Zoho. Je to dôsledok toho, že migračný nástroj neprenesie pôvodný dátum každého emailu. Pochopiť presne, prečo k tomu dochádza, je prvý krok k správnej oprave.

Technická príčina: INTERNALDATE a hlavičky Received

Email uložený na IMAP serveri pozostáva z dvoch oddelených vecí: surového obsahu správy (hlavičky RFC 2822, telo, prílohy) a metadát uloženia spravovaných IMAP serverom, vrátane INTERNALDATE. Práve táto metadáta zaujíma poštových klientov pri zobrazovaní a triedení správ.

Hlavička Date: definovaná v surovej správe (RFC 2822) predstavuje dátum, kedy odosielateľ správu napísal alebo odoslal. INTERNALDATE je dátum, kedy server IMAP správu prijal alebo uložil. Na zdravom serveri sú tieto dve hodnoty blízko seba. Po migrácii je to iná história.

Ako IMAP migrácia môže poškodiť dátumy

Keď nástroj na migráciu (Zoho Migration Wizard, imapsync, BitTitan alebo akýkoľvek iný) prenáša správu z Zoho Mail do Exchange Online, robí to cez protokol IMAP. Nástroj sa pripojí k Zoho, správu stiahne a vloží ju do Exchange Online príkazom IMAP APPEND. A práve tu nastáva problém.

Exchange Online ponechá dátum, ktorý dostane: keď nástroj pri príkaze APPEND odovzdá pôvodný INTERNALDATE každej správy, kópia si ho zachová. Niektoré migračné nástroje to robia. Iné to nerobia, alebo to robia nesprávne, a Exchange Online potom ako INTERNALDATE priradí okamih vloženia, teda dátum migrácie.

Výsledok: či už bol email odoslaný v roku 2019 alebo 2022, jeho INTERNALDATE teraz ukazuje na týždeň migrácie. Outlook číta túto hodnotu prednostne. Triedenie sa zrúti.

Špecifické správanie Zoho Migration Wizard

Zoho ponúka vlastný migračný nástroj pre opustenie svojej platformy: Zoho Migration Wizard. Tento nástroj je praktický pre jednoduché migrácie, no na fórach administrátorov je zdokumentované jeho správanie: nie vždy správne prenáša pôvodný INTERNALDATE pri vkladaní do cieľového servera.

Presnejšie: keď Zoho Migration Wizard pôvodný dátum skutočne odovzdá, Exchange Online si ho zachová a Outlook zobrazí správny dátum. Emaily, ktoré zobrazujú dátum migrácie, sú tie, ktorých dátum sa neodovzdal.

Administrátori, ktorí na odchod z Zoho používajú generické IMAP nástroje ako imapsync, môžu naraziť na rovnaký problém: imapsync kopíruje dátum, ktorý má zdrojový server pri každej správe, takže nesprávny dátum na zdroji sa stane nesprávnym dátumom aj v cieli. (Mimochodom, ak ste niekedy prechádzali log imapsync riadok po riadku o 2:00 v noci pri hľadaní chyby synchronizácie, viete, že je to výkonný nástroj, no nie zvlášť odpúšťajúci pri hraničných prípadoch.)

Prečo Outlook zobrazuje nesprávny dátum

Outlook nepoužíva len hlavičku Date: na zobrazenie dátumu emailu. Vo väčšine zobrazení sa používa INTERNALDATE poskytnutý IMAP/Exchange serverom, najmä pri triedení doručenej pošty. Pôvodná hlavička Date: je v správe prítomná, neporušená, ale ignoruje sa v prospech INTERNALDATE.

Preto možnosť "Triediť podľa dátumu odoslania" v Outlooku problém skutočne nerieši. Zobrazuje iný dátum, áno, ale správanie pri triedení zostáva nestabilné v závislosti od verzie Outlooku a režimu zobrazenia (zoskupené konverzácie alebo nie). Triedenie podľa dátumu odoslania nie je riešenie. Je to náplasť, ktorá odpadne pri prvej aktualizácii klienta.

Skutočný rozsah problému

Pri migrácii Zoho do Microsoft 365 strednej veľkosti hovoríme pokojne o 50 000 až 500 000 ovplyvnených správach, podľa veku schránok a veľkosti organizácie. Každý email prenesený počas migračného okna nesie rovnaký poškodený dátum, čo robí problém okamžite viditeľným pre používateľov pri prvom otvorení Outlooku.

Priečinky Odoslané sú často najproblematickejšie. Obchodník, ktorý hľadá cenovú ponuku odoslanú v marci 2022, musí prehrabávať stovky emailov, ktoré všetky zobrazujú dátum migrácie. Prevádzkový dopad je reálny, nielen kozmetický.

A na rozdiel od toho, čo by sa mohlo zdať, problém časom nezmizne. INTERNALDATE je pevne nastavený v momente vloženia. Neopraví sa sám. Bez aktívneho zásahu si emaily zachovajú poškodený dátum donekonečna.

Prečo vlastná oprava je rizikovejšia, než sa zdá

Pokušenie je pochopiteľné: keďže pôvodná hlavička Date: je stále v správe, stačí... opraviť metadáta. Na papieri to dáva zmysel. V praxi, na produkčnej schránke s 80 000 emailmi, je to operácia, ktorá môže katastrofálne zlyhať.

Tu je niekoľko hraničných prípadov, s ktorými si domáci skript pravdepodobne neporadí:

• Emaily podpísané S/MIME, kde podpis pokrýva celú štruktúru hlavičiek. Akákoľvek zmena štruktúry správy zneplatní kryptografický podpis.
• Správy šifrované PGP, kde je obsah nepriehľadný a každá manipulácia s MIME obálkami môže správu poškodiť.
• Hlavičky zakódované v non-ASCII podľa RFC 2047 (mená odosielateľov so špeciálnymi znakmi), ktoré sa rozpadnú, ak skript nezvláda kódovanie správne.
• Prílohy zakódované v base64 s nesprávne ukončenými riadkami, neštandardnými MIME hranicami alebo vnorenou multipart štruktúrou.
• Emaily bez platnej hlavičky Date: (také existujú, najmä v starých exportoch Zoho), kde musí skript rozhodnúť, čo urobiť.

Skript, ktorý funguje na 50 testovacích emailoch, nebude fungovať na produkčnej Zoho schránke s rokmi histórie. A ako overíte, správu po správe, že každá oprava je neporušená a prílohy neboli skrátené? Overenie je minimálne rovnako zložité ako samotná oprava.

Je tu aj otázka kvót. API Exchange Online cez Microsoft Graph ukladá prísne limity rýchlosti (notoricky známe chyby 429 Too Many Requests). Neobmedzený batch na 100 000 správach môže spustiť dočasné blokovanie alebo tiché chyby, ktoré sa ťažko diagnostikujú spätne. Bez mechanizmu obnovy po chybe začínate odznova.

Ako Redate.io opravuje dátumy po migrácii z Zoho

Redate.io sa pripojí k vášmu Microsoft 365 tenantovi tak, že sa každý používateľ prihlási svojím kontom Microsoft, čím Redate.io získa prístup len k jeho vlastnej schránke. Počiatočný sken je bezplatný: Redate.io identifikuje ovplyvnené schránky a odhadne objem emailov s nesprávnymi dátumami porovnaním INTERNALDATE s hodnotami v reťazci hlavičiek správy.

Oprava využíva proprietárny engine, ktorý analyzuje celý reťazec hlavičiek každej správy, nepotrebuje vedieť, ktorý nástroj migráciu vykonal (Zoho Migration Wizard, imapsync alebo akýkoľvek iný) a rekonštruuje metadáta dátumu cez viacstupňový validačný pipeline. Každý opravený email je overený individuálne: integrita obsahu, zachovanie príloh, zhoda s RFC. Originály sa neodstraňujú: zostávajú vo viditeľnom priečinku vašej schránky, kým ich sami neodstránite.

Žiadna opakovaná migrácia. Žiadny výpadok. Používatelia naďalej pracujú v Outlooku, kým oprava prebieha na pozadí.

Cena je jednorazová platba podľa objemu, bez predplatného. Podrobnosti sú dostupné priamo na stránke.

Súvisiace situácie, o ktorých je dobré vedieť

Ak spravujete viacero migrácií súčasne, alebo ak ste MSP a spravujete klientov odchádzajúcich z Zoho, rovnaký problém nastáva aj pri migráciách z iných platforiem do Exchange Online. Mechanizmus je totožný: kópia dostane dátum, ktorý jej odovzdá nástroj, bez ohľadu na zdroj.

Pre migrácie z Google Workspace, z on-premises Exchange alebo cez nástroje ako BitTitan MigrationWiz či CloudM sa venujú špecifickým správaniam každého nástroja samostatné články na blogu Redate.io. Stránka Nesprávne dátumy emailov po migrácii na Exchange Online poskytuje prehľad všetkých scenárov, ktoré vedú k tomuto problému na danom tenante.

Ak vaša migrácia zahŕňa zdieľané schránky alebo Exchange zdroje (miestnosti, vybavenie), problém je rovnaký a rovnaké opravné nástroje platia. Sprievodca opravou IMAP do Exchange na stránke Redate.io popisuje kroky pripojenia k vášmu tenantovi.

Pre tímy, ktoré na odchod z Zoho používajú imapsync, stránka imapsync nezachoval dátumy? dokumentuje konfiguračné možnosti imapsync a odkiaľ v skutočnosti pochádzajú nesprávne dátumy.

Vaše dátumy z migrácie Zoho sa stále zobrazujú v Outlooku nesprávne? Naskenujte schránky bezplatne na Redate.io a zistite presný rozsah problému pred rozhodnutím, ako postupovať.