Nový Outlook: nesprávne dátumy po migrácii, skutočné príčiny

Dva Outloky, dva rozdielne správania pri rovnakých emailoch

Ak ste nedávno migrovali poštové schránky do Microsoft 365 a niektorí používatelia sa sťažujú, že všetky staré emaily zobrazujú rovnaký dátum (dátum migrácie), možno ste si všimli niečo zvláštne: používatelia klasického Outlooku niekedy vidia správny dátum v čítacom paneli, zatiaľ čo tí na novom Outlooku pre Windows systématicky vidia dátum migrácie. Tá istá schránka. Tie isté emaily. Rozdielne výsledky.

Nejde o chybu v pravom zmysle slova. Je to architektonické rozhodnutie, ktoré má priame dôsledky na to, ako sa dátumy zobrazujú po IMAP migrácii. Aby sme pochopili, čo sa deje, musíme sa pozrieť na detaily emailových hlavičiek a protokolu IMAP, čo nie je úplne ľahké čítanie, ale vysvetľuje, prečo žiadna manipulácia na strane klienta nestačí na vyriešenie problému.

IMAP INTERNALDATE: skutočný vinník

Keď je email uložený na IMAP serveri, existujú pre neho dva typy dátumov, ktoré koexistujú a neprekrývajú sa.

Prvým je hlavička Date:, definovaná v RFC 2822. Je to dátum napísaný priamo v správe, ktorý odosielateľ nastavil v momente odoslania emailu. Je súčasťou tela správy a nikdy sa nemení, bez ohľadu na to, kadiaľ email putuje.

Druhým je INTERNALDATE, metadáta spravované IMAP serverom, ktoré sú mimo samotnej správy. Je to dátum, kedy server správu prijal a zaznamenal. Pri bežnej migrácii kvalitné nástroje pôvodnú INTERNALDATE zachovajú. Pri zle nakonfigurovanej migrácii, alebo s nástrojmi, ktoré tieto metadáta nespravujú správne, sa INTERNALDATE resetuje na aktuálny dátum migrácie. Výsledok: všetky migrované emaily nesú rovnaký dátum doručenia z pohľadu servera.

(Mimochodom, ak ste niekedy čítali logy imapsync alebo MigrationWiz, viete, že existujú špecifické prepínače na pokus o zachovanie INTERNALDATE. Tieto prepínače nefungujú vždy a niektoré cieľové servery ich odmietajú rešpektovať.)

Klasický Outlook: ako číta dátumy

Klasický Outlook, teda lokálne nainštalované COM verzie (Outlook 2016, 2019, 2021 a desktopový klient Microsoft 365 Apps), používa o niečo zložitejší mechanizmus na určenie, ktorý dátum zobraziť v zozname správ.

Pre emaily v priečinku Odoslané sa opiera o hlavičku Date:. Pre prijaté emaily používa prednostne INTERNALDATE zo servera, ale v určitých kontextoch (najmä keď je zapojená OST vyrovnávacia pamäť, alebo pri prvom zobrazení v čítacom paneli) môže čítať aj reťazec hlavičiek Received:, aby zrekonštruoval približný pôvodný dátum.

Práve preto vidíme toto nekonzistentné správanie: klasický Outlook môže niekedy zobraziť správny dátum v čítacom paneli, pretože pre podrobný náhľad číta pôvodnú hlavičku Date: správy, aj keď samotný zoznam emailov využíva poškodenú INTERNALDATE. Pozor však, nie je to spoľahlivé a nič to neopravuje. Zoradenie zostáva rozbité, vyhľadávanie podľa dátumu zostáva skreslené.

Nový Outlook: radikálne odlišná architektúra

Nový Outlook pre Windows, postupne nasadzovaný od konca roka 2023, už nie je COM aplikáciou. V podstate ide o Progressive Web App (PWA) postavenú na rovnakom kódovom základe ako Outlook na webe (OWA). Táto prepracovaná architektúra má hlboké dôsledky.

