eM Client: nesprávne dátumy po importe PST alebo Thunderbird

Symptóm: všetky emaily majú rovnaký dátum

Práve ste dokončili import PST do eM Clienta, alebo ste migrovali z Thunderbirdu do novej schránky. Import prebehol bez zjavnej chyby. Ale po otvorení doručenej pošty niečo nesedí: stovky, niekedy tisícky emailov zobrazujú rovnaký dátum, dátum dna importu. Email z roku 2019 vyzerá, akoby bol doručený včera. Zmluva podpísaná pred tromi rokmi sa javí, akoby práve prišla.

Prvá prirodzená reakcia je obviňovať eM Clienta. Zlé nastavenie, zlý stĺpec triedenia, chyba zobrazenia... Hľadáte v preferenciách. Prepínate medzi "Dátumom prijatia" a "Dátumom odoslania". Nič sa nemení. Alebo skôr, niečo sa zmení, ale jadro problému to nerieši.

Je to preto, že problém nie je v eM Clientovi. Je v metadátach servera.

Skutočná príčina: INTERNALDATE IMAP prepísaný počas importu

Aby sme pochopili, čo sa deje, treba ísť o úroveň nižšie a pozrieť sa na to, ako protokol IMAP uchováva emaily.

Každá správa na IMAP serveri má dva odlišné typy dátumov:

• Hlavička Date: (definovaná RFC 2822): je to dátum, ktorý odosielateľ zapísal do správy v čase odoslania. Je zapuzdrená v tele správy a teoreticky sa nedá zmeniť.
• INTERNALDATE: metadáta servera, externe od správy, ktoré predstavujú dátum, kedy bola správa uložená do schránky. Práve túto hodnotu e-mailové klienty používajú prednostne na triedenie a zobrazovanie emailov.

Pri importe PST alebo migrácii z Thunderbirdu, importovací nástroj (či už ide o natívny modul eM Clienta, nástroj tretej strany alebo manuálnu kópiu cez IMAP) uloží správy na cieľový IMAP server. A ak nástroj pri ukladaní explicitne nezachová pôvodný INTERNALDATE, server automaticky priradí aktuálny INTERNALDATE, teda dátum a čas importu.

Výsledok: 8 000 archivovaných emailov od roku 2017, všetky s pečiatkou "prijaté" v momente vašej migrácie.

(Mimochodom, ak ste niekedy skúsili čítať surové hlavičky emailu cez Zobraziť zdroj v eM Clientovi, mohli ste si všimnúť, že pôvodná hlavička Date: je stále tam, neporušená. To je znak, že problém pochádza z INTERNALDATE na serveri, nie zo samotnej správy.)

Prečo zmena stĺpca triedenia nepomáha

Zmätok pramení z rozdielu, ktorý málokto pozná. V eM Clientovi, rovnako ako v Outlooku alebo Thunderbirde, zvyčajne existujú dva stĺpce dátumu:

• "Dátum prijatia" (alebo "Dátum doručenia"): vychádza z INTERNALDATE servera.
• "Dátum" alebo "Dátum odoslania": vychádza z hlavičky Date: správy.

Mnoho administrátorov to objaví a myslí si, že našli riešenie: prepnúť na "Dátum odoslania" a problém vizuálne zmizne v eM Clientovi. Ale to nie je celkom presné.

Vlastne, aj keď v eM Clientovi triedite podľa dátumu odoslania, problém pretrváva pre všetkých ostatných klientov a všetky ostatné rozhrania, ktoré pristupujú k tej istej schránke. Ak vaši používatelia kontrolujú emaily z OWA, z Outlooku v kancelárii, z aplikácie Gmail na mobile, alebo z akéhokoľvek klienta nakonfigurovaného cez IMAP, uvidia dátumy importu. Nastavenie triedenia eM Clienta sa vzťahuje len na eM Clienta a nepôsobí na metadáta uložené na strane servera.

Navyše, v Microsoft 365 a Google Workspace natívne webové rozhranie triedi podľa INTERNALDATE. Toto správanie sa nedá zmeniť z klienta.

Triedenie podľa dátumu odoslania nie je riešenie. Je to náplasť, ktorá zakrýva skutočný problém bez toho, aby ho opravila.

Špeciálny prípad importu PST

Import súborov PST si zaslúži osobitný odsek. Súbor PST (Personal Storage Table) je proprietárny formát Microsoftu, ktorý uchováva emaily, kontakty a kalendáre lokálne. Keď importujete PST do eM Clienta, existujú dva scenáre:

• Lokálny import do IMAP účtu: eM Client prečíta PST a odošle správy na cieľový IMAP server. Ak sa dátum uloženia nezachová, INTERNALDATE sa prepíše. Toto je najčastejší prípad a práve tu sa dátumy pokazia.
• Import do lokálneho priečinka: správy zostanú na stroji, mimo servera. INTERNALDATE v tomto kontexte neexistuje a eM Client môže zobrazovať dátum Date: zo správy. Menej problémov s dátumom, ale aj menej praktickej hodnoty.

Pri Thunderbirde je situácia podobná. Či už používate vstavanú funkciu importu eM Clienta (ktorá číta profily Thunderbirdu), alebo ste kopírovali priečinky mbox cez IMAP, správy sa uložia na server bez záruky zachovania INTERNALDATE. A server, ktorý prijme správu bez explicitnej inštrukcie pre dátum INTERNALDATE, ho systematicky nastaví na čas prijatia.

Ktoré platformy sú postihnuté?

Problém je rovnaký bez ohľadu na cieľovú platformu, pretože ide o štandardné správanie protokolu IMAP:

