eM Client: chybná data po importu PST nebo Thunderbird

Příznak: všechny e-maily nesou stejné datum

Právě jste dokončili import PST do eM Clientu, nebo jste přešli z Thunderbirdu do nové schránky. Import proběhl zdánlivě bez chyb. Ale při otevření doručené pošty něco nesedí: stovky, někdy tisíce e-mailů zobrazují stejné datum, datum dne importu. E-mail z roku 2019 vypadá, jako by dorazil včera. Smlouva podepsaná před třemi lety se tváří, jako by právě přišla.

Přirozená první reakce je vinit eM Client. Špatné nastavení, špatný sloupec řazení, chyba zobrazení... Hledáte v předvolbách. Přepínáte mezi "Datem přijetí" a "Datem odeslání". Nic se nemění. Přesněji řečeno, něco se změní, ale podstata problému zůstává.

Důvod je prostý: problém není v eM Clientu. Je v metadatech serveru.

Skutečná příčina: INTERNALDATE IMAP přepsaný při importu

Abyste pochopili, co se děje, je třeba sestoupit o úroveň níže a podívat se, jak protokol IMAP ukládá e-maily.

Každá zpráva na serveru IMAP má dva odlišné typy dat:

• Hlavička Date: (definovaná RFC 2822): datum, které odesílatel zapsal do zprávy v okamžiku odeslání. Je zapouzdřena v těle zprávy a teoreticky nedotknutelná.
• INTERNALDATE: metadata serveru, stojící vně zprávy samotné, která představují datum, kdy byla zpráva uložena do schránky. Tuto hodnotu e-mailoví klienti používají přednostně při řazení a zobrazování zpráv.

Při importu PST nebo migraci z Thunderbirdu ukládá importní nástroj (ať už jde o nativní modul eM Clientu, nástroj třetí strany nebo ruční kopírování přes IMAP) zprávy na cílový IMAP server. Pokud nástroj při ukládání explicitně nezachová původní INTERNALDATE, server automaticky přiřadí aktuální INTERNALDATE, tedy datum a čas importu.

Výsledek: 8 000 archivovaných e-mailů z roku 2017, všechny označené jako "přijaté" v den Vaší migrace.

(Mimochodem, pokud jste někdy zkusili číst nezpracované hlavičky e-mailu pomocí funkce Zobrazit zdroj v eM Clientu, jistě jste si všimli, že původní hlavička Date: je stále tam, nedotčená. To je jasný znak, že problém pochází z INTERNALDATE serveru, nikoli ze zprávy samotné.)

Proč změna sloupce řazení nepomůže

Zmatek pramení z jednoho rozlišení, které málokdo zná. V eM Clientu, stejně jako v Outlooku nebo Thunderbirdu, existují obvykle dva sloupce s datem:

• "Datum přijetí" (nebo "Datum doručení"): vychází z INTERNALDATE serveru.
• "Datum" nebo "Datum odeslání": vychází z hlavičky Date: zprávy.

Mnoho správců to zjistí a myslí si, že našli řešení: přepnout na "Datum odeslání" a problém v eM Clientu vizuálně zmizí. To ale není úplně přesné.

Vlastně to přesné vůbec není. I když v eM Clientu řadíte podle data odeslání, problém přetrvává pro všechny ostatní klienty a všechna rozhraní, která přistupují ke stejné schránce. Pokud uživatelé čtou e-maily přes OWA, přes Outlook v kanceláři, přes aplikaci Gmail v mobilu nebo přes jakýkoli jiný klient nakonfigurovaný přes IMAP, uvidí data importu. Nastavení řazení v eM Clientu platí pouze pro eM Client a nemá vliv na metadata uložená na serveru.

Navíc na Microsoft 365 a Google Workspace řadí nativní webové rozhraní podle INTERNALDATE. Toto chování z klienta změnit nelze.

Řazení podle data odeslání není řešení. Je to náplast, která zakrývá skutečný problém, aniž by ho opravila.

Zvláštní případ importu PST

Import souborů PST si zaslouží samostatný odstavec. Soubor PST (Personal Storage Table) je proprietární formát Microsoftu, který ukládá e-maily, kontakty a kalendáře lokálně. Při importu PST do eM Clientu jsou možné dva scénáře:

• Import z lokálního úložiště na IMAP účet: eM Client přečte PST a odešle zprávy na cílový IMAP server. Pokud se datum uložení nezachová, INTERNALDATE se přepíše. Toto je nejčastější případ a právě zde dochází ke korumpování dat.
• Import do lokální složky: zprávy zůstávají v počítači, mimo server. INTERNALDATE v tomto kontextu neexistuje a eM Client může zobrazit datum Date: ze zprávy. Problémy s daty jsou zde méně časté, ale i praktická využitelnost je omezená.

U Thunderbirdu je situace podobná. Ať už používáte integrovanou funkci importu eM Clientu (která čte profily Thunderbirdu), nebo jste kopírovali složky mbox přes IMAP, zprávy jsou znovu uloženy na server bez záruky zachování INTERNALDATE. A server, který přijme zprávu bez explicitní instrukce o datu INTERNALDATE, ji vždy orazítkuje okamžikem přijetí.

Kterých platforem se to týká?