Nový Outlook zobrazovanie dátumov úplne deleguje na Microsoft 365 API. Nečíta hlavičky Received:, neprehrabáva sa reťazcom hlavičiek, aby našiel pôvodný dátum, a nepokúša sa o žiadnu rekonštrukciu na strane klienta. Jednoducho zobrazuje to, čo mu vráti server: INTERNALDATE.

Výsledok: ak bola INTERNALDATE pri migrácii poškodená, nový Outlook neváha. Zobrazuje dátum migrácie pre každý dotknutý email, bez výnimky, bez nuancií. Je to správanie konzistentnejšie a predvídateľnejšie ako u klasického Outlooku, ale problém migrácie sa stáva okamžite viditeľným a nemožno ho ignorovať.

Admin, ktorý migruje 300 schránok v piatok večer, zistí v pondelok ráno, že všetci používatelia nového Outlooku vidia celé archívy datované minulým víkendom. Tikety prichádzajú rýchlo.

Prečo žiadne obchádzanie na strane klienta nefunguje

Mnohí admini skúšajú riešenia na strane klienta skôr, ako si uvedomia, že problém je v serverových dátach. Tu sú klasické pokusy a dôvody ich zlyhania.

Zoradiť podľa "Dátumu odoslania" namiesto "Dátumu prijatia"

Zoradenie podľa dátumu odoslania v Outlooku sa opiera o hlavičku Date: správy, ktorá je neporušená. Toto zoradenie teda môže fungovať. Ale je to náplasť, nie riešenie. Vyhľadávanie podľa dátumu zostáva rozbité. Pravidlá založené na dátume zostávajú nepoužiteľné. A hlavne, používateľ musí ručne prekonfigurovať každý priečinok, každú schránku. Na 300 schránkach je to nereálne. Triedenie podľa dátumu odoslania nie je riešenie a koncoví používatelia nechápajú, prečo sa od nich žiada zmena návykov.

Vymazanie vyrovnávacej pamäte Outlooku alebo vytvorenie nového profilu

To sa nedotýka INTERNALDATE na strane servera. Po vytvorení nového profilu Outlook znovu synchronizuje emaily zo servera a stiahne presne tie isté poškodené metadáta. Vyrovnávacia pamäť nie je problémom.

Používanie OWA namiesto Outlooku

OWA a nový Outlook zdieľajú rovnakú databázu. Ak je INTERNALDATE poškodená na serveri Exchange Online, OWA zobrazuje presne ten istý nesprávny dátum. Zmena klienta nezmení dáta.

Problém je na serveri, v metadátach každej správy. Žiadna akcia na strane klienta nemôže opraviť dáta uložené na strane servera.

Pasca hlavičiek Received: prečo komplikujú všetko

Keď migračný nástroj skopíruje email z jedného servera na druhý cez IMAP, cieľový server automaticky pridá hlavičku Received: na začiatok reťazca, s dátumom a časom vloženia. Toto je štandardné správanie SMTP a IMAP serverov, ktoré dodržiavajú RFC.

Tieto hlavičky sa hromadia v opačnom poradí, ako email putoval. Najnovšia je hore. Niektorí emailoví klienti čítajú prvú hlavičku Received:, aby odhadli dátum doručenia, čo dáva dátum migrácie namiesto pôvodného dátumu.

Upresním: toto správanie nie je špecifické pre jeden nástroj. BitTitan MigrationWiz, CloudM, imapsync, GSMMO a dokonca aj manuálna IMAP kópia medzi dvomi Thunderbird klientmi produkujú rovnaký výsledok. Pôvodná hlavička Date: zostáva v správe neporušená. Práve to technicky umožňuje opravu. INTERNALDATE je však samostatná metadáta spravovaná serverom a nedá sa opraviť jednoduchou manipuláciou s hlavičkami správy na strane klienta.

