Staré emaily majú všetky rovnaký dátum: čo sa stalo?

Príznak: všetky staré emaily zoskupené k rovnakému dátumu

Otvoríte Outlook, Gmail alebo Apple Mail ráno a niečo nesedí. Stovky, niekedy tisíce starých emailov zobrazujú rovnaký dátum: spred niekoľkých dní alebo týždňov. Správy z roku 2021, 2019, 2016 vyzerajú, akoby prišli včera. Triedenie podľa dátumu stratilo akýkoľvek zmysel. Hľadáte dôležitý email z minulého roka a je pohrebený v bloku tisícok správ, ktoré sa zdanlivo zišli v rovnaký deň.

Nové emaily majú správne dátumy. Problém sa týka výhradne starých správ.

Čo sa vlastne stalo?

Prvý reflex: hľadať chybu v softvéri

Prirodzene, pomyslíte na chybu programu. Outlook zlyhal. Aktualizácia sa nepodarila. Poškodený súbor. A tu začína zdĺhavé pátranie: zadáte "chyba dátumu Outlook", narazíte na fóra, ktoré hovoria o súboroch OST, nástroji SCANPST.exe, o vytvorení profilu Outlooku od nuly...

Dve hodiny strávíte testovaním rôznych riešení. Problém pretrváva.

Mimochodom, SCANPST je nástroj na opravu lokálnych dátových súborov Outlooku. Dokáže opraviť isté poškodenia súboru, ale nedotýka sa dát uložených na poštovom serveri. Inými slovami, aj keby ste váš OST súbor opravili dokonale, dátumy zostanú nesprávne, pretože problém nie je na vašom počítači.

Problém je priamo v emailoch, na serveri.

Čo sa naozaj stalo: migrácia

V drvivej väčšine prípadov sa tento príznak objaví po migrácii poštového systému. Vaša firma prešla zo starého systému na Google Workspace, Microsoft 365 alebo nový server. Niekto, niekde, použil nástroj na presun všetkých vašich emailov z jedného miesta na druhé.

Možno vás o tom nikto neinformoval. Alebo ste o migrácii vedeli, ale nespojili ste si ju s problémom s dátumami. To je úplne pochopiteľné.

Tieto migračné nástroje odvádzajú obrovskú prácu: kopírujú tisíce správ, celé priečinky, prílohy. Majú však jeden zákerný vedľajší efekt. Keď sa email prenesie z jedného servera na druhý, nástroj pridá do emailu malý technický riadok, tzv. hlavičku "Received:", ktorá zaznamená, kedy správa dorazila na nový server. Teda: dátum migrácie.

A tu je jadro problému.

Ako poštový klient rozhoduje, ktorý dátum zobraziť

Email v skutočnosti obsahuje viacero rôznych dátumov skrytých vo svojich technických dátach. Je tam pôvodný dátum odoslania (ten, ktorý normálne vidíte), ale aj hlavičky "Received:", ktoré zaznamenávajú každú zastávku správy na internete.

(Ak ste niekedy klikli na "Zobraziť zdroj" alebo "Zobraziť úplné hlavičky" emailu, možno ste videli tieto záhadné riadky, ktoré vyzerajú ako nezrozumiteľný blok textu. Presne to je.)

Za normálnych okolností váš poštový klient číta poslednú hlavičku "Received:" a podľa nej určí, kedy email zobraziť. Táto logika funguje dokonale: posledná hlavička "Received:" vždy zodpovedá príchodu správy do vašej schránky, teda pár sekúnd po odoslaní.

Po migrácii sa však táto logika obráti proti vám. Migračný nástroj pridal novú hlavičku "Received:" úplne na vrch, s dátumom prenosu. Váš poštový klient prečíta túto hlavičku ako prvú, uvidí dátum migrácie a zobrazí ho. Pôvodný dátum odoslania je stále prítomný, netknutý, len hlbšie v dátach emailu. Váš klient ho však nevidí, pretože sa zastaví pri prvej hlavičke.

Výsledok: 8 000 emailov, ktoré sa zdajú byť doručené v rovnaký novembrový utorok.

Ktoré nástroje spôsobujú tento problém?

Najrozšírenejšie migračné nástroje majú všetky rovnaké správanie. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (bezplatný nástroj Google na migráciu z Outlooku) a mnohé ďalšie. Nie je to vlastne ich chyba: je to dôsledok technického fungovania emailového protokolu. Tieto nástroje pridávajú danú hlavičku, pretože to protokol predpisuje pri prenose správy z jedného servera na druhý.

Problém je, že nikto používateľov vopred neupozorní, že sa to stane.

Ak vaša firma nedávno zmenila poštový systém, alebo ak vaše IT oddelenie uskutočnilo "migráciu do cloudu", je to s veľkou pravdepodobnosťou pôvod problému. Môžete to overiť pohľadom na postihnuté dátumy: zodpovedajú všetky zhruba rovnakému obdobiu? Ak áno, toto obdobie je dátum migrácie.

Falošné stopy, ktorým sa vyhnúť

Zopár riešení, ktoré sa na fórach objavujú často a nefungujú:

Oprava dátového súboru pomocou SCANPST

Spomínali sme to vyššie: SCANPST opravuje lokálne súbory Outlooku (súbory .pst alebo .ost uložené na vašom počítači). Emaily na serveri nemení. Po oprave budú vaše emaily stále zobrazovať rovnaké nesprávne dátumy, pretože tieto dátumy sú priamo v emailoch, nie v lokálnom súbore.

Vytvorenie nového profilu Outlooku

Rovnaká logika. Vytvorenie nového profilu Outlooku znamená začať lokálne od nuly a znova stiahnuť všetky emaily zo servera. Znova stiahnuté emaily budú mať presne rovnaké nesprávne dátumy ako predtým. Len ste stratili čas s opätovnou konfiguráciou.

Triedenie podľa "dátumu odoslania" namiesto "dátumu prijatia"

Niektoré fóra navrhujú zmeniť kritérium triedenia v Outlooku, prejsť od dátumu prijatia k dátumu odoslania. V niektorých prípadoch to môže pomôcť... ale nie vždy. A nič to nerieši v iných klientoch, na iných zariadeniach, ani pre ďalšie osoby, ktoré pristupujú k vašej schránke. Základná príčina zostáva. Triedenie podľa dátumu odoslania nie je riešenie, je to len náplasť.

Preinštalovanie poštového klienta

Nie. Emaily sú na serveri, nie v klientovi. Preinštalovanie Outlooku, Gmailu, Apple Mailu alebo Thunderbirdu nijako nezmení dáta uložené online.

Dobrá správa: skutočné dátumy sú stále tam

Tu je niečo dôležité, čo treba pochopiť a čo opravu umožňuje: pôvodný dátum odoslania každého emailu nebol vymazaný. Stále je v emaile, v hlavičke nazvanej "Date:", ktorá zodpovedá dátumu odoslania zvolenému odosielateľom. Je to emailový štandard (definovaný technickou špecifikáciou RFC 2822), ktorý všetky migračné nástroje dodržiavajú, pretože jeho zmena by bola závažným porušením noriem.

Inými slovami, ak ste dostali email 14. marca 2022, tento email stále obsahuje daný dátum niekde v svojich dátach. Len to už nie je dátum, ktorý váš klient zobrazuje ako prvý.

Práve to opravu umožňuje. Problém nie je strata dát. Je to otázka čítania metadát: váš poštový klient číta nesprávny dátum, zatiaľ čo správny dátum je stále prítomný.

Prečo to neskúšať opraviť svojpomocne?

Možno sa pýtate, či IT špecialista nemôže jednoducho napísať skript na opravu problému. Pochopiť, čo sa deje, je jedna vec. Opraviť to korektne na tisícoch emailoch bez jedinej straty je vec druhá.

Email nie je jednoduchý textový súbor. Môže obsahovať prílohy, digitálne podpisy, obsah zakódovaný v zložitých formátoch. Úprava metadát takejto správy bez jej poškodenia vyžaduje zvládnuť desiatky osobitných prípadov: elektronicky podpísané správy (S/MIME), šifrované emaily (PGP), neštandardné kódovania, viacčasticové štruktúry... Domáci skript, ktorý funguje na 20 testovacích emailoch, s veľkou pravdepodobnosťou nebude správne fungovať na produkcií s 15 000 správami. A ak niečo zlyhá, ako zistíte, že žiadny email nebol poškodený alebo stratený? S domácim skriptom: nemožné.

Bez zálohovacieho a individuálneho overovacieho mechanizmu pre každý email je riziko vedľajších škôd reálne.

Čo robí Redate.io

Redate.io je služba navrhnutá špeciálne pre tento problém. Pripojí sa k vašej schránke (Google Workspace, Microsoft 365 alebo IMAP server), identifikuje emaily, ktorých dátumy boli migráciou zmenené, a opraví ich pomocou proprietárneho engine, ktorý analyzuje celý reťazec hlavičiek a rekonštruuje dátové metadáta pre každú správu.

Každý opravený email je overený individuálne. Originály sú uchovávané v záložnom priečinku viditeľnom po dobu 30 dní. Ak niečo nie je v poriadku, môžete sa vrátiť späť.

Úvodný scan je bezplatný: Redate.io analyzuje vašu schránku a ukáže vám presne, koľko emailov je postihnutých, ešte predtým, ako sa rozhodnete čokoľvek podniknúť. Žiadne prekvapenia.

Cena je jednorazová platba, závislá od objemu emailov na opravu. Žiadne predplatné. Zaplatíte raz, problém je vyriešený.

Chcete vidieť rozsah škôd skôr, než sa zavážete? Spustite bezplatný scan vašej schránky na Redate.io a zistite za pár minút, koľko emailov je postihnutých.