Obnova profilu Outlook: prečo sa menia dátumy

Bežný zásah, ktorý pokazí dátumy

Používateľ sa sťažuje, že Outlook sa prestál synchronizovať. Emaily neprichádzajú, priečinok Odoslaná pošta sa neaktualizuje, koliesko sa točí donekonečna. Technik diagnostikuje poškodený profil, vymaže súbor OST a vytvorí profil Outlook od nuly. Výsledok: Outlook sa znova pripojí, emaily sa zobrazia, všetko funguje.

Až na druhý deň ráno, keď používateľ otvorí schránku a zistí, že 8 rokov korešpondencie zobrazuje rovnaký dátum: dnešok.

Je to presne ten istý príznak ako po neúspešnej IMAP migrácii. A z rovnakých dôvodov.

Čo sa deje technicky

Aby sme pochopili, prečo obnova profilu vedie k tomuto výsledku, treba sa vrátiť k rozdielu, ktorý väčšina technikov dobre nepozná: rozdiel medzi hlavičkou Date: emailu a jeho INTERNALDATE v IMAP.

Každý email obsahuje v RFC 2822 hlavičkách pole Date:, ktoré uvádza, kedy bola správa odoslaná. Toto pole zapisuje poštový klient odosielateľa v čase odoslania a potom sa prenáša cez všetky servery až do vašej schránky bez zmeny. Nikdy sa nemení. Email odoslaný 14. marca 2019 o 09:32 bude mať toto pole Date: vždy neporušené, bez ohľadu na to, čo sa stane neskôr.

INTERNALDATE IMAP je niečo iné. Je to metadáta spravovaná poštovým serverom, nezávislá od obsahu správy. Udáva, kedy bola správa "uložená" do schránky. Za normálnych podmienok, keď email príde cez SMTP, server zaznamená čas doručenia ako INTERNALDATE. Email prijatý 14. marca 2019 bude mať teda INTERNALDATE zodpovedajúci dátumu odoslania.

Outlook predvolene triedi a zobrazuje emaily podľa INTERNALDATE prenášaného IMAP serverom, nie podľa poľa Date: samotnej správy. (Ak ste niekedy otvorili úplné vlastnosti emailu v Outlooku, aby ste videli surové hlavičky, viete, že to nie je práve oddychové čítanie.)

Čo spustí vymazanie súboru OST

Keď Outlook používa IMAP účet, udržiava lokálnu databázu: súbor OST (Offline Storage Table). Tento súbor je lokálnym zrkadlom emailov uložených na serveri, vrátane ich metadát, stavov prečítania, kategórií atď.

Vymazanie súboru OST je ako vymazanie tohto lokálneho zrkadla. Outlook musí znova stiahnuť všetko zo servera IMAP.

Problém? Keď Outlook opätovne stiahne správu cez IMAP, použije príkaz FETCH na načítanie obsahu. Ale nie vždy použije príkaz FETCH INTERNALDATE na získanie a zachovanie pôvodného IMAP dátumu. V niektorých konfiguráciách a verziách Outlooku klient rekonštruuje lokálny index s použitím dátumu, kedy správu znova stiahol, namiesto INTERNALDATE uloženého na serveri.

A tak sa všetky emaily v schránke ocitnú datované dňom opätovného načítania.

Nie všetky verzie Outlooku sa správajú rovnako

Vlastne, toto správanie sa netýka všetkých verzií Outlooku rovnako, a práve tu je diagnostika náročná.

Outlook 2016 a 2019 v IMAP režime majú zdokumentované správanie nesprávnej rekonštrukcie indexu po vymazaní vyrovnávacej pamäte. Nový Outlook (webový, postupne nasadzovaný od konca roka 2023) spravuje cache inak a môže produkovať premenlivé výsledky. Outlook cez Exchange/Microsoft 365 s účtom nakonfigurovaným v Exchange režime je menej vystavený tomuto špecifickému problému, pretože protokol MAPI/Exchange spravuje synchronizáciu inak ako IMAP.

