Takeout mbox: všechny e-maily mají dnešní datum

Otevřeli jste archiv Google Takeout, soubor mbox jste naimportovali do Thunderbirdu pomocí ImportExportTools NG (nebo do Apple Mail) a složky jste pak přetáhli do nového účtu IMAP. V klientovi byly e-maily úhledně seřazené rok po roku. V cílovém účtu mají všechny dnešní datum. Tento článek vysvětluje, co se děje při importu Takeout mbox, proč se zobrazuje datum kopie, jak to během pár minut potvrdit a jak to opravit na straně serveru.

První věc, kterou je třeba vědět: vaše e-maily jsou v pořádku. Původní datum je ve zprávě pořád uložené. Cílový účet ho jen přestal zobrazovat.

Typický scénář importu Takeout mbox

Právě jste zrušili osobní účet Gmail, který jste měli patnáct let. Na takeout.google.com jste si vyžádali export, čekali na zprávu od Googlu (u velké schránky dva dny) a stáhli čtyři archivy zip. V každém je jeden soubor .mbox na každý štítek. Naimportujete je do Thunderbirdu: místní složka se naplní, řazení podle data je bezvadné, rok 2009 úplně dole, včerejšek nahoře.

Pak uděláte to, co by udělal každý. Označíte složky a přetáhnete je do cílového účtu IMAP, třeba Microsoft 365, u hostingu nebo do Google Workspace. Přenos trvá celý večer. V pondělí ráno otevřete webmail.

Problém? Všech 18 400 e-mailů má datum uplynulého víkendu, vejdou se do rozmezí několika hodin. Smlouva z roku 2014 leží vedle newsletteru z minulého týdne a nikdo už nic nenajde v chronologickém pořadí.

Případ se velmi podobá situaci, kdy staré e-maily mají všechny stejné datum, s jedním zásadním rozdílem: tady žádný migrační nástroj vinu nenese. Stačí přetažení myší.

Tři datumy v jednom e-mailu

Abyste tomu porozuměli, přestaňte mluvit o "datu" e-mailu v jednotném čísle. Zpráva importovaná ze souboru mbox nese nejméně tři a každé slouží k něčemu jinému.

Hlavička Date: datum odesílatele

Je to hlavička Date: definovaná v RFC 2822 (převzatá do RFC 5322). Klient odesílatele ji zapíše v okamžiku odeslání, například Date: Tue, 14 Mar 2017 09:12:45 +0100. Patří ke zprávě, putuje s ní a Takeout ji zachovává beze změny. Právě díky ní je oprava možná, protože zůstává nedotčená.

Řádek From v souboru mbox: datum jen na oko

V souboru mbox předchází každé zprávě řádek začínající From (s mezerou, bez dvojtečky). Není to hlavička, je to oddělovač typický pro tento formát souboru a součástí zprávy není. Žádný seriózní nástroj by se na něj při určování data e-mailu neměl spoléhat.

INTERNALDATE: datum uložení na serveru

Třetí údaj, a ten nejméně nápadný: INTERNALDATE, definovaný v RFC 3501. Je to atribut, který server IMAP ukládá vedle zprávy (ne do ní) a který odpovídá okamžiku, kdy byla zpráva do schránky vložena. Outlook, webmaily i telefony ho používají k zobrazení a řazení data přijetí. Podrobnosti o mechanismu najdete v článku o tom, proč se kvůli INTERNALDATE v IMAP datumy pokazí.

Ještě poznámka k hlavičkám Received:, ze kterých se tu často viní nesprávně. Řádky Received u exportovaného e-mailu z Gmailu popisují skutečnou cestu zprávy v roce 2017: mají stará a zcela oprávněná data. V tomto konkrétním případě tedy špatné datum nesídlí ve zprávě, ale v metadatech, která server přidělí kopii.

Proč cílový účet zobrazuje datum kopie

Když klient ukládá zprávu na server IMAP, použije příkaz APPEND. Ten volitelně přijímá datum, které má zpráva dostat. Pokud ho klient pošle, server si ho uloží jako INTERNALDATE. Pokud ne, uplatní pravidlo z RFC 3501: aktuální datum a čas. Zobrazené datum tedy závisí na tom, jak nástroj e-mail zapsal. Nástroj, který původní datum nepředá, dostane datum kopie.

Důsledek: zatímco přetahujete složky, každá zpráva dostane datum svého vlastního uložení. Složka s 3 000 e-maily zkopírovaná za 40 minut se vejde do 40minutového okna.

A proč tedy vypadala místní složka v Thunderbirdu tak dokonale? Protože Thunderbird v ní řadí podle hlavičky Date, ne podle data ze serveru, když místní složka žádný server nemá. Apple Mail se s importovanými schránkami chová podobně: dokud zprávy zůstávají na Macu, je všechno v pořádku. Pravda vyjde najevo ve chvíli, kdy schránku IMAP přečte jiný program, třeba Outlook.

Abych byl přesný, není úplně správné tvrdit, že se všichni klienti mýlí pokaždé. Některé verze datum předávají, jiné ne, a chování se s aktualizacemi měnilo. Dva kolegové, kteří postupují stejně, tak mohou skončit s rozdílným výsledkem, což diagnostiku dělá záhadnější, než by se zdálo.

Přetažení složek není migrace. Je to kopie, a kopie nese datum svého vzniku.

Jak tento případ poznat za pět minut

Než začnete hledat řešení, ověřte, že jste opravdu v tomto scénáři a ne v jiném. Stačí čtyři kontroly.

• Porovnejte obě místa. Místní složka Thunderbirdu (nebo importovaná schránka v Apple Mail) ukazuje správná data, účet IMAP u týchž zpráv datum čerstvé.
• Podívejte se na rozpětí. Ve složce účtu IMAP se datum přijetí vejde do několika hodin, případně minut, kolem okamžiku, kdy jste složky přesunuli.
• Otevřete zdroj zprávy. V Thunderbirdu Zobrazit a pak Zdroj zprávy, v Outlooku najdete hlavičky ve vlastnostech zprávy. Měli byste tam najít starý řádek Date:, zatímco zobrazené datum je čerstvé.
• Zkontrolujte pořadí. Zprávy jsou seřazené v pořadí, v jakém je klient kopíroval, ne chronologicky.

Takhle vypadá srovnání na skutečné zprávě:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (ve zprávě, beze změny)
Datum zobrazené účtem IMAP: den kopírování   (metadata serveru)

Pokud si ty dva řádky vyprávějí každý jiný příběh, jste tady správně. A pokud je špatné i zobrazené datum a zároveň i Date:, jde o jiný, vzácnější problém, který sem nepatří.

(Mimochodem, pokud jste nikdy nečetli surové hlavičky e-mailu, připravte si kafe: není to zrovna čtení na pláž.)

Řazení podle data odeslání: jen náplast

První reflex je přepnout řazení na datum odeslání. V Outlooku to zhruba funguje, ale musíte to nastavit znovu v každé složce a na každém zařízení. Vyhledávání, oznámení, pravidla podle stáří zpráv a zobrazení v mobilu přitom dál používají datum přijetí. Uživatel, který na telefonu hledá "ten mail z minulého září", neuvidí nic logického.

Další lákavá cesta: zkopírovat to celé znovu. Na už používaném účtu to hlavně vytvoří duplicity vedle stávajících zpráv, se stejně špatným datem nebo s jiným. Po dalších sto složkách nemáte jedinou čistou schránku.

Oprava na straně serveru

Dobrá zpráva: původní datum tam pořád je. Oprava spočívá v tom, aby ho cílový účet zobrazoval, bez zásahu do obsahu vašich zpráv.

To dělá Redate. Služba se připojí ke schránce (Google Workspace přes delegování pravomocí v rámci domény, Microsoft 365, Outlook.com a Hotmail s účtem Microsoft každého uživatele nebo přímo IMAP s adresou a heslem). Nepotřebuje vědět, který nástroj potíže způsobil: najde e-maily, jejichž zobrazené datum neodpovídá jejich původnímu datu, ať už příčinou bylo přetažení z Takeout mbox, nebo cokoli jiného. Bezplatná kontrola ukáže rozsah škod ještě před jakýmkoli rozhodnutím.

Vlastní oprava běží na proprietárním korekčním enginu, vícestupňovém analytickém řetězci, který zkoumá řetězec hlaviček každé zprávy a vrací každému e-mailu jeho původní datum. Každý opravený e-mail se pak individuálně ověřuje, včetně kontroly souladu s RFC a zachování struktury zprávy. Originály se nikdy nemažou: zůstávají ve viditelné složce vaší schránky, dokud je sami neodstraníte.

Proč je domácí řešení riskantní

Pochopit problém je jedna věc. Opravit 15 000 e-mailů a neztratit ani jeden je věc druhá.

Skript, který funguje na deseti testovacích zprávách, neobstojí na produkční schránce s 30 000 zprávami. Narazí na podepsané e-maily S/MIME, kterým rozbije podpis sebemenší úprava. Na šifrované zprávy PGP. Na vnořené struktury multipart/alternative, nekonzistentní hranice MIME, nečekaná kódování Content-Transfer-Encoding, hlavičky mimo ASCII kódované podle RFC 2047, přílohy o velikosti 40 MB. A pak přijdou kvóty API, chyba 429 Too Many Requests ve tři ráno uprostřed dávky, síťové timeouty, které operaci utnou na zprávě číslo 11 874.

A co dál? Jak poznáte, že je každá zpráva v pořádku? Bez mechanismu vrácení změn (rollbacku) po chybě zůstanou duplicitní zprávy, ztracené přílohy, rozbitá vlákna konverzací a zmizelé štítky. Redate každý e-mail kontroluje automaticky a originál nechává po ruce, právě aby vám nikdy nemuselo jít o všechno.

Poslední rada zdarma: původní archivy Takeout si nechte, dokud schránku neověříte. Soubor mbox je referenční kopie, i když cílový účet vypadá v pořádku.

Návody podle vašeho klienta

Podle toho, jakým klientem jste kopírovali, popisují konkrétní případ tyto podrobné návody: oprava data ručního kopírování IMAP v Thunderbirdu a stejný případ v Apple Mail.

Máte Takeout už zkopírovaný do účtu IMAP a datum je špatně? Spusťte bezplatnou kontrolu Redate, uvidíte, kolika e-mailů se to týká, a pak je opravte jednorázovou platbou, bez omezení velikosti schránky.