• Microsoft 365 / Exchange Online: INTERNALDATE sa prepíše pri každom importe, ktorý nepoužíva príkaz IMAP APPEND s explicitným parametrom dátumu. Rovnaká situácia pri migrácii z on-premise Exchange.
• Google Workspace: rovnaké správanie. Emaily importované cez eM Clienta alebo nástroje tretích strán zobrazujú dátum importu v Gmaile aj v administrátorskom rozhraní.
• Klasickí IMAP poskytovatelia (OVH, Infomaniak, Ionos, a podobní): žiadne špeciálne spracovanie dátumu pri prijatí správy cez APPEND. INTERNALDATE bude dátum uloženia.

Jeden zákazník nás kontaktoval po tom, čo migroval dobrú stovku schránok z Exchange 2013 na Microsoft 365, pričom eM Clienta použil ako prechodový nástroj pre niektoré VIP účty. Výsledok: schránky migrované správne cez MigrationWiz boli v poriadku, ale schránky prenesené cez eM Clienta mali všetky dátumy importu. Needless to say, dotknutí používatelia neboli nadšení.

Prečo domáci skript problém ľahko nevyrieši

Technicky by niekto, kto rozumie protokolu IMAP, mohol uvažovať o napísaní skriptu na opravu INTERNALDATE. Pôvodná hlavička Date: je tam, neporušená v každej správe. Stačilo by ju prečítať a podľa toho rekonštruovať metadáta servera, nie?

Teoreticky áno. V praxi je to mínové pole.

Po prvé, okrajové prípady sa na produkčnej schránke rýchlo hromadia. Správy digitálne podpísané cez S/MIME sú mimoriadne citlivé na akúkoľvek manipuláciu so štruktúrou. Rovnako správy šifrované cez PGP. Emaily s objemnými prílohami, neštandardnými MIME hranicami alebo neobvyklými kódovaniami Content-Transfer-Encoding sa môžu potichu poškodiť, ak spracovanie nie je dôkladné. Skript, ktorý funguje na 50 testovacích emailoch, nebude spoľahlivo fungovať na schránke s 20 000 správami a 6-ročnou históriou.

Po druhé, správa kvót API. Na Microsoft 365 limity na Graph API alebo EWS o 3. hodine ráno pri dávkovej oprave 8 000 správ, to sa dá zvládnuť. Ale nie samo od seba. Nedohliadzaný skript, ktorý narazí na chybu 429 Too Many Requests pri správe č. 3741, možno bude pokračovať, možno nie. A nie vždy viete, ktoré správy boli spracované.

A predovšetkým: ako overíte, že každý opravený email je po spracovaní neporušený? Domáci skript väčšinou nemá mechanizmus individuálneho overenia. Redate.io to robí automaticky, pre každú správu.

Oprava dátumov pri zdroji s Redate.io

Redate.io rieši problém tam, kde sa nachádza: na úrovni metadát servera, nie na úrovni e-mailového klienta.

Proces začína bezplatnou fázou skenovania. Redate.io sa pripojí k dotknutej schránke (Microsoft 365 cez Azure AD, Google Workspace cez delegovanie domény, alebo priamo cez IMAP pre klasických poskytovateľov) a identifikuje emaily, ktorých metadáta dátumu sú nekonzistentné s obsahom správy. Výsledok vidíte ešte pred akoukoľvek platbou.

Oprava využíva proprietárny engine, ktorý analyzuje celý reťazec hlavičiek každej správy, aplikuje porovnávanie vzorov na stovkách signatúr známych importovacích nástrojov (vrátane špecifického správania eM Clienta, Thunderbirdu, importov PST) a cielene rekonštruuje metadáta dátumu bez zmeny obsahu správy, jej príloh ani štruktúry MIME.

Každý opravený email sa overuje individuálne. Originály sa uchovávajú vo viditeľnom záložnom priečinku po dobu 30 dní, čo domáci skript predvolene nikdy nespraví.

Cenový model je jednoduchý: jednorazová platba za schránku, závislá od objemu emailov na opravu. Žiadne predplatné, žiadne opakujúce sa poplatky. Podrobnosti nájdete na úvodnej stránke.

Pred ďalšou migráciou: čo treba skontrolovať

Ak plánujete migráciu a chcete sa tomuto problému vyhnúť vopred, kontrolný bod je jednoduchý: zachováva nástroj, ktorý používate, explicitne INTERNALDATE pri ukladaní správ na cieľový server?

Pri importe PST do Microsoft 365 certifikované nástroje Microsoftu (napríklad MigrationWiz v natívnych režimoch alebo nástroj na migráciu Exchange Online) toto zachovávanie zvyčajne zvládajú. Pri manuálnych importoch cez eM Clienta alebo Thunderbird je to zriedkavé. Pred spustením importu na produkčné schránky si overte dokumentáciu vášho nástroja.

Dobrý checklist migrácie emailov vždy obsahuje post-migračnú kontrolu dátumov na vzorke schránok. Ak chcete ísť ďalej, náš checklist migrácie emailov pokrýva tento bod podrobne.

Pre administrátorov, ktorí pravidelne spravujú migrácie pre svojich klientov, článok o oprave dátumov emailov na strane MSP a článok o fungovaní IMAP INTERNALDATE poskytujú úplnejší pohľad na problém.

Dátumy vašich emailov sú poškodené po importe cez eM Clienta? Spustite bezplatné skenovanie na Redate.io a zistite rozsah problému ešte pred tým, ako sa rozhodnete, čo robiť.