Ale ak je váš používateľ na IMAP účte nakonfigurovanom v klasickom Outlooku a technik vymazal súbor OST alebo obnovil profil: riziko je reálne.

Ako odlíšiť tento prípad od skutočnej migrácie

IT admin, ktorý dostáva tikety "moje dátumy sú zlé" po obnove profilu, môže mylne myslieť na problém s migráciou. Tu je návod, ako oba prípady rozlíšiť.

Prípad IMAP migrácie

Pri IMAP migrácii (BitTitan, CloudM, imapsync atď.) migračný nástroj kopíruje emaily z jedného servera na druhý. Pre každú skopírovanú správu vytvorí novú položku na cieľovom serveri. Ak nástroj pri tom explicitne nešpecifikuje pôvodný INTERNALDATE, cieľový server zaznamená aktuálny čas ako INTERNALDATE. Niektoré nástroje navyše pridávajú hlavičku Received: s dátumom migrácie, čo v niektorých klientoch problém ešte zhoršuje. Detail tohto mechanizmu nájdete v článku o IMAP INTERNALDATE a poškodených dátumoch.

Prípad obnovy profilu

Tu sú emaily stále na tom istom serveri s rovnakými pôvodnými INTERNALDATE. Na strane servera sa nič nepohlo. Iba lokálna vyrovnávacia pamäť Outlooku bola rekonštruovaná s nesprávnymi dátumami. Viditeľný príznak je rovnaký (všetky emaily zobrazujú rovnaký nedávny dátum), ale príčina je iná.

Ako to overiť: prihláste sa do schránky cez webmail (Gmail, Outlook.com alebo webmail rozhranie vášho poskytovateľa). Ak sú dátumy zobrazené vo webmaile správne, problém je čisto lokálny pre Outlook. Ak sú dátumy nesprávne aj vo webmaile, problém je na strane servera (migrácia alebo zmena INTERNALDATE priamo na serveri).

Prečo pôvodné dátumy zostávajú obnoviteľné

Dobrá správa: v oboch prípadoch (migrácia alebo obnova profilu) pôvodné dátumy nie sú stratené.

Hlavička Date: RFC 2822 je neoddeliteľnou súčasťou správy. Je rovnako nemenná ako telo textu alebo prílohy. Email odoslaný v roku 2017 obsahuje v surových dátach niečo takéto:

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

Tento riadok je prítomný v správe uloženej na serveri. Nebol zmenený. To, čo Outlook zobrazuje (nesprávne), sú metadáta vonkajšie voči obsahu správy.

Práve to umožňuje opravu. Engine Redate.io analyzuje reťazec hlavičiek každej správy, aby extrahoval skutočný pôvodný dátum, a potom vykoná cielenú korekciu metadát bez zmeny obsahu správy. INTERNALDATE viditeľný Outlookom je rekonštruovaný z tejto autentickej informácie, ktorá je vždy prítomná v správe.

Pasca "čistej" obnovy

Práve ste vyriešili problém so synchronizáciou pre používateľa. Jeho Outlook funguje, nové emaily prichádzajú. Zatvoríte tiket.

O tri dni neskôr používateľ volá znova: hľadá email od dodávateľa z minulého roka, ale v Outlooku sa všetky jeho emaily z roku 2023 zobrazujú ako prijaté "včera". Nič nenachádza. Automatická archivácia možno klasifikovala nedávne emaily ako staré. A jeho nadriadený žiada emailovú konverzáciu zo septembra 2022 pre právny spor.

Tento scenár sa stáva pravidelne. Nie preto, že by technik zle odviedol svoju prácu, ale preto, že toto správanie Outlooku nie je viditeľne zdokumentované v štandardných príručkách odstraňovania problémov.

Falošné riešenia, ktoré nič neriešia

