Antidatování e-mailu: co je možné a co je odhalitelné

Antidatování e-mailu: o čem přesně mluvíme?

Tato otázka se pravidelně objevuje na fórech systémových administrátorů a ve Slack skupinách MSP: je možné změnit datum e-mailu po odeslání? Krátká odpověď zní ano, technicky. Ale úplná odpověď je pro každého, kdo by to chtěl zneužít, mnohem méně povzbuzující.

E-mail není monolitický soubor. Je to kolekce textových hlaviček následovaných tělem zprávy. Mezi těmito hlavičkami nese informace o datu hned několik z nich. A některé se mění snadněji než jiné.

V každém e-mailu koexistují tři vrstvy datování:

• Hlavička Date: (RFC 2822), kterou zapsal poštovní klient v okamžiku odeslání
• Hlavičky Received:, přidávané každým serverem, který zprávu přeposílá
• IMAP INTERNALDATE, metadata uložená na straně serveru, nezávislá na obsahu zprávy

Každou z těchto vrstev lze upravit. Žádnou z nich ale nelze upravit bez zanechání stop.

Úprava hlavičky Date:: nejočividnější manipulace

Hlavička Date: je prostý text v souboru .eml. Technicky ji může přepsat libovolný hexadecimální editor nebo Python skript během několika sekund. Pokud jste někdy otevřeli nezpracované hlavičky e-mailu v Gmailu (malé menu "Zobrazit originál"), víte, že je čitelná pro kohokoliv.

Problém? Od roku 2004 podepisuje velká většina poštovních serverů odchozí e-maily pomocí DKIM (DomainKeys Identified Mail). Tento kryptografický podpis explicitně pokrývá několik hlaviček, včetně Date:, From:, Subject: a těla zprávy. Podpis je uložen v hlavičce DKIM-Signature:.

Změna Date: po podpisu mechanicky zneplatní ověření DKIM. Jakýkoliv přijímací server může podpis ověřit načtením veřejného klíče z DNS domény odesílatele. Pokud podpis neodpovídá, zpráva je označena jako pozměněná. Gmail, Outlook.com a všichni velcí poskytovatelé tuto kontrolu provádějí automaticky.

(Mimochodem, pokud chcete DKIM podpis vidět na vlastní oči, otevřete nezpracované hlavičky libovolného e-mailu z Gmailu nebo Office 365: najdete řádek DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=..., který vypadá jako náhodný šum, ale ve skutečnosti je to kryptografický hash celé zprávy.)

Výsledek: upravit Date: na e-mailu podepsaném DKIM znamená rozbít pečeť. Změna je viditelná každému administrátorovi, který ví, kde hledat.

Přepsání hlaviček Received:: řetězec, který se těžko padělá

Hlavičky Received: sledují cestu, kterou e-mail urazil od odesílatele k příjemci. Každý SMTP server, který se zprávy dotkne, přidá jednu, se svým názvem, IP adresou a časovým razítkem. E-mail procházející dvěma nebo třemi relé tedy obsahuje dva nebo tři vrstvené záznamy Received:.

Lze je upravit? Technicky ano, ve vlastní kopii zprávy. Jenže zde je háček: příjemce má také svou kopii. A jeho server přidal vlastní hlavičku Received: jako poslední. Tato hlavička je pod kontrolou příjemce, ne odesílatele. Z vnějšku ji zfalšovat nelze.

Konzistence řetězce je ověřitelná. Pokud jsou časová razítka po sobě jdoucích Received: nekonzistentní (například by prostřední relé přijalo zprávu dříve, než ji odesílatel odeslal), je to okamžitě podezřelé. Forenzní nástroje pro analýzu e-mailů, jako MXToolbox nebo interní nástroje bezpečnostních týmů, kontrolují přesně tohle.

Vlastně to není úplně přesné říkat, že hlavičky Received: nelze zfalšovat vůbec: útočník, který kontroluje vlastní poštovní infrastrukturu, může vytvořit věrohodné hlavičky pro relé, která ovládá. Ale poslední článek řetězce - server příjemce - nikdy neovládá.

IMAP INTERNALDATE: nejtechničtější případ

INTERNALDATE jsou metadata IMAP uložená na straně serveru. Nejde o hlavičku v samotné zprávě: je to hodnota, kterou server asociuje se zprávou ve své interní databázi. Tuto hodnotu používá většina poštovních klientů k řazení zpráv v doručené poště.

Příkaz IMAP APPEND umožňuje uložit zprávu na server s explicitně zadanou hodnotou INTERNALDATE. Jde o legitimní funkci protokolu, zdokumentovanou v RFC 3501. Migrační nástroje ji využívají neustále: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... všechny ukládají e-maily na cílový server se zadanou hodnotou INTERNALDATE.

Teoreticky by někdo s IMAP přístupem ke své vlastní schránce mohl uložit e-mail s libovolnou hodnotou INTERNALDATE. Tato manipulace ale nemění hlavičky zprávy. Původní Date: zůstane nedotčen, Received: zůstanou nedotčeny, DKIM podpis zůstane nedotčen. Mění se pouze metadata pro řazení na straně serveru.

Pro odborníka, který zkoumá nezpracovanou zprávu, je nesoulad mezi INTERNALDATE a Date: okamžitě patrný. A pokud je zpráva podepsána DKIM, je původní datum kryptograficky doloženo.

Message-ID: otisk, který se těžko padělá

