Nový Outlook: špatné datum po migraci, skutečné příčiny

Dva Outlooku, dva odlišné přístupy ke stejným e-mailům

Migrovali jste schránky do Microsoft 365 a někteří uživatelé si stěžují, že všechny starší e-maily zobrazují stejné datum (datum migrace)? Možná jste si všimli něčeho zvláštního: uživatelé klasického Outlooku vidí v podokně čtení správné datum, zatímco ti na novém Outlooku pro Windows vidí bez výjimky datum migrace. Stejná schránka. Stejné e-maily. Různé výsledky.

Nejde o chybu v pravém slova smyslu. Je to architektonické rozhodnutí, které má přímý dopad na zobrazování dat po migraci pomocí IMAP. Abyste pochopili, co se děje, musíte se ponořit do detailů e-mailových hlaviček a protokolu IMAP, což není zrovna oddychové čtení, ale vysvětlí vám to, proč žádná manipulace na straně klienta nestačí problém vyřešit.

IMAP INTERNALDATE: skutečný viník

Když je e-mail uložen na IMAP serveru, existují dva typy dat, která koexistují a navzájem se nepletou.

První je hlavička Date:, definovaná normou RFC 2822. Jde o datum zapsané přímo ve zprávě, které odesílatel nastavil při odeslání e-mailu. Je součástí těla zprávy a nikdy se nemění, bez ohledu na to, kudy e-mail putoval.

Druhé je INTERNALDATE, metadata spravovaná IMAP serverem, nezávislá na obsahu zprávy. Je to datum, kdy server zprávu zaznamenal. Při standardní migraci seriózní nástroje původní INTERNALDATE zachovají. Při špatně nakonfigurované migraci nebo s nástroji, které tato metadata nezvládají správně, se INTERNALDATE resetuje na aktuální datum migrace. Výsledek: všechny migrované e-maily nesou z pohledu serveru stejné datum přijetí.

(Mimochodem, pokud jste někdy četli logy imapsync nebo MigrationWiz, víte, že existují specifické volby pro zachování INTERNALDATE. Ne vždy fungují a některé cílové servery je jednoduše neuznají.)

Klasický Outlook: jak čte data

Klasický Outlook, tedy COM verze instalované lokálně (Outlook 2016, 2019, 2021 a desktopový klient Microsoft 365 Apps), používá poněkud složitější mechanismus pro určení, jaké datum zobrazit v seznamu zpráv.

U e-mailů v složce Odeslaná pošta se opírá o hlavičku Date:. U přijatých e-mailů preferuje INTERNALDATE ze serveru, ale v určitých kontextech (zejména když je zapojena mezipaměť OST nebo při prvním zobrazení v podokně čtení) může také číst řetěz hlaviček Received: a z nich přibližně rekonstruovat původní datum.

Právě proto pozorujeme toto nekonzistentní chování: klasický Outlook může někdy zobrazit správné datum v podokně čtení, protože pro podrobný náhled čte původní hlavičku Date: zprávy, i když samotný seznam e-mailů používá poškozenou INTERNALDATE. Pozor ale - není to spolehlivé a nic to neopravuje. Řazení zůstává rozbité, vyhledávání podle data zůstává nepřesné.

Nový Outlook: radikálně odlišná architektura

Nový Outlook pro Windows, postupně nasazovaný od konce roku 2023, již není COM aplikace. Jde v podstatě o Progressive Web App (PWA) postavenou na stejném kódu jako Outlook na webu (OWA). Tato přestavba má zásadní důsledky.

Nový Outlook zcela deleguje zobrazování dat na rozhraní Microsoft 365 API. Nečte hlavičky Received:, nezachází do řetězu hlaviček, aby nalezl původní datum, a neprovádí žádnou rekonstrukci na straně klienta. Jednoduše zobrazuje to, co mu vrátí server: INTERNALDATE.

Výsledek: pokud byla INTERNALDATE při migraci poškozena, nový Outlook váhá? Ne. Zobrazí datum migrace u každého dotčeného e-mailu, bez výjimky a bez odstínů. Jde o konzistentnější a předvídatelnější chování než u klasického Outlooku, ale problém migrace je okamžitě viditelný a nelze ho přehlédnout.

Správce, který v pátek večer migruje 300 schránek, zjistí v pondělí ráno, že všichni uživatelé na novém Outlooku vidí celé archivy datované minulým víkendem. Tikety přicházejí rychle.

Proč žádné obejití na straně klienta nefunguje

Mnoho správců zkouší řešení na straně klienta dříve, než pochopí, že problém leží v datech na serveru. Zde jsou klasické pokusy a proč selhávají.

Řazení podle "Data odeslání" místo "Data přijetí"

Řazení podle data odeslání v Outlooku využívá hlavičku Date: zprávy, která je neporušená. Ano, toto řazení může fungovat. Je to ale náplast, ne řešení. Vyhledávání podle data zůstává rozbité. Pravidla založená na datu zůstávají nepoužitelná. A hlavně: uživatel musí ručně překonfigurovat každou složku, každou schránku. U 300 schránek je to nereálné. Řazení podle data odeslání není řešení a koncoví uživatelé nerozumí, proč po nich někdo chce měnit zavedené zvyklosti.

Vymazání mezipaměti Outlooku nebo opětovné vytvoření profilu

