Změnit datum přijatého e-mailu: co je možné?

Otázka, kterou si pokládá každý (a proč skrývá dvě zcela rozdílné situace)

Zkuste zadat "změnit datum přijatého e-mailu" do Googlu. Najdete desítky vláken na fórech Microsoft Q&A, diskuze na Redditu, otázky na Quoře. Záměr je jasný, ale důvody za ním jsou zásadně odlišné podle toho, kdo se ptá.

Jsou tu ti, kdo chtějí datum zfalšovat zpětně, z důvodů, o kterých raději neuvažujeme. A pak jsou tu IT administrátoři, kteří po migraci IMAP vidí, jak všechny jejich e-maily zobrazují stejný den (den migrace), a chtějí jednoduše obnovit skutečná data. Tyto dvě situace spolu nemají nic společného, přesto sdílejí stejný vyhledávací dotaz.

Tento článek odpovídá na obojí. Spoiler: v prvním případě není úprava skutečně proveditelná tak, aby zůstala neodhalitelná. Ve druhém případě je zcela legitimní a přesně to dělá Redate.io.

Nejdřív: co vlastně je "datum" e-mailu?

E-mail neobsahuje jedno datum. Obsahuje jich několik, uložených na různých místech, kontrolovaných různými subjekty.

Hlavička Date: (RFC 2822)

To je datum, které klient odesílatele zapíše do zprávy v okamžiku odeslání. V nezpracovaných hlavičkách je viditelná v tomto formátu:

Date: Mon, 14 Oct 2024 09:32:11 +0200

Tato hlavička je součástí těla zprávy. Technicky ji lze upravit, pokud máte přístup k surovému souboru. Ale slovo "technicky" je tady klíčové.

Hlavičky Received:

Každý poštovní server, přes který e-mail prochází, přidá svoji vlastní hlavičku Received: s časovým razítkem. Tyto hlavičky tvoří chronologický řetězec, od serveru odesílatele až po Vaši schránku. (Mimochodem, pokud jste někdy zkoušeli číst nezpracované hlavičky e-mailu, víte, že to není zrovna čtení na pláži. Desítky řádků technických metadat, v pořadí od nejnovějšího po nejstarší.)

IMAP INTERNALDATE

To je metadata nejdůležitější pro pochopení, proč některé úpravy nemají žádný viditelný účinek. INTERNALDATE je atribut uložený na straně IMAP serveru, nezávisle na obsahu zprávy. Právě tento atribut většina poštovních klientů používá k řazení e-mailů ve složkách. Outlook ho používá. Gmail také. Apple Mail taktéž, v naprosté většině případů.

INTERNALDATE není ve zprávě samotné. Je v databázi serveru. Nelze ho změnit úpravou souboru .eml na Vašem disku.

Co se skutečně stane, když upravujete lokálně

Úprava souboru .eml

Technicky vzato, soubor .eml je textový soubor. Můžete ho otevřít v editoru, změnit řádek Date:, uložit. Pokud tento soubor znovu importujete do lokálního poštovního klienta, zobrazené datum se může změnit, závisí to na klientovi.

Ale tady je to, co se nezmění:

• INTERNALDATE na IMAP serveru (zůstane nedotčen)
• Hlavičky Received: přidané mezilehlými servery
• Logy doručení u Googlu, Microsoftu nebo Vašeho poskytovatele
• Podpis DKIM, pokud zpráva nějaký měla

Výsledek: na Vašem lokálním počítači možná uvidíte jiné datum. Z Outlooku připojeného k Exchange Online, nebo z Gmailu v prohlížeči, se nic nezměnilo.

Změna systémových hodin

Některá fóra navrhují upravit hodiny pracovní stanice, aby se "obelstil" poštovní klient. Nefunguje to. Outlook ani Gmail nečtou systémový čas pro zobrazení dat přijatých e-mailů. Čtou INTERNALDATE ze serveru, nebo hlavičky zprávy. Lokální hodiny do tohoto procesu vůbec nevstupují.

Manipulace přes Thunderbird

Thunderbird nabízí větší flexibilitu než většina klientů. Pomocí rozšíření nebo přímou manipulací s profilem (soubory mbox, soubory .msf) se někteří pokoušejí změnit zobrazení dat. Může to fungovat přímo v Thunderbirdu, pro e-maily uložené lokálně v režimu POP3. Jakmile je ale Thunderbird připojen přes IMAP, synchronizuje se ze serveru. "Oprava" zmizí při příští synchronizaci.

DKIM: neviditelná bariéra, o které nikdo nemluví

Většina e-mailů odesílaných od roku 2018 je podepsána pomocí DKIM (DomainKeys Identified Mail). Podpis DKIM v hlavičkách vypadá takto:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