Triedenie emailov podľa "Dátumu odoslania" namiesto "Dátumu prijatia" v Outlooku je prvá vec, ktorú používatelia skúšajú. A zdá sa, že to funguje... kým nezistia, že triedenie podľa dátumu odoslania je dostupné len pre niektoré priečinky, zmizne pri zmene zobrazenia a iné aplikácie (mobilná, webmail, pravidlá automatického triedenia) naďalej používajú nesprávny INTERNALDATE.

Triedenie podľa dátumu odoslania nie je riešenie. Je to náplasť, ktorá skrýva príznak bez toho, aby sa dotkla skutočného problému. Podrobnejšie to vysvetľujeme v článku Triedenie podľa dátumu odoslania nestačí.

Obnoviť profil druhýkrát? To nič nemení, ak Outlook pri obnove cache používa aktuálny dátum.

Exportovať a znova importovať cez PST? Pozor. Export PST z Outlooku s poškodenými dátumami exportuje poškodené metadáta. Súbor PST bude obsahovať zlé dátumy. Opätovný import tento súbor neopraví a môže situáciu dokonca zhoršiť tvorením duplicitov s nekonzistentnými dátumami. Táto téma je podrobne spracovaná v článku o importe PST a dátumoch, ktoré skončia na deň importu.

Čo robí Redate.io v tomto konkrétnom prípade

Či problém pochádza z IMAP migrácie alebo obnovy profilu Outlook, výsledok na strane servera je podobný: emaily, ktorých metadáta dátumu sú nekonzistentné s ich skutočným obsahom.

Redate.io sa pripojí priamo k poštovej schránke (Google Workspace, Microsoft 365 alebo priamy IMAP), prehľadá všetky správy, aby identifikoval tie s nesprávnymi metadátami, a potom aplikuje viacstupňový analytický pipeline na opravu každého emailu jednotlivo. Každá oprava je overená. Redate.io nikdy nevymaže pôvodné správy. Zostávajú vo viditeľnom záložnom priečinku vo vašej schránke, kým ich nevymažete sami.

Proces zvláda hraničné prípady, na ktorých domáce skripty systematicky zlyhávajú: S/MIME podpísané správy, emaily s non-ASCII kódovaním v hlavičkách (RFC 2047), komplexné multipart štruktúry, hlavičky Date: s neštandardnými alebo poškodeným časovými pásmami. Skript, ktorý správne funguje na 50 testovacích emailoch vo vývojovej schránke, môže nevratne poškodiť 2 000 správ v produkcii. V IMAP neexistuje natívny rollback, keď je správa nahradená bez predchádzajúcej zálohy.

Pre prípady súvisiace konkrétne s Outlookom stránka oprava dátumov manuálnej kópie IMAP v Outlooku podrobne popisuje kroky na pripojenie schránky a spustenie analýzy.

Ako predísť problému pri budúcich zásahoch

Ak ste technik alebo IT admin a pravidelne zasahujete do profilov Outlook, niekoľko reflexov vám pomôže tejto situácii predísť.

Pred vymazaním súboru OST alebo obnovením profilu skontrolujte dátumy zobrazené vo webmaile. Ak sú správne, poznačte to do tiketu. Po obnove sa znova prihláste do webmailu a porovnajte zobrazené dátumy s tými v Outlooku. Ak sa objaví rozdiel, problém je identifikovaný okamžite, ešte predtým, ako sa naň používateľ sťažuje o tri dni neskôr.

Pre plánované migrácie checklist migrácie emailov uvádza overenia, ktoré treba vykonať pred aj po, aby ste tento typ problému zachytili hneď po skončení operácie.

Obnovili ste profil Outlook a dátumy vo vašej schránke sú teraz všetky zlé? Spustite bezplatný scan na Redate.io a identifikujte postihnuté emaily a opravte metadáta bez zmeny obsahu vašich správ.