Znovu vytvořit profil Outlook: proč se mění data

Opravný zásah, který rozbije data

Uživatel si stěžuje, že se mu Outlook přestal synchronizovat. E-maily nepřicházejí, složka Odeslaná pošta se neaktualizuje, kolečko se točí donekonečna. Technik diagnostikuje poškozený profil, smaže soubor OST, vytvoří profil Outlook od nuly. Výsledek: Outlook se znovu připojí, e-maily se zobrazí, zdá se, že vše funguje.

Až do rána příštího dne, kdy uživatel otevře schránku a zjistí, že 8 let korespondence zobrazuje stejné datum: dnešní.

Je to přesně stejný příznak jako při nepovedené migraci IMAP. A ze stejných důvodů.

Co se děje technicky

Aby bylo jasné, proč znovu vytvoření profilu přináší tento výsledek, je třeba se vrátit k rozdílu, který většina techniků dobře nezná: rozdílu mezi hlavičkou Date: e-mailu a jeho INTERNALDATE v IMAP.

Každý e-mail obsahuje v hlavičkách RFC 2822 pole Date:, které udává, kdy byla zpráva odeslána. Toto pole zapíše poštovní klient odesílatele v okamžiku odeslání a pak se přenáší beze změny přes všechny servery až do Vaší schránky. Nikdy se nemění. E-mail odeslaný 14. března 2019 v 9:32 bude mít toto pole Date: vždy nedotčené, ať se potom děje cokoliv.

INTERNALDATE v IMAP je něco jiného. Jde o metadata spravovaná poštovním serverem, nezávislá na obsahu zprávy. Udává, kdy byla zpráva "uložena" do schránky. Za normálních podmínek, když e-mail dorazí přes SMTP, server zaznamená čas přijetí jako INTERNALDATE. E-mail přijatý 14. března 2019 bude mít INTERNALDATE odpovídající datu odeslání.

Outlook ve výchozím nastavení třídí a zobrazuje e-maily podle INTERNALDATE přijatého ze serveru IMAP, nikoli podle pole Date: ve zprávě samotné. (Mimochodem, pokud jste někdy otevřeli úplné vlastnosti e-mailu v Outlooku, abyste viděli jeho nezpracované hlavičky, víte, že to není zrovna čtení na pláži.)

Co způsobí smazání souboru OST

Když Outlook používá účet IMAP, udržuje lokální databázi: soubor OST (Offline Storage Table). Tento soubor je lokálním zrcadlem e-mailů uložených na serveru, včetně jejich metadat, stavů přečtení, kategorií atd.

Smazání souboru OST je totéž, jako by se vymazalo toto lokální zrcadlo. Outlook musí vše znovu stáhnout ze serveru IMAP.

Problém nastane tehdy, když Outlook při opětovném stahování zprávy přes IMAP použije příkaz FETCH k načtení obsahu. Ne vždy ale použije příkaz FETCH INTERNALDATE k načtení a zachování původního IMAP data. V některých konfiguracích a verzích Outlooku klient rekonstruuje svůj lokální index pomocí data, kdy zprávu znovu stáhl, nikoliv podle INTERNALDATE uloženého na serveru.

A v tu chvíli se u všech e-mailů ve schránce zobrazí datum dne, kdy proběhlo opětovné načtení.

Ne všechny verze Outlooku se chovají stejně

Upřesněme: toto chování nepostihuje všechny verze Outlooku stejným způsobem, a právě tady se diagnostika komplikuje.

Outlook 2016 a 2019 v režimu IMAP mají zdokumentované chování nesprávné rekonstrukce indexu po smazání mezipaměti. Nový Outlook (webový, nasazovaný postupně od konce roku 2023) zpracovává mezipaměť jinak a může přinést proměnlivé výsledky. Outlook přes Exchange/Microsoft 365 s účtem nastaveným v režimu Exchange je tomuto konkrétnímu problému méně vystaven, protože protokol MAPI/Exchange řeší synchronizaci odlišně od IMAP.

Pokud je ale Váš uživatel na IMAP účtu nakonfigurovaném v klasickém Outlooku a technik smazal soubor OST nebo znovu vytvořil profil, riziko je reálné.

Jak tento případ odlišit od skutečné migrace

IT administrátor, který po znovu vytvoření profilu dostává tikety "moje data jsou špatná", si může nesprávně myslet, že jde o problém s migrací. Tady je návod, jak oba případy rozlišit.

Případ migrace IMAP

Při migraci IMAP (BitTitan, CloudM, imapsync atd.) nástroj zkopíruje e-maily z jednoho serveru na druhý. Pro každou zkopírovanou zprávu vytvoří nový záznam na cílovém serveru. Pokud nástroj explicitně neuvede původní INTERNALDATE, cílový server zaznamená aktuální čas jako INTERNALDATE. Některé nástroje navíc přidávají hlavičku Received: s datem migrace, což situaci v některých klientech zhoršuje. Podrobnosti tohoto mechanismu najdete v článku IMAP INTERNALDATE: proč se datumy pokazí.

Případ znovu vytvoření profilu

Zde jsou e-maily stále na stejném serveru se stejnými původními INTERNALDATE. Na straně serveru se nic nezměnilo. Pouze lokální mezipaměť Outlooku byla rekonstruována s nesprávnými daty. Viditelný příznak je identický (všechny e-maily zobrazují stejné nedávné datum), ale příčina je jiná.

Pro potvrzení: přihlaste se do schránky přes webmail (Gmail, Outlook.com nebo webmailové rozhraní Vašeho poskytovatele). Jsou-li data zobrazená ve webmailu správná, jde o problém čistě lokální v Outlooku. Jsou-li data nesprávná i ve webmailu, problém je na straně serveru (migrace nebo změna INTERNALDATE přímo na serveru).