Pre hlbšie pochopenie tohto mechanizmu sa pozrite na článok o IMAP INTERNALDATE a poškodených dátumoch, ktorý podrobne opisuje, ako sú tieto metadáta spravované na rôznych serveroch.

Ktoré migračné nástroje spôsobujú tento problém v Microsoft 365

Otázka sa vracia stále: spôsobujú tento problém všetky migračné nástroje?

Krátka odpoveď: závisí to od konfigurácie a cieľovej platformy. Na Exchange Online / Microsoft 365 je server obzvlášť prísny pri správe INTERNALDATE. Aj nástroje, ktoré sa ju pokúšajú zachovať, niekedy zlyhajú, pretože Graph API a EWS (Exchange Web Services) sa správajú odlišne podľa použitej metódy vkladania.

BitTitan MigrationWiz je jedným z najrozšírenejších nástrojov pre migrácie do Microsoft 365 a zároveň jedným z tých, pri ktorých sú problémy s dátumami najlepšie zdokumentované. Stránka oprava dátumov migrácie BitTitan v Microsoft 365 pokrýva špecifické konfigurácie, na ktoré treba dávať pozor. CloudM a imapsync majú vlastné zvláštnosti, zdokumentované na oprava dátumov migrácie CloudM v Microsoft 365 a oprava dátumov migrácie imapsync v Microsoft 365.

Čo je spoločné pre všetky tieto nástroje: pôvodná hlavička Date: migrácii prežíva. To je základ, na ktorom je oprava technicky možná.

Prečo je vlastný skript tu zlý nápad

Pochopenie problému niekedy vyvoláva ilúziu, že riešenie je jednoduché. Nie je, nie v produkčnom prostredí.

Úprava metadát emailov uložených na Exchange Online nie je triviálna záležitosť. Microsoft Graph API ukladá prísne limity požiadaviek (chyba 429 Too Many Requests v nočnom dávkovom spracovaní sa objaví rýchlo). Spracovanie emailov podpísaných S/MIME alebo šifrovaných PGP vyžaduje osobitnú pozornosť, aby sa neporušili digitálne podpisy. Viacúrovňové štruktúry s veľkými prílohami pridávajú obmedzenia pri sieťových timeoutoch. A hlavne: ako overíte, email po emaile, že oprava prebehla správne bez zmeny obsahu alebo príloh?

Skript, ktorý funguje dobre na 50 testovacích emailoch, sa nebude správať rovnako na schránke so 40 000 správami a 8 rokmi histórie. Pravdepodobnosť, že nejaký okrajový prípad niečo rozbije, rastie s každým ďalším tisícom správ. A bez mechanizmu návratu zanechá chyba v polovici spracovania schránku v nekonzistentnom stave.

Pozrite si tiež: oprava dátumov emailov po migrácii do Microsoft 365 pre úplný prehľad dostupných možností.

Čo Redate.io robí konkrétne

Redate.io sa pripája k Microsoft 365 tak, že sa každý používateľ prihlási vlastným kontom Microsoft, bez portálu a bez registrácie aplikácie, bezplatne naskenuje emaily s nesprávnymi dátumami a na identifikované správy aplikuje proprietárny opravný engine. Multi-etapový analytický pipeline vykonáva zhodu na stovkách signatúr známych migračných nástrojov, overenie súladu s RFC a analýzu reťazca hlavičiek na rekonštrukciu správnych dátumových metadát.

Každý opravený email je overený individuálne. Pôvodné správy zostávajú zachované v záložnom priečinku, ktorý je viditeľný vo vašej schránke, až do ich vymazania. Cenový model je jednorazová platba za poštovú schránku, bez predplatného.

Nový Outlook potom zobrazuje správne dátumy, pretože serverové dáta sú opravené, nie len maskované.

Máte dotknuté schránky v novom Outlooku? Spustite bezplatné skenovanie na Redate.io a zistite presne, koľko emailov je zasiahnutých, skôr než sa rozhodnete pre ďalší postup.