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 očakávané, no zle zdokumentované správanie každej migrácie IMAP do Exchange Online. 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 poškodzuje 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 pri prijatí každej správy vygeneruje novú hlavičku Received:, ktorú pridá na začiatok správy. Táto hlavička nesie presný dátum a čas vloženia, teda dátum migrácie. Niektoré migračné nástroje sa pokúšajú zachovať pôvodný INTERNALDATE jeho odovzdaním ako parametra príkazu APPEND. Iné to nerobia, alebo to robia nesprávne, a Exchange Online potom automaticky priradí dátum prijatia ako INTERNALDATE.

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, problém sa týka hlavne migrácií na servery, ktoré systematicky pridávajú hlavičku Received: ku každej prichádzajúcej správe, čo je presne správanie Exchange Online. Aj keď Zoho Migration Wizard odovzdá pôvodný dátum cez parameter APPEND, hlavička Received: vygenerovaná Exchange Online sa ocitne na prvej pozícii v reťazci hlavičiek, a Outlook ju použije na určenie toho, "kedy email prišiel".

Administrátori, ktorí na odchod z Zoho používajú generické IMAP nástroje ako imapsync, narazia na rovnaký problém, niekedy v horšej forme, pretože predvolená konfigurácia imapsync nie je optimalizovaná pre Exchange Online. (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 cez štandardné Azure AD oprávnenia, bez globálneho administrátorského prístupu. 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, identifikuje špecifické signatúry migračných nástrojov Zoho (či už ide o Zoho Migration Wizard alebo imapsync nakonfigurovaný pre odchod z Zoho) 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 sú uchovávané v záložnom priečinku prístupnom 30 dní.

Ž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ý: hlavička Received: vygenerovaná Exchange Online prepíše INTERNALDATE 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 prečo na Exchange Online nestačia.

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ť.