Staré e-maily mají stejné datum: co se stalo?

Příznak: všechny staré e-maily se seskupily ke stejnému datu

Otevřete Outlook, Gmail nebo Apple Mail. Něco nesedí. Stovky, někdy tisíce starých e-mailů zobrazují stejné datum: před několika dny nebo několika týdny. Zprávy z roku 2021, 2019 nebo 2016 vypadají, jako by dorazily včera. Řazení podle data ztratilo smysl. Hledáte důležitý e-mail z loňského roku a je pohřben v bloku tisíců zpráv, které zdánlivě přišly ve stejný den.

Nové e-maily zobrazují správná data. Problém se týká pouze starých zpráv.

Co se vlastně stalo?

První reakce: obviňovat software

Přirozeně si pomyslíte, že je to chyba. Outlook spadl. Aktualizace se nepovedla. Poškozený soubor. A tady začíná zdlouhavé pátrání: hledáte "chyba datum Outlook", narazíte na fóra, která mluví o souborech OST, o nástroji SCANPST.exe, o vytvoření nového profilu Outlooku od nuly...

Strávíte dvě hodiny zkoušením všeho možného. Problém přetrvává.

Mimochodem, SCANPST je nástroj pro opravu lokálních datových souborů Outlooku. Dokáže opravit určité poškození souborů, ale nedotýká se dat uložených na poštovním serveru. Jinými slovy: i kdybyste opravili soubor OST dokonale, data zůstanou špatná, protože problém není u Vás.

Problém je přímo v e-mailech samotných, na serveru.

Co se skutečně stalo: migrace

V naprosté většině případů se tento příznak objeví po migraci poštovního systému. Vaše firma přešla ze starého systému na Google Workspace, Microsoft 365 nebo nový server. Někdo někde použil nástroj pro přesun všech e-mailů z jednoho místa na druhé.

Možná jste o tom nebyli informováni. Nebo jste to věděli, ale nespojili jste si to s problémem s daty. To je zcela pochopitelné.

Tyto migrační nástroje odvádějí obrovskou práci: kopírují tisíce zpráv, celé složky, přílohy. Mají ale zákeřný vedlejší efekt. Když je e-mail přenesen z jednoho serveru na druhý, nástroj přidá do e-mailu malý technický řádek nazvaný hlavička "Received:", která zaznamenává, kdy zpráva dorazila na nový server. To znamená: datum migrace.

A to je jádro celého problému.

Jak poštovní klient rozhoduje, které datum zobrazit

E-mail ve skutečnosti obsahuje několik různých dat, skrytých v technických datech. Existuje původní datum odeslání (to, které normálně vidíte), ale také hlavičky "Received:", které zaznamenávají každý krok cesty zprávy přes internet.

(Pokud jste někdy klikli na "Zobrazit zdroj" nebo "Zobrazit úplné hlavičky" u e-mailu, možná jste viděli ty záhadné řádky, které vypadají jako nesrozumitelný blok textu. Přesně o tom mluvíme.)

Za normálních okolností se Váš poštovní klient podívá na nejnovější hlavičku "Received:", aby určil, kdy e-mail zobrazit. Tato logika funguje dokonale: poslední "Received:" vždy odpovídá příchodu zprávy do schránky, tedy několik vteřin po odeslání.

Po migraci se tato logika obrátí proti Vám. Migrační nástroj přidal novou hlavičku "Received:" úplně nahoře, s datem přenosu. Váš poštovní klient si tuto hlavičku přečte jako první, uvidí datum migrace a zobrazí ho. Původní datum odeslání je stále přítomné, nedotčené, pohřbené níže v datech e-mailu. Váš klient ho ale nevidí, protože se zastaví u první hlavičky.

Výsledek: 8 000 e-mailů, které vypadají, jako by všechny dorazily v ten samý listopadový úterý.

Které nástroje tento problém způsobují?

Nejrozšířenější migrační nástroje toto chování sdílejí. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (bezplatný nástroj Googlu pro migraci z Outlooku) a mnoho dalších. Není to jejich chyba jako taková: jde o důsledek technického fungování e-mailového protokolu. Tyto nástroje přidávají tuto hlavičku, protože to protokol předepisuje při přesunu zprávy z jednoho serveru na druhý.

Problém je, že na tuto skutečnost nikdo uživatele neupozorní.

Pokud Vaše firma nedávno změnila poštovní systém nebo IT oddělení provedlo "migraci do cloudu", je to velmi pravděpodobná příčina. Můžete to ověřit pohledem na postižená data: shodují se přibližně na stejné období? Pokud ano, toto období odpovídá datu migrace.

Falešná řešení, která nefungují

Několik postupů, které se na fórech často objevují, ale nepomáhají:

Oprava datového souboru pomocí SCANPST

Jak jsme zmínili: SCANPST opravuje lokální soubory Outlooku (soubory .pst nebo .ost uložené ve Vašem počítači). E-maily na serveru nemění. Po opravě budou mít Vaše e-maily stále stejná špatná data, protože tato data jsou v e-mailech samotných, nikoli v lokálním souboru.

Vytvoření nového profilu Outlooku

Stejná logika. Vytvoření nového profilu Outlooku znamená začít lokálně od nuly a pak znovu stáhnout všechny e-maily ze serveru. Znovu stažené e-maily budou mít přesně stejná špatná data jako předtím. Jen jste ztratili čas přenastavováním všeho.

Řazení podle "data odeslání" místo "data přijetí"

Některá fóra doporučují změnit kritérium řazení v Outlooku, přejít z data přijetí na datum odeslání. V některých případech to může pomoci... ale ne vždy. A nevyřeší to nic pro jiné programy, jiná zařízení nebo jiné osoby, které přistupují k Vaší schránce. Základní příčina zůstává. Řazení podle data odeslání není řešení, je to náplast.

Přeinstalace poštovního klienta

Ne. E-maily jsou na serveru, nikoli v softwaru. Přeinstalace Outlooku, Gmailu, Apple Mailu nebo Thunderbirdu nezmění nic na datech uložených online.

Dobrá zpráva: správná data jsou stále tam

Tady je něco důležitého, co je dobré pochopit, a co korekci umožňuje: původní datum odeslání každého e-mailu nebylo vymazáno. Je stále v e-mailu, v hlavičce nazvané "Date:", která odpovídá datu odeslání zvolenému odesílatelem. Jde o e-mailový standard (definovaný technickou specifikací RFC 2822), který všechny migrační nástroje respektují, protože jeho změna by byla závažným porušením standardů.

Jinými slovy: pokud jste obdrželi e-mail 14. března 2022, tento e-mail stále obsahuje toto datum někde ve svých datech. Jenom to už není datum, které Váš klient zobrazí jako první.

Přesně to korekci umožňuje. Problém není ztráta dat. Jde o čtení metadat: Váš poštovní klient čte špatné datum, zatímco správné datum je stále přítomné.

Proč to nezkusit opravit vlastními silami?

Možná Vás napadne, zda by IT specialista nemohl napsat skript pro opravu problému. Pochopit, co se děje, je jedna věc. Opravit to správně na tisících e-mailů bez ztráty jediného je věc druhá.

E-mail není jednoduchý textový soubor. Může obsahovat přílohy, digitální podpisy, obsah zakódovaný v komplexních formátech. Úprava metadat takové zprávy bez narušení její struktury vyžaduje zvládnout desítky zvláštních případů: elektronicky podepsané zprávy (S/MIME), šifrované e-maily (PGP), nestandardní kódování, víceúčelové struktury... Skript napsaný na míru, který funguje na 20 testovacích e-mailech, na produkční schránce s 15 000 zprávami velmi pravděpodobně selže. A pokud se něco pokazí, jak zajistit, že žádný e-mail nebyl poškozen nebo ztracen? S domácím skriptem: nelze.

Bez zálohovacího a ověřovacího mechanismu pro každý jednotlivý e-mail je riziko vedlejších škod reálné.

Co dělá Redate.io

Redate.io je služba navržená přímo pro tento problém. Připojí se k Vaší schránce (Google Workspace, Microsoft 365 nebo IMAP server), identifikuje e-maily, jejichž data byla migrací poškozena, a opraví je prostřednictvím proprietárního engine, který analyzuje celý řetězec hlaviček a rekonstruuje datová metadata každé zprávy.

Každý opravený e-mail je ověřen individuálně. Originály jsou uchovány ve viditelné zálohovací složce po dobu 30 dnů. Pokud něco nesedí, můžete se vrátit zpět.

Počáteční sken je zdarma: Redate.io analyzuje Vaši schránku a ukáže Vám přesně, kolik e-mailů je postiženo, ještě než se rozhodnete k čemukoli. Žádné překvapení.

Cena je jednorázová platba, závislá na objemu e-mailů k opravě. Žádné předplatné. Zaplatíte jednou, problém je vyřešen.

Chcete vidět rozsah škod, než se k čemukoli zavážete? Spusťte bezplatný sken Vaší schránky na Redate.io a zjistěte během několika minut, kolik e-mailů je postiženo.