Problém je identický bez ohledu na cílovou platformu, protože jde o standardní chování protokolu IMAP:

• Microsoft 365 / Exchange Online: INTERNALDATE se přepíše při jakémkoli importu, který nepoužívá příkaz IMAP APPEND s explicitním parametrem data. Stejná situace platí pro migraci z on-premise Exchange.
• Google Workspace: stejné chování. E-maily importované přes eM Client nebo nástroje třetích stran zobrazují datum importu v Gmailu i v administrátorském rozhraní.
• Klasické IMAP hostingy (OVH, Infomaniak, Ionos, Wedos apod.): při přijetí zprávy přes APPEND se datum nijak speciálně nezpracovává. INTERNALDATE bude datum uložení.

Jeden zákazník nás kontaktoval poté, co migroval dobrých sto schránek z Exchange 2013 na Microsoft 365 a pro některé VIP účty použil eM Client jako přechodný nástroj. Výsledek: schránky migrované správně přes MigrationWiz byly v pořádku, ale schránky přesunuté přes eM Client měly všechny data importu. Netřeba říkat, že dotčení uživatelé nadšení nebyli.

Proč domácí skript problém snadno nevyřeší

Technicky vzato by někdo, kdo rozumí protokolu IMAP, mohl uvažovat o napsání skriptu pro opravu INTERNALDATE. Původní hlavička Date: je přece v každé zprávě přítomna, nedotčená. Stačilo by ji přečíst a podle toho přebudovat metadata serveru, ne?

Teoreticky ano. V praxi je to zaminované pole.

Zaprvé, hraniční případy se na produkční schránce rychle kupí. Digitálně podepsané zprávy S/MIME jsou na jakoukoli manipulaci se strukturou obzvláště citlivé. Stejně tak PGP šifrované zprávy. E-maily s objemnými přílohami, nestandardními hranicemi MIME nebo neobvyklým kódováním Content-Transfer-Encoding se mohou při nepečlivém zpracování tiše poškodit. Skript funkční na 50 testovacích e-mailech nebude spolehlivě fungovat na schránce s 20 000 zprávami a šestiletou historií.

Zadruhé, správa API kvót. Na Microsoft 365 se limity rychlosti přístupu přes Graph API nebo EWS ve 3 ráno při opravném dávkování 8 000 zpráv dají zvládnout. Ale nezvládají se samy od sebe. Nehlídaný skript, který narazí na chybu 429 Too Many Requests u zprávy číslo 3 741, možná bude pokračovat, možná ne. A Vy nebudete nutně vědět, které zprávy byly zpracovány.

A především: jak ověřit, že každý opravený e-mail je po zpracování neporušený? Domácí skript obvykle žádný mechanismus individuálního ověření nemá. Redate.io to dělá automaticky, pro každou zprávu.

Oprava dat přímo u zdroje pomocí Redate.io

Redate.io řeší problém tam, kde skutečně leží: na úrovni metadat serveru, nikoli e-mailového klienta.

Proces začíná bezplatnou fází skenování. Redate.io se připojí k dané schránce (Microsoft 365 přes Azure AD, Google Workspace přes doménovou delegaci nebo přímý IMAP pro klasické hostingy) a identifikuje e-maily, jejichž metadata data jsou v nesouladu s obsahem zprávy. Výsledek vidíte ještě před tím, než cokoliv zaplatíte.

Oprava využívá proprietární korekční engine, který analyzuje celý řetězec hlaviček každé zprávy, provádí porovnávání vzorů oproti stovkám signatur známých importních nástrojů (včetně specifického chování eM Clientu, Thunderbirdu a importů PST) a cíleně rekonstruuje metadata data, aniž by pozměnil obsah zprávy, její přílohy nebo strukturu MIME.

Každý opravený e-mail je ověřen individuálně. Originály jsou po dobu 30 dnů uchovávány v záložní složce, která je viditelná - to žádný domácí skript standardně nedělá.

Cenový model je jednoduchý: jednorázová platba za schránku podle objemu e-mailů k opravě. Žádné předplatné, žádné opakující se poplatky. Podrobnosti najdete na stránce pro registraci.

Před příští migrací: co zkontrolovat

Pokud plánujete migraci a chcete se tomuto problému předem vyhnout, kontrolní bod je jednoduchý: zachovává nástroj, který používáte, při ukládání zpráv na cílový server explicitně INTERNALDATE?

Pro importy PST do Microsoft 365 nástroje certifikované Microsoftem (například MigrationWiz v nativních režimech nebo nástroj pro migraci Exchange Online) toto zachování obecně zajišťují. U ručních importů přes eM Client nebo Thunderbird to bývá vzácné. Před spuštěním importu na produkčních schránkách si prostudujte dokumentaci svého nástroje.

Dobrý checklist migrace e-mailů vždy zahrnuje ověření dat po migraci na vzorku schránek. Tento bod pokrývá podrobně.

Správci, kteří pravidelně řeší migrace pro své klienty, ocení článek o opravě datumů e-mailů ze strany MSP a také ten o fungování IMAP INTERNALDATE, který dává celému problému širší kontext.

Data Vašich e-mailů jsou poškozená po importu v eM Clientu? Spusťte bezplatný sken na Redate.io a zjistěte rozsah problému dřív, než se rozhodnete, co dělat.