Import PST v Outlooku: prečo všetky dátumy skončia na deň importu

Príznak: všetky emaily majú dnešný dátum

Práve ste dokončili import PST v Outlooku. Ukazovateľ priebehu dosiahol 100 %, všetko prebehlo hladko. Potom otvoríte doručenú poštu... a každý importovaný email zobrazuje dnešný dátum. Správa z roku 2019, ďalšia z roku 2021, archív starý päť rokov: všetky nesú rovnaký dátum. Ten z dňa importu.

Nie je to chyba zobrazenia. Nie je to problém s časovým pásmom. Je to správanie perfektne zdokumentované a konzistentné s tým, ako IMAP spravuje metadáta dátumov. Ale pre každého, kto potrebuje nájsť staré emaily podľa dátumu, je to katastrofa.

Lokálny PST a IMAP: dva veľmi odlišné svety

Predtým, než vysvetlíme, prečo sa dátumy pokazia, treba pochopiť, čo je súbor PST z pohľadu správy dátumov.

Súbor PST (Personal Storage Table) je proprietárny formát Microsoftu. Uchováva emaily spolu s ich úplnými metadátami: dátum odoslania, dátum prijatia, prílohy, kategórie, príznaky prečítania. Tieto metadáta spravuje priamo Outlook, mimo akéhokoľvek poštového protokolu. Keď prehliadate PST v Outlooku bez pripojenia k serveru, zobrazované dátumy pochádzajú priamo z interných polí súboru PST. Zatiaľ všetko v poriadku.

Problém nastáva, keď sa pokúsite preniesť tento obsah do poštovej schránky uloženej na IMAP serveri, či už ide o Microsoft 365, Google Workspace alebo akéhokoľvek klasického hostiteľa. V tom momente opúšťate svet PST a vstupujete do sveta IMAP, kde sa pravidlá radikálne menia.

IMAP APPEND a INTERNALDATE: jadro problému

V IMAP má každá správa uložená na serveri dva typy dátumových údajov:

• Hlavička Date: (RFC 2822), ktorá je súčasťou samotného obsahu správy. Je to dátum, ktorý odosielateľ zapísal do správy.
• INTERNALDATE, čo je metadátum spravované IMAP serverom. Reprezentuje okamih, keď bola správa uložená na server. Práve túto hodnotu Outlook používa na triedenie správ v zobrazení "Dátum prijatia".

(Mimochodom, ak ste niekedy skúšali čítať surové hlavičky emailu, viete, že to nie je presne plážové čítanie. Ale práve tam sa všetko odohráva.)

Keď email dorazí na server normálnym spôsobom, poštový server automaticky nastaví INTERNALDATE na presný okamih prijatia. Výsledok: dátum zobrazený v Outlooku skutočne zodpovedá tomu, kedy ste správu dostali.

Keď Outlook importuje súbor PST do IMAP schránky, používa príkaz IMAP APPEND na odoslanie každej správy na server. Štandard IMAP umožňuje pri APPEND odovzdať explicitný INTERNALDATE. Outlook to však nerobí. Odosiela správy bez uvedenia INTERNALDATE. IMAP server, keď nedostane žiadnu inštrukciu, použije svoj predvolený postup: INTERNALDATE nastaví na aktuálny čas, teda na okamih importu.

Výsledok: 8 000 importovaných emailov, 8 000 emailov s dnešným dátumom.

Prečo sa Outlook takto správa

Nejde o opomenutie Microsoftu. Je to implementačné rozhodnutie, ktoré v dobe vzniku pravdepodobne dávalo zmysel: v pôvodnom použití importu PST si používateľ archivuje správy lokálne a "importuje" ich do aktuálnej schránky. Relevantný dátum pre triedenie by bol pôvodný dátum prijatia... ale Microsoft sa rozhodol pri operácii importu INTERNALDATE neprenášať.

Pre presnosť treba povedať, že toto správanie sa týka importu PST cez natívneho sprievodcu Outlooku (Súbor > Otvoriť a exportovať > Import/Export). Iné metódy importu, napríklad niektoré nástroje tretích strán alebo migrácie cez Exchange Admin Center, sa môžu správať inak v závislosti od ich implementácie IMAP APPEND.

Toto správanie je známe a zdokumentované na fórach Microsoftu už roky. Nezmenilo sa ani s Outlookom 2016, ani s Outlookom 2019, ani s aktuálnymi verziami Microsoft 365. Používateľ, ktorý dnes importuje PST, narazí presne na ten istý problém ako v roku 2015.

Čím sa to líši od klasickej IMAP migrácie

Práve tu to začína byť zaujímavé, pretože import PST produkuje podobný výsledok ako klasická IMAP migrácia s poškodenými dátumami, ale iným mechanizmom.

Pri typickej IMAP migrácii, napríklad cez BitTitan MigrationWiz alebo imapsync, prechádzajú emaily zo zdrojového IMAP servera na cieľový IMAP server. Migračný nástroj stiahne správy a znovu ich vloží cez IMAP APPEND. Niektoré nástroje správne zachovávajú INTERNALDATE, iné nie. V každom prípade majú správy pri prechode pridanú hlavičku Received: s dátumom migrácie, čo môže narušiť zobrazenie v Outlooku nezávisle od INTERNALDATE.

Pri importe PST je mechanizmus jednoduchší: nepridáva sa žiadna migračná hlavička Received: (súbory PST neprechádzajú cez sprostredkovateľský poštový server), ale INTERNALDATE jednoducho nikdy nie je nastavený na správnu hodnotu. Viditeľný výsledok je rovnaký, ale základná príčina je mierne odlišná.

Tento rozdiel má priamy dopad na opravu: postup nie je úplne rovnaký pri IMAP migrácii a pri importe PST. Pozrite si tiež prečo INTERNALDATE spôsobuje poškodené dátumy pre podrobné vysvetlenie oboch prípadov.

Prečo možnosti zobrazenia Outlooku nič neopravujú

Bežná reakcia po objavení problému je prehrabávanie sa v nastaveniach Outlooku. A skutočne tam existuje parameter, ktorý vyzerá sľubne: možnosť triediť emaily podľa "Dátumu" namiesto "Dátumu prijatia".

Triedenie podľa dátumu odoslania nie je riešenie. Je to len náplasť.

Prečo: aj keď zmeníte triedenie tak, aby sa zobrazoval stĺpec "Dátum" (ktorý zodpovedá hlavičke Date: správy, teda pôvodnému dátumu), niekoľko problémov pretrváva:

• Vyhľadávanie v Outlooku indexuje podľa INTERNALDATE. Vyhľadávanie "emaily z januára 2020" nevráti importované emaily z januára 2020, pretože ich INTERNALDATE hovorí, že pochádzajú z dňa importu.
• Priečinky "Dnes", "Tento týždeň", "Tento mesiac" v rozhraní Outlooku sú založené na INTERNALDATE, nie na hlavičke Date:.
• Vo webových rozhraniach (Outlook Web App, Gmail) a na mobilných klientoch závisí zobrazený dátum a správanie pri triedení takmer vždy od INTERNALDATE na serveri.
• Pravidlá a automatické filtre aplikované na dátum prijatia nebudú fungovať správne.

Jednoducho povedané, zmena zobrazenia rieši len to, čo vidí konkrétny používateľ na konkrétnom klientovi v konkrétnej konfigurácii. Problém pri zdroji to neopraví.

Resynchronizácia OST tiež nepomôže

Ďalší klasický pokus: vymazať cache OST a vynútiť úplnú resynchronizáciu zo servera. Myšlienka je, že problém možno pochádza z lokálnej cache Outlooku, nie zo servera.

Slepá ulička. Súbor OST je lokálna cache, ktorá odráža stav IMAP servera. Ak je INTERNALDATE na serveri nesprávny, bude nesprávny aj v OST po resynchronizácii. Vymazanie OST nič nemení na dátach uložených na serveri Exchange Online alebo Google Workspace. Server je autoritou.

Jediný spôsob, ako opraviť dátumy, je opraviť metadáta priamo na strane servera, správu po správe. A práve tu začína byť manuálne riešenie problematické.

Problém rozsahu: 1 email je triviálny. 15 000 je iný príbeh

Technicky, ak niekto pochopí problém, mohol by napísať skript, ktorý prejde schránku, prečíta hlavičku Date: každej správy a podľa toho opraví INTERNALDATE. Pochopiť problém je jedna vec. Opraviť 15 000 emailov bez straty jediného je vec celkom iná.

Niekoľko praktických realít:

• Microsoft Graph API aj Gmail API majú limity počtu požiadaviek (rate limits). Naivný skript vyvolá chyby 429 Too Many Requests, preruší svoju činnosť uprostred opravy a zanechá vám čiastočne opravenú schránku bez toho, aby ste vedeli, ktoré emaily boli spracované a ktoré nie.
• Niektoré emaily v PST môžu mať deformované alebo chýbajúce hlavičky Date:. Skript bez obsluhy týchto hraničných prípadov môže tieto správy poškodiť alebo potichu preskočiť.
• Podpísané emaily (S/MIME) alebo šifrované (PGP) majú dodatočné obmedzenia integrity. Úprava ich metadát bez opatrnosti môže zneplatniť kryptografický podpis.
• Štruktúry multipart/alternative so zložitými MIME hranicami niekedy reagujú nepredvídateľne na modifikačné operácie.
• Žiadny mechanizmus na vrátenie zmien. Ak sa niečo pokazí uprostred spracovania, ako sa vrátiť do pôvodného stavu?

Skript, ktorý funguje na 10 testovacích emailoch, nebude fungovať na produkčnej schránke s 50 000 správami. Minulý rok mal zákazník PST archív veľký 40 GB a pokúsil sa to opraviť Pythonovým skriptom stiahnutým zo Stack Overflow. Výsledok: 3 000 emailov v duplikáte, 200 správ s nedostupnými prílohami a dva týždne manuálneho upratovania.

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

Redate.io analyzuje metadáta každej správy v cieľovej schránke, identifikuje emaily s nesprávnymi dátumami (vrátane tých pochádzajúcich z importu PST) a aplikuje opravu cez svoj proprietárny opravný engine. Viacstupňový analytický pipeline porovnáva reťazec hlavičiek každej správy, extrahuje pôvodný dátum s validáciou zhody RFC a vykoná cielenú opravu metadát bez zmeny obsahu správy.

Každý opravený email je overený individuálne. Originály sú po dobu 30 dní uchovávané vo viditeľnom záložnom priečinku pred akoukoľvek definitívnou zmenou. Oprava funguje na troch hlavných platformách: Microsoft 365 (cez Azure AD), Google Workspace (cez delegovanie domény) a priamo IMAP pre klasických hostiteľov.

Úvodný sken je bezplatný. Umožní presne vidieť, koľko emailov je postihnutých a aké je rozloženie nesprávnych dátumov, pred tým, než sa rozhodnete čokoľvek podniknúť.

Pozrite si tiež:

• Dátumy emailov po migrácii do Microsoft 365
• Outlook: dátum prijatia IMAP vs dátum odoslania
• Ako opraviť dátumy emailov po migrácii

Import PST prepísal všetky dátumy vašich emailov? Naskenujte svoju schránku bezplatne na Redate.io a zistite rozsah problému pred tým, než začnete konať.