Proč původní data zůstávají obnovitelná

Dobrá zpráva: v obou případech (migrace i znovu vytvoření profilu) původní data nejsou ztracena.

Hlavička Date: RFC 2822 je nedílnou součástí zprávy. Je stejně neměnná jako tělo textu nebo přílohy. E-mail odeslaný v roce 2017 obsahuje ve svém nezpracovaném textu něco jako:

Date: Mon, 12 Jun 2017 14:23:41 +0200

Tento řádek je přítomen ve zprávě uložené na serveru. Nebyl změněn. To, co Outlook zobrazuje (nesprávně), jsou metadata vně obsahu zprávy.

A právě to opravu umožňuje. Redate.io analyzuje řetězec hlaviček každé zprávy, aby extrahoval skutečné původní datum, a poté provede cílenou opravu metadat bez zásahu do obsahu zprávy. INTERNALDATE viditelný v Outlooku je rekonstruován z této autentické informace, která je ve zprávě vždy přítomna.

Past "čistého" znovu vytvoření profilu

Právě jste vyřešili problém se synchronizací u uživatele. Jeho Outlook zase funguje, nové e-maily přicházejí. Tiket uzavřete.

O tři dny později uživatel volá znovu: hledá e-mail od dodavatele z loňského roku, ale v Outlooku všechny jeho e-maily z roku 2023 vypadají, jako by byly přijaty "včera". Nic nenachází. Automatická archivace mohla novější e-maily zařadit jako staré. A jeho nadřízený po něm chce e-mailovou konverzaci ze září 2022 kvůli sporu.

Tento scénář se opakuje pravidelně. Ne proto, že by technik odvedl špatnou práci, ale protože toto chování Outlooku není viditelně zdokumentováno ve standardních průvodcích řešením problémů.

Falešná řešení, která nepomáhají

Třídit e-maily podle "Data odeslání" místo "Data přijetí" v Outlooku je první věc, kterou uživatelé zkouší. A zdá se, že to funguje... dokud nezjistí, že třídění podle data odeslání je dostupné jen v některých složkách, zmizí při změně zobrazení a ostatní aplikace (mobilní, webmail, pravidla automatického třídění) nadále používají nesprávný INTERNALDATE.

Třídění podle data odeslání není řešení. Je to náplast, která zakrývá příznak bez zásahu do skutečného problému. Podrobně to vysvětlujeme v článku Řazení podle data odeslání není řešení.

Znovu vytvořit profil podruhé? To nic nezmění, pokud Outlook při rekonstrukci mezipaměti znovu použije aktuální datum.

Exportovat a znovu importovat jako PST? Pozor. Export PST z Outlooku se špatným datem e-mailů exportuje stejně chybné metadata. Soubor PST bude obsahovat stejně nesprávné datum. Zpětný import nic neopraví a může situaci ještě zhoršit vytvořením duplicit s nekonzistentním datem. Tímto tématem se samostatně zabývá článek Import PST v Outlooku: proč se přepíší všechna data.

Co Redate.io v tomto konkrétním případě dělá

Ať už problém pochází z migrace IMAP nebo ze znovu vytvoření profilu Outlook, výsledek na straně serveru je podobný: e-maily, jejichž metadata data jsou nekonzistentní s jejich skutečným obsahem.

Redate.io se připojí přímo k poštovní schránce (Google Workspace, Microsoft 365 nebo přímé IMAP), prohledá všechny zprávy, aby identifikoval ty s nesprávnými metadaty, a pak pro každý e-mail jednotlivě aplikuje svůj víceúrovňový analytický pipeline. Každá oprava je ověřena. Původní zprávy zůstávají ve viditelné záložní složce Vaší schránky, dokud je sami neodstraníte.

Proces zvládá okrajové případy, na které domácí skripty pravidelně nestačí: S/MIME podepsané zprávy, e-maily s non-ASCII kódováním v hlavičkách (RFC 2047), složité víceúčelové struktury, hlavičky Date: s nestandardními nebo poškozenými časovými pásmy. Skript, který správně funguje na 50 testovacích e-mailech ve vývojové schránce, může v produkčním prostředí nenávratně poškodit 2000 zpráv. Nativní rollback v IMAP neexistuje, jakmile je zpráva nahrazena bez předchozího zálohování.

Pro případy týkající se konkrétně Outlooku stránka opravy jak opravit datum ručního kopírování IMAP v Outlooku popisuje kroky pro připojení Vaší schránky a spuštění analýzy.

Jak příštímu problému předejít

Pokud jste technik nebo IT administrátor, který pravidelně zasahuje do profilů Outlooku, několik návyků Vám pomůže této situaci vyhnout.

Před smazáním souboru OST nebo znovu vytvořením profilu zkontrolujte zobrazená data ve webmailu. Jsou-li správná, zaznamenejte to do tiketu. Po znovu vytvoření se znovu přihlaste přes webmail a porovnejte data zobrazená tam s těmi v Outlooku. Pokud se liší, problém je identifikován okamžitě, ještě před tím, než si uživatel stěžuje o tři dny později.

Pro plánované migrace obsahuje checklist migrace e-mailů ověření, která je třeba provést před i po operaci, aby byl tento typ problému odhalen hned po jejím dokončení.

Znovu jste vytvořili profil Outlook a data ve Vaší schránce jsou nyní všechna špatná? Spusťte bezplatný sken na Redate.io a identifikujte postižené e-maily a opravte metadata bez zásahu do obsahu Vašich zpráv.