To se INTERNALDATE na straně serveru nijak nedotkne. Po opětovném vytvoření profilu Outlook znovu synchronizuje e-maily ze serveru a načte přesně stejná poškozená metadata. Mezipaměť problémem není.

Použití OWA místo Outlooku

OWA a nový Outlook sdílejí stejnou databázi. Pokud je INTERNALDATE na serveru Exchange Online poškozena, OWA zobrazí přesně stejné špatné datum. Změna klienta data nezmění.

Problém leží na serveru, v metadatech každé zprávy. Žádná akce na straně klienta nedokáže opravit datum uložené na straně serveru.

Past hlaviček Received: proč vše komplikují

Když migrační nástroj zkopíruje e-mail z jednoho serveru na druhý přes IMAP, cílový server automaticky přidá hlavičku Received: na začátek řetězu s datem a časem vložení. Jde o standardní chování SMTP a IMAP serverů v souladu s RFC.

Tyto hlavičky se hromadí v opačném pořadí, než jakou cestou e-mail prošel. Nejnovější je nahoře. Některé e-mailové klienty čtou první Received: pro odhadnutí data přijetí, což dává datum migrace namísto původního data.

Upřesnění: toto chování není vlastní jedinému nástroji. BitTitan MigrationWiz, CloudM, imapsync, GSMMO, dokonce i ruční kopírování IMAP mezi dvěma klienty Thunderbird - všechny produkují stejný výsledek. Původní hlavička Date: ve zprávě zůstává neporušena. Právě to technicky umožňuje opravu. Ale INTERNALDATE je odlišné metadata spravované serverem a nelze ho opravit pouhým upravováním hlaviček zprávy na straně klienta.

Pro hlubší pochopení tohoto mechanismu článek o IMAP INTERNALDATE a poškozených datech podrobně popisuje, jak jsou tato metadata spravována na různých serverech.

Které migrační nástroje způsobují tento problém v Microsoft 365

Otázka se vrací opakovaně: způsobují tento problém všechny migrační nástroje?

Krátká odpověď je, že záleží na konfiguraci a cílové platformě. Exchange Online / Microsoft 365 je zvláště přísný ohledně správy INTERNALDATE. Dokonce i nástroje, které se ji snaží zachovat, někdy selhávají, protože Graph API a EWS (Exchange Web Services) se chovají odlišně podle použité metody vkládání.

BitTitan MigrationWiz patří mezi nejrozšířenější nástroje pro migrace do Microsoft 365 a zároveň je jedním z těch, jejichž problémy s daty jsou nejlépe zdokumentovány. Stránka jak opravit datum po migraci BitTitan v Microsoft 365 pokrývá konkrétní konfigurace, na které si dát pozor. CloudM a imapsync mají svá vlastní specifika, zdokumentovaná na jak opravit datum po migraci CloudM v Microsoft 365 a jak opravit datum po migraci imapsync v Microsoft 365.

Co mají všechny tyto nástroje společné: původní hlavička Date: migraci přežije. To je základ, na němž je oprava možná.

Proč je vlastní skript v tomto případě špatný nápad

Pochopení problému někdy vyvolává iluzi, že řešení je jednoduché. Není, ne v produkčním měřítku.

Úprava metadat e-mailů uložených na Exchange Online není triviální záležitost. Microsoft Graph API ukládá přísné limity frekvence požadavků (chyba 429 Too Many Requests v nočním dávkovém zpracování přijde rychle). Práce s e-maily podepsanými S/MIME nebo šifrovanými PGP vyžaduje zvláštní péči, aby nedošlo k zneplatnění podpisů. Víceúrovňové struktury s velkými přílohami přidávají omezení ohledně síťových časových limitů. A především: jak ověříte, e-mail po e-mailu, že oprava proběhla správně bez změny obsahu nebo příloh?

Skript, který funguje na 50 testovacích e-mailech, se nebude chovat stejně na schránce se 40 000 zprávami s 8 lety historie. Pravděpodobnost, že okrajový případ něco rozbije, roste s každým dalším tisícem zpráv. A bez mechanismu pro vrácení změn zanechá chyba v půli cesty schránku v nekonzistentním stavu.

Viz také: jak opravit datum e-mailů po migraci Microsoft 365 pro úplný přehled dostupných možností.

Co Redate.io konkrétně dělá

Redate.io se připojí k Microsoft 365 tak, že se uživatel přihlásí svým účtem Microsoft (bezpečná delegace přístupu, bez ukládání hesel), bezplatně naskenuje e-maily s nesprávnými daty a poté aplikuje proprietární opravný engine na identifikované zprávy. Víceúrovňový analytický pipeline provádí shodu se stovkami signatur známých migračních nástrojů, validaci souladu s RFC a analýzu řetězu hlaviček pro rekonstrukci správných datových metadat.

Každý opravený e-mail je ověřen individuálně. Původní zprávy jsou uchovávány v viditelné zálohovací složce, dokud je sami neodstraníte. Cenový model je jednorázová platba za schránku, bez předplatného.

Nový Outlook pak u e-mailů zobrazuje správné datum, protože je datum opraveno na serveru, ne maskováno.

Máte schránky zasažené na novém Outlooku? Spusťte bezplatný sken na Redate.io a zjistěte přesně, kolik e-mailů je dotčeno, než se rozhodnete pro další postup.