Pole h= uvádí hlavičky zahrnuté do podpisu. Ve výše uvedeném příkladu je podepsáno i Date. Pokud změníte hlavičku Date: zprávy, ověření DKIM selže. Jakýkoliv poštovní server nebo nástroj pro forenzní analýzu dokáže úpravu odhalit přepočítáním podpisu.

Není to dokonalá ochrana (škodlivý odesílatel kontroluje svůj vlastní klíč DKIM a může podepsat cokoliv v okamžiku odeslání). Ale pro e-mail, který už byl přijat a podepsán, zanechá změna hlavičky Date: detekovatelnou stopu.

Logy serveru: skutečný zdroj pravdy

I kdybyste dokázali upravit všechna viditelná metadata e-mailu (hlavičky, INTERNALDATE, vše), poskytovatelé si vedou vlastní záznamy.

Google Workspace zaznamenává každou zprávu v auditnich logu Admin Console. Microsoft 365 to samé v Centru souladu (Purview). Tyto záznamy obsahují časová razítka doručení, nezávisle na tom, co zobrazují klienti. Právník, právní oddělení nebo tým informační bezpečnosti může tato data získat. Datum viditelné v Outlooku nemá před soudem ani při bezpečnostním auditu žádnou váhu.

Přesněji řečeno: ani administrátor s přístupem ke schránce prostřednictvím delegování domény nemůže tyto záznamy zpětně přepsat. Jsou mimo dosah uživatelů, i těch privilegovaných.

Legitimní případ: oprava po migraci

Právě jste dokončili migraci 150 schránek z Exchange on-premise na Microsoft 365. V pondělí ráno začínají přicházet tickety: "všechny moje staré e-maily mají datum z minulého pátku". Datum migrace.

Jde o zdokumentovaný problém, který je zcela odlišný od toho, co jsme popsali výše. Zde nikdo nic nefalsifikuje. Skutečná původní data stále existují, nedotčena, v hlavičce Date: každé zprávy. Problém pochází odjinud: nástroj pro migraci (BitTitan MigrationWiz, CloudM, imapsync nebo jiný) vložil na začátek řetězce hlavičku Received: s datem migrace. Outlook, který v určitých kontextech spoléhá spíše na nejnovější hlavičky Received: než na INTERNALDATE, zobrazuje místo toho toto datum.

V takovém případě "oprava" spočívá v obnovení souladu mezi tím, co zpráva říká (původní hlavička Date:, která je stále přítomna), a tím, co si server myslí (INTERNALDATE nastavený v okamžiku migrace). Nejde o falsifikaci. Jde o obnovu.

Přesně takový problém popisuje článek o tom, proč e-maily zobrazují špatné datum po migraci. A přesně to Redate.io řeší.

Proč "udělej si sám" selhává ve větším měřítku

Pochopit problém je jedna věc. Opravit ho na 40 000 e-mailech rozložených do 150 schránek bez ztráty jediného je věc jiná.

Skripty z GitHubu nebo Stack Overflow fungují na 20 testovacích e-mailech. V produkci narážejí na problémy, které autor skriptu nepředvídal:

• E-maily podepsané S/MIME nebo šifrované PGP mají struktury, se kterými nelze zacházet jako s běžnými zprávami
• Zprávy multipart s nestandardními hranicemi MIME způsobují chyby při parsování
• Hlavičky kódované podle RFC 2047 (znaky mimo ASCII v polích From: nebo Subject:) rozbíjejí jednoduché parsery
• Google a Microsoft API mají limity volání (rate limiting): ve 3 ráno během zpracování dávky 30 000 e-mailů se chyba 429 Too Many Requests neošetří, skript se zastaví a nikdo neví, kde přesně skončil
• Žádný mechanismus pro rollback: pokud dojde k poškození zprávy během zpracování, není cesta zpět

Redate.io uchovává kopii každého původního e-mailu v záložní složce viditelné po dobu 30 dní. Každá oprava je ověřena individuálně. Pipeline analýzy zpracovává stovky signatur známých migračních nástrojů, včetně všech okrajových případů, se kterými by si domácí skript neporadil.

Pro podrobnější informace podle použitého nástroje: BitTitan MigrationWiz a data e-mailů, nebo CloudM Migrate: jak opravit špatná data e-mailů.

Co se změní a co nezměníte nikdy

Rozdíl je zřejmý. První tři řádky tabulky popisují povrchní nebo odhalitelné úpravy. Poslední řádek popisuje legitimní opravu metadat, v souladu s původním obsahem zprávy, po migraci, která zanesla nekonzistenci.

Pokud jste v situaci popsané v posledním řádku tabulky, po migraci přes imapsync, BitTitan, CloudM nebo jiný nástroj, Redate.io je přesně pro Vás.

Vaše e-maily zobrazují datum migrace místo skutečných dat? Zdarma prohledejte své schránky pomocí Redate.io a zjistěte přesně, kolik e-mailů je dotčeno, dříve než se rozhodnete.