Import PST v Outlooku: proč se přepíší všechna data

Příznak: všechny e-maily mají datum dnešního dne

Právě jste dokončili import PST v Outlooku. Ukazatel průběhu dosáhl 100 %, vše proběhlo v pořádku. Otevřete doručenou poštu... a každý importovaný e-mail zobrazuje dnešní datum. Zpráva z roku 2019, jiná z roku 2021, archiv starý pět let: všechny nesou stejné datum. Datum dne importu.

Nejde o chybu zobrazení. Nejde o problém s časovým pásmem. Je to chování, které je zcela zdokumentované a odpovídá tomu, jak IMAP nakládá s datovými metadaty. Přesto je to katastrofa pro každého, kdo potřebuje dohledat staré e-maily podle data.

PST lokálně a IMAP: dva zcela odlišné světy

Než vysvětlíme, proč se data kazí, je třeba pochopit, co vlastně soubor PST je z pohledu správy datumů.

Soubor PST (Personal Storage Table) je proprietární formát Microsoftu. Ukládá e-maily s jejich úplnými metadaty: datum odeslání, datum přijetí, přílohy, kategorie, příznaky přečtení. Tato metadata spravuje přímo Outlook, mimo jakýkoliv poštovní protokol. Když si prohlížíte PST v Outlooku bez připojení k serveru, zobrazená data pocházejí přímo z interních polí souboru PST. Zatím žádný problém.

Potíže nastávají ve chvíli, kdy se pokusíte přenést tento obsah do poštovní schránky umístěné na IMAP serveru, ať jde o Microsoft 365, Google Workspace nebo jiného klasického poskytovatele. V tom okamžiku opouštíte svět PST a vstupujete do světa IMAP, kde platí zcela jiná pravidla.

IMAP APPEND a INTERNALDATE: jádro problému

V IMAP má každá zpráva uložená na serveru dva typy datových údajů:

• Hlavičku Date: (RFC 2822), která je součástí samotného obsahu zprávy. Je to datum, které do zprávy zapsal odesílatel.
• INTERNALDATE, což je metadata spravovaná IMAP serverem. Představuje okamžik, kdy byla zpráva na server uložena. Tuto hodnotu Outlook používá pro řazení zpráv ve sloupci "Datum přijetí".

(Mimochodem, pokud jste někdy zkoušeli číst neupravené hlavičky e-mailu, víte, že to není zrovna lehká četba. Ale právě tam se to celé odehrává.)

Když e-mail dorazí na server standardní cestou, poštovní server automaticky nastaví INTERNALDATE na přesný okamžik přijetí. Výsledek: datum zobrazené v Outlooku skutečně odpovídá tomu, kdy jste zprávu obdrželi.

Když Outlook importuje soubor PST do IMAP schránky, použije příkaz IMAP APPEND k odeslání každé zprávy na server. Standard IMAP umožňuje při příkazu APPEND explicitně předat INTERNALDATE. Outlook to ale nedělá. Zprávy odesílá bez specifikace INTERNALDATE. IMAP server pak v takovém případě uplatní své výchozí pravidlo: INTERNALDATE se nastaví na aktuální čas, tedy na okamžik importu.

Výsledek: 8 000 importovaných e-mailů, 8 000 e-mailů s dnešním datem.

Proč se Outlook chová takto

Nejde o přehlédnutí Microsoftu. Je to implementační volba, která v době vzniku pravděpodobně dávala smysl: v původním případu použití importu PST uživatel archivuje zprávy lokálně a "importuje" je do své aktuální schránky. Relevantním datem pro řazení by pak bylo původní datum přijetí... ale Microsoft se rozhodl INTERNALDATE během importu nepřenášet.

Přesněji řečeno, toto chování se týká importu PST prostřednictvím nativního průvodce Outlooku (Soubor > Otevřít a exportovat > Importovat/Exportovat). Jiné metody importu, například některé nástroje třetích stran nebo migrace přes Exchange admin centrum, se mohou chovat odlišně podle vlastní implementace příkazu IMAP APPEND.

Toto chování je na fórech Microsoftu zdokumentováno již řadu let. Nezměnilo se v Outlooku 2016, ani v Outlooku 2019, ani v aktuálních verzích Microsoft 365. Uživatel, který importuje PST dnes, narazí na naprosto stejný problém jako v roce 2015.

Čím se to liší od klasické migrace IMAP

Tady to začíná být zajímavé, protože import PST přináší výsledek podobný klasické migraci IMAP s poškozenými daty, ale mechanismem, který je jiný.

Při typické migraci IMAP, například přes BitTitan MigrationWiz nebo imapsync, putují e-maily ze zdrojového IMAP serveru na cílový. Nástroj pro migraci zprávy načte a znovu je vloží přes IMAP APPEND. Některé nástroje INTERNALDATE správně zachovají, jiné ne. V každém případě ale mají zprávy při průchodu přidanou hlavičku Received: s datem migrace, což může v Outlooku narušit zobrazení nezávisle na INTERNALDATE.

Při importu PST je mechanismus jednodušší: žádná migrační hlavička Received: se nepřidává (soubory PST neprocházejí přes mezipoštovní server), ale INTERNALDATE prostě nikdy není nastaven na správnou hodnotu. Viditelný výsledek je stejný, přičemž příčina je mírně odlišná.

Toto rozlišení má přímý dopad na způsob opravy: postup se liší podle toho, zda řešíte migraci IMAP, nebo import PST. Viz také proč INTERNALDATE způsobuje poškozená data pro podrobné vysvětlení obou případů.

Proč nastavení zobrazení v Outlooku nic nevyřeší

Typická první reakce po zjištění problému je prohledat nastavení Outlooku. A skutečně tam existuje parametr, který vypadá slibně: možnost řadit e-maily podle "Datum" místo "Datum přijetí".

Řazení podle data odeslání není řešení. Je to jen náplast.

Proč? I když změníte řazení tak, aby se zobrazoval sloupec "Datum" (který odpovídá hlavičce Date: zprávy, tedy původnímu datu), přetrvávají četné problémy:

• Outlook indexuje vyhledávání podle INTERNALDATE. Hledání "e-maily z ledna 2020" nevrátí importované zprávy z ledna 2020, protože jejich INTERNALDATE říká, že pocházejí z dne importu.
• Složky "Dnes", "Tento týden", "Tento měsíc" v rozhraní Outlooku jsou založeny na INTERNALDATE, nikoliv na hlavičce Date:.
• Ve webových rozhraních (Outlook Web App, Gmail) i na mobilních klientech závisí zobrazené datum a chování řazení téměř vždy na INTERNALDATE ze serveru.
• Pravidla a automatické filtry aplikované na datum přijetí nebudou fungovat správně.

Zkrátka, změna zobrazení vyřeší prezentaci dat pro konkrétního uživatele, na konkrétním klientovi, v konkrétní konfiguraci. Problém v jeho kořeni to nenapraví.

Ani resynchronizace OST nepomůže

Dalším klasickým pokusem je smazat cache OST a vynutit úplnou resynchronizaci ze serveru. Idea spočívá v tom, že problém možná pochází z lokální cache Outlooku, nikoliv ze serveru.

Špatná stopa. Soubor OST je lokální cache, která odráží stav IMAP serveru. Pokud je INTERNALDATE na serveru chybný, bude chybný i v OST po resynchronizaci. Smazání OST nijak nezmění data uložená na serveru Exchange Online nebo Google Workspace. Server je autoritou.

Jediný způsob, jak data opravit, je opravit metadata přímo na straně serveru, zprávu po zprávě. A právě tady se ruční oprava stává komplikovanou záležitostí.

Problém rozsahu: 1 e-mail je triviální. 15 000 je jiná věc

Technicky vzato, kdo problém pochopí, mohl by napsat skript, který projde schránku, přečte hlavičku Date: každé zprávy a příslušně opraví INTERNALDATE. Pochopit problém je jedna věc. Opravit 15 000 e-mailů bez ztráty jediného je věc zcela jiná.

Několik reálných faktů:

• Rozhraní Microsoft Graph API i Gmail API mají omezení počtu požadavků (rate limits). Naivní skript vyvolá chyby 429 Too Many Requests, přeruší se uprostřed opravy a zanechá Vám částečně opravenou schránku, přičemž nevíte, které e-maily byly zpracovány a které ne.
• Některé e-maily v PST mohou mít chybně formátované nebo chybějící hlavičky Date:. Skript bez ošetření těchto okrajových případů může takové zprávy poškodit nebo je tiše přeskočit.
• Podepsané e-maily (S/MIME) nebo šifrované zprávy (PGP) mají dodatečná omezení integrity. Nedbalá úprava jejich metadat může zneplatnit kryptografický podpis.
• Struktury multipart/alternative se složitými MIME hranicemi reagují na modifikační operace někdy nepředvídatelně.
• Žádný mechanismus rollbacku. Když se něco pokazí uprostřed zpracování, jak se vrátíte do původního stavu?

Skript, který funguje na 10 testovacích e-mailech, nebude fungovat v produkční schránce s 50 000 zprávami. Loni měl jeden klient PST archiv o velikosti 40 GB a pokusil se to opravit Pythonovým skriptem staženým ze Stack Overflow. Výsledek: 3 000 duplikátů e-mailů, 200 zpráv s nepřístupnými přílohami a dva týdny ručního čištění.

Co v takovém případě dělá Redate.io

Redate.io analyzuje metadata každé zprávy v cílové schránce, identifikuje e-maily s nesprávnými daty (včetně těch pocházejících z importu PST) a provede opravu prostřednictvím svého proprietárního korekčního systému. Víceúrovňový analytický pipeline porovnává řetězec hlaviček každé zprávy, extrahuje původní datum s validací shody RFC a provede cílenou opravu metadat bez jakékoliv změny obsahu zprávy.

Každý opravený e-mail je ověřen individuálně. Originály jsou uchovány ve viditelné záložní složce po dobu 30 dní před jakoukoli trvalou změnou. Oprava funguje na třech hlavních platformách: Microsoft 365 (přes Azure AD), Google Workspace (přes delegování domény) a přímý IMAP pro klasické poskytovatele.

Úvodní skenování je zdarma. Umožní Vám vidět přesně, kolik e-mailů je zasaženo a jaké je rozložení nesprávných dat, ještě než se rozhodnete cokoliv podniknout.

Viz také:

• Oprava datumů e-mailů po migraci Microsoft 365
• Outlook: datum migrace IMAP vs datum odeslání
• Lze opravit data e-mailů po migraci?

Import PST přepsal všechna data Vašich e-mailů? Naskenujte svou schránku zdarma na Redate.io a změřte rozsah problému dříve, než začnete jednat.