Každý e-mail získá jedinečný identifikátor, hlavičku Message-ID:. Tento identifikátor vytváří odesílající SMTP server v okamžiku odeslání, obvykle kombinací časového razítka, náhodného identifikátoru a názvu domény serveru.

Typický Message-ID vypadá takto: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Časové razítko je často přímo zakódováno v identifikátoru. Změnit datum zprávy a ponechat Message-ID s nekompatibilním časovým razítkem vytvoří nesoulad, který je okamžitě nápadný.

Navíc jsou Message-ID indexovány velkými poštovními systémy. Google, Microsoft a další hráči vedou logy, které umožňují dohledat, kdy zpráva skutečně procházela jejich infrastrukturou. V právním nebo forenzním kontextu jsou tyto logy přístupné prostřednictvím soudních postupů.

V praxi: kdo může pokus o manipulaci odhalit?

Položme otázku konkrétně. Obdržíte e-mail, u kterého máte podezření, že bylo datum pozměněno. Co může udělat IT administrátor nebo právník s alespoň základními technickými znalostmi?

• Ověření DKIM: v Gmailu menu "Zobrazit originál" přímo zobrazuje výsledek ověření DKIM nahoře na stránce. "PASS" potvrzuje integritu zprávy od odeslání. "FAIL" nebo "SOFTFAIL" signalizuje změnu.
• Analýza hlaviček: nástroje jako MXToolbox Header Analyzer nebo Google Admin Toolbox automaticky parsují řetězec Received: a upozorní na časové nesrovnalosti.
• Konzistence Message-ID a Date: analytik může porovnat časové razítko zakódované v Message-ID s deklarovanou hodnotou Date:.
• Serverové logy: pokud e-mail prošel serverem, jehož jste administrátorem, SMTP logy obsahují skutečné datum a čas přijetí zprávy, nezávisle na jakýchkoliv hlavičkách.

Zkrátka, nástroje pro odhalení jsou dostupné, zdarma a nevyžadují pokročilé forenzní znalosti. Zvědavý IT admin ověří integritu e-mailu za méně než dvě minuty.

Jediný legitimní případ hromadné změny dat: migrace IMAP

Existuje scénář, kdy stovky tisíc e-mailů skončí s nesprávnými daty bez jakéhokoliv zlého úmyslu: migrace IMAP.

Právě jste dokončili migraci 150 Exchange schránek do Google Workspace. V pondělí ráno začínají přicházet tikety. Uživatelé hlásí, že všechny jejich staré e-maily zobrazují stejné datum - datum víkendu, kdy probíhala migrace. Jejich doručené pošty jsou nečitelné.

Co se stalo, je zdokumentované a předvídatelné: migrační nástroj (BitTitan, CloudM, imapsync, na tom nezáleží) uložil e-maily do Google Workspace přes IMAP APPEND. Nastavil přitom INTERNALDATE odpovídající datu migrace, ne původnímu datu e-mailu. Výsledek: Outlook, který standardně řadí podle INTERNALDATE, zobrazuje datum migrace u všech zpráv. Proč e-maily zobrazují špatné datum po migraci vysvětluje tento mechanismus podrobně.

Původní hlavička Date: je v každé zprávě nedotčena. DKIM podpisy jsou nedotčeny. Obsah se nezměnil. Nesprávná je pouze hodnota INTERNALDATE na straně serveru.

Tento problém se týká BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO a všech nástrojů, které používají IMAP APPEND bez správného zachování INTERNALDATE. Článek věnovaný BitTitan MigrationWiz pokrývá specifika tohoto nástroje. Checklist migrace e-mailů uvádí body, které je třeba ověřit před migrací a po ní, aby se tomuto typu problému předešlo.

Rozdíl mezi opravou a falzifikací

Oprava, kterou provádí Redate.io, je pravým opakem pokusu o falzifikaci. Proprietární opravný engine analyzuje řetězec hlaviček každé zprávy, identifikuje původní datum zakódované v hlavičce Date: (RFC 2822), která se nikdy nezměnila, a opravuje datová metadata tak, aby odpovídala této autentické informaci, která je ve zprávě již obsažena.

Hlavička Date: je zdrojem pravdy. Zapsal ji poštovní klient odesílatele v okamžiku odeslání. Je kryta DKIM podpisem. Redate.io ji nemění. Co se opravuje, je nesoulad zavedený migračním nástrojem, ne původní datum.

Opravit 47 000 e-mailů po nepovedené migraci bez ztráty jediného, bez rozlámání vláken diskuzí, bez poškození příloh, bez vyvolání chyby 429 ve 3 ráno na Google API: to vyžaduje víceúrovňový analytický pipeline se zvládnutím okrajových případů (S/MIME, PGP, kódování non-ASCII dle RFC 2047, složité víceúrovňové struktury). Python skript o pěti řádcích by nepřežil první produkční schránku. Lze opravit data e-mailů po migraci? podrobně vysvětluje, proč je DIY řešení na skutečných objemech riskantní.

Redate.io skenuje poštovní schránky zdarma, identifikuje e-maily s nesprávnými daty a opravuje je prostřednictvím validačního pipeline, který ověřuje každou zprávu individuálně. Originály jsou uchovány ve viditelné záložní složce po dobu 30 dní. Pokud se něco pokazí, vrácení změn je možné.

Migrace posunula data Vašich e-mailů? Spusťte bezplatné skenování na Redate.io a zjistěte rozsah problému dříve, než se rozhodnete, co dělat.