Změnit datum e-mailu: technické limity

E-mail má tři "datumy". Ne jeden.

Když se mluví o "změně data přijatého e-mailu", většina lidí si představí, že upraví nějaké pole, podobně jako datum vytvoření souboru ve Windows. Realita je trochu jiná. Každý e-mail ve skutečnosti nese tři samostatné vrstvy datování, každá s vlastními pravidly, vlastními strážci a vlastními následky, pokud do nich sáhnete.

Pochopit tyto tři vrstvy znamená pochopit, proč jsou některé opravy technicky správné, zatímco jiné jsou buď nemožné, nebo okamžitě odhalitelné jako falzifikát.

Vrstva 1: INTERNALDATE v IMAP

INTERNALDATE je metadata uložená na straně serveru, mimo samotnou zprávu. Není součástí obsahu e-mailu. Definuje ji IMAP server a právě tuto hodnotu většina e-mailových klientů používá k řazení zpráv v seznamu.

Outlook například ve výchozím nastavení zobrazuje zprávy seřazené podle INTERNALDATE. Gmail také, v určitých kontextech. Takže pokud je vaše INTERNALDATE špatná, všechny e-maily v rozhraní vypadají, jako by měly stejné datum, bez ohledu na to, co říkají interní hlavičky zprávy.

INTERNALDATE se nastavuje ve chvíli, kdy je zpráva uložena na server. Prostřednictvím protokolu IMAP ji lze "změnit" jen nepřímo: je nutné použít příkaz APPEND a uložit novou kopii zprávy s požadovaným datem. Příkaz SETINTERNALDATE v IMAP neexistuje. Tento detail bude za chvíli důležitý.

Vrstva 2: hlavička Date: (RFC 2822)

Jde o pole Date: v nezpracovaných hlavičkách zprávy. Nastavuje ji e-mailový klient při odesílání a putuje se zprávou ze serveru na server. Je to datum odeslání deklarované odesílatelem.

(Mimochodem, pokud jste nikdy nenahlédli do nezpracovaných hlaviček e-mailu, je to poměrně zajímavá četba. Každá zpráva s sebou táhne tak dvacet technických řádků, které 99 % lidí nikdy nevidělo.)

Technicky nic nebrání odeslat e-mail s polem Date: nastaveným do minulosti nebo budoucnosti. SMTP servery toto pole neověřují. Ale přijímající servery si reálný čas příchodu zaznamenají do hlaviček Received:, čímž okamžitě vzniká nesoulad viditelný pro jakéhokoli e-mailového klienta nebo analytický nástroj.

Vrstva 3: skládané hlavičky Received:

Pokaždé, když SMTP server přeposílá zprávu, přidá na začátek hlavičku Received: s časovým razítkem. E-mail, který prošel třemi servery, bude mít tři hlavičky Received:. Čtou se zdola nahoru: nejstarší je dole, nejnovější nahoře.

Právě tady migrační nástroje způsobují problém. Když BitTitan MigrationWiz, CloudM, imapsync nebo GSMMO migrují e-mail, vloží ho na nový server přes IMAP. Toto vložení vygeneruje nový záznam Received: opatřený časovým razítkem okamžiku migrace. Výsledek: nejstarší e-mail ve schránce z roku 2019 má najednou Received: datovaný do listopadu 2024. A protože některé e-mailové klienty (v čele s Outlookem) používají nejnovější Received: jako zobrazované datum...

A máme problém. 15 000 e-mailů zobrazuje stejné datum migrace.

Dají se tato data skutečně "změnit"?

Technicky ano u INTERNALDATE (s určitými omezeními). Technicky možné, ale zbytečné u Date:. A u Received: to zaslouží trochu více pozornosti.

Přepsat hlavičku Received: je triviální. A okamžitě odhalitelné.

Hlavička Received: není nic jiného než textový řádek ve zprávě. Dá se upravit jako jakýkoli textový soubor. Přesně tak jednoduché, jak to vypadá.

Ale tady je to, co se stane pak.

První problém: DKIM. Podpis DKIM (DomainKeys Identified Mail) se vypočítává z množiny hlaviček zprávy, někdy včetně Received:. Úprava podepsané hlavičky podpis zneplatní. Jakýkoli přijímající server, který DKIM ověřuje, okamžitě zjistí, že zpráva byla pozměněna. To není žádná jemná falzifikace, to je alarm.

Druhý problém: interní identifikátory. Moderní poštovní servery (Google Workspace, Microsoft 365) přiřazují každé zprávě rostoucí interní identifikátor. Tyto identifikátory jsou provázány s INTERNALDATE a pořadím přijetí. Úprava Received: bez souladu s těmito identifikátory vytvoří nesrovnalosti, které auditní nástroje snadno odhalí.

Třetí problém, praktičtější: i když upravíte Received: v obsahu zprávy, INTERNALDATE se nezmění, ta stále odpovídá okamžiku vložení přes IMAP. E-mailový klient bude nadále zobrazovat špatné datum pro řazení. Zprávu jste upravili zbytečně.

Zkrátka: přepisovat Received: za účelem podvodu s datem e-mailu je technicky triviální, ale expert to odhalí během několika sekund. Není to seriózní cesta.

Hlavička Date:: změnit minulost na papíře

Stejná logika platí pro Date:. Dá se upravit v těle zprávy. Ale hlavičky Received: ověřené mezilehlými servery zůstanou nedotčené a vypovídají jiný příběh. Časová posloupnost je nekonzistentní. Každý analytik nebo soud porovnávající tato pole to okamžitě uvidí.

Upřímně řečeno, to nebrání některým e-mailovým klientům zobrazit upravené Date:, pokud jim přímo předložíte soubor .eml. Ale v prostředí živého poštovního serveru s autentizací a záznamy je úprava transparentní.

Migrace IMAP: jediný kontext, kde oprava dat dává smysl

Existuje jeden, a pouze jeden případ, kdy změna data přijatého e-mailu není jen možná, ale technicky oprávněná: oprava škod způsobených špatně provedenou migrací IMAP.

Konkrétní situace. Právě jste migrovali 80 e-mailových schránek z Exchange do Microsoft 365. Migrace skončila v pátek večer. V pondělí ráno začínají přicházet první tikety: "Všechny moje e-maily mají stejné datum", "Nedokážu najít e-mail z minulého roku", "Celá moje historie s tímto klientem je rozbita". Máte 80 zablokovaných uživatelů a nadřízeného, který čeká na odpověď.

V tomto kontextu je problém zdokumentovaný, identifikovatelný a jeho příčina jasná: migrační nástroj přidal Received: datovaný dnem migrace a některé e-mailové klienty tuto novou hlavičku používají jako zobrazované datum. Původní hlavička Date: je přitom v každé zprávě nedotčena. Nikdy nebyla upravena. Stále obsahuje správné původní datum odeslání.

Oprava tedy není falzifikací, je to obnova. Vychází se ze skutečných dat (původní Date:) a rekonstruují se konzistentní metadata. To je zásadně jiné než snažit se vydávat e-mail z roku 2024 za e-mail z roku 2019.

Pro podrobnější informace o mechanismech specifických pro jednotlivé nástroje jsou k dispozici průvodci s konkrétními případy: oprava dat BitTitan v Microsoft 365, oprava dat CloudM v Outlooku nebo oprava dat imapsync v Google Workspace.

Proč nepsat vlastní skript

Základní logika je dostupná. Každý správce IT, který strávil čas na fórech o IMAP, dokáže obecný postup rekonstruovat. To ale není problém.

Problém je propast mezi skriptem, který funguje na 50 testovacích e-mailech, a skriptem, který zpracuje 40 000 zpráv v produkci bez ztráty jediného e-mailu, bez poškození jediné přílohy a bez rozbití jediného vlákna konverzace.

Několik konkrétních případů, s nimiž si domácí skripty obvykle neporadí:

• E-maily podepsané S/MIME: podpis pokrývá obsah i hlavičky. Jakákoli změna struktury zprávy podpis zneplatní. Nešikovně opravený podepsaný e-mail dorazí příjemci s hláškou "neplatný podpis".
• Zprávy šifrované PGP: stejná kategorie problémů, s potenciálně horšími následky v závislosti na implementaci.
• Kódování non-ASCII v hlavičkách: RFC 2047 popisuje kódování speciálních znaků v hlavičkách. Skript, který s hlavičkami pracuje bez ošetření těchto případů, tiše poškodí předměty e-mailů s diakritikou, japonskými znaky nebo arabskými jmény.
• Limity API: Google Workspace i Microsoft 365 mají agresivní throttling. Ve tři ráno narazí dávka 10 000 e-mailů na chybu 429 Too Many Requests bez exponenciálního backoffu a polovina schránek zůstane opravena jen napůl.
• Poškozené MIME hranice: víceodílné zprávy s přílohami mají přesné MIME hranice. Jejich nesprávná regenerace způsobí, že přílohy budou nečitelné.

A otázka, kterou žádný domácí skript nevyřeší: jak ověřit, že každý opravený e-mail je v pořádku? Skript, který upraví 40 000 zpráv bez individuálního ověření, je sázka. Sázka na data, která uživatelé často považují za nenahraditelná.

Článek o dostupných možnostech opravy dat po migraci rozebírá různé přístupy včetně jejich omezení.

Co Redate.io v tomto kontextu dělá

Redate.io je navržen přesně pro tento případ: opravit data poškozená migrací IMAP ve velkém měřítku, bez rizika pro integritu zpráv.

Služba se přímo připojí k dotčeným schránkám (Google Workspace přes delegaci domény, Microsoft 365 přes Azure AD nebo přímý IMAP), zdarma prohledá zprávy s nesprávnými daty a poté použije proprietární korekční pipeline, který ošetřuje výše popsané krajní případy. Každý e-mail je po opravě individuálně ověřen. Originály zůstávají v záložní složce po dobu 30 dnů.

Rozpoznávání vzorů pokrývá stovky signatur známých migračních nástrojů: BitTitan MigrationWiz, CloudM, imapsync, GSMMO a jejich varianty. Detekce je přesná, Redate.io nesahá na e-maily se správným datem.

Cenový model je přímočarý: jednorázová platba za schránku, bez předplatného. Diagnostický sken je zdarma, takže si můžete rozsah problému změřit dřív, než se rozhodnete cokoli dělat.

Pokud spravujete schránky postižené tímto problémem, tento článek o chybných datech v Outlooku po migraci popisuje nejčastější příznaky a jak je odlišit od jiných příčin.

Chcete vědět, kolik e-mailů je ve Vašich schránkách postiženo? Spusťte bezplatný sken na Redate.io a zjistěte přesný počet ještě před jakoukoli opravou.