Zmeniť dátum prijatého emailu: pravda alebo lož?

Otázka, ktorú si kladie každý (a prečo skrýva dve úplne odlišné situácie)

Zadajte do Googlu "zmeniť dátum prijatého emailu". Nájdete desiatky vlákien na fórach Microsoft Q&A, Reddit, Quora. Požiadavka je jasná, ale dôvody za ňou sú radikálne odlišné podľa toho, kto sa pýta.

Sú tu tí, ktorí chcú spätne sfalšovať dátum z dôvodov, ktoré si radšej ani nepredstavujeme. A potom sú IT administrátori, ktorí po IMAP migrácii vidia, že všetky emaily zobrazujú ten istý deň (deň migrácie), a chcú jednoducho obnoviť pôvodné dátumy. Tieto dve situácie nemajú nič spoločné, ale zdieľajú rovnaké vyhľadávacie výrazy.

Tento článok odpovedá na obe. Spoiler: v prvom prípade nie je modifikácia skutočne možná tak, aby zostala neodhaliteľná. V druhom je úplne legitímna a práve to robí Redate.io.

Najprv: čo vlastne je "dátum" emailu?

Email neobsahuje iba jeden dátum. Obsahuje ich niekoľko, uložených na rôznych miestach, kontrolovaných rôznymi subjektmi.

Hlavička Date: (RFC 2822)

Toto je dátum, ktorý klient odosielateľa zapíše do správy v momente odoslania. V surových hlavičkách vyzerá takto:

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

Táto hlavička je súčasťou tela správy. Technicky ju možno upraviť, ak máte prístup k surovému súboru. Ale práve to slovo "technicky" je tu kľúčové.

Hlavičky Received:

Každý mailový server, cez ktorý email prechádza, pridá svoju vlastnú hlavičku Received: s časovou pečiatkou. Tieto hlavičky tvoria chronologický reťazec, od servera odosielateľa až po vašu schránku. (Ak ste niekedy skúšali čítať surové hlavičky emailu, viete, že to nie je presne oddychové čítanie. Niekoľko desiatok riadkov technických metadát, v poradí od najnovšieho po najstaršie.)

INTERNALDATE IMAP

Toto je najdôležitejšia metadáta pre pochopenie toho, prečo niektoré úpravy nemajú žiadny viditeľný efekt. INTERNALDATE je atribút uložený na strane IMAP servera, nezávisle od obsahu správy. Práve ten väčšina mailových klientov používa na triedenie emailov v priečinkoch. Outlook ho používa. Gmail tiež. Apple Mail taktiež, vo väčšine prípadov.

INTERNALDATE nie je v správe. Je v databáze servera. Nedá sa zmeniť úpravou súboru .eml na vašom disku.

Čo sa naozaj stane, keď upravujete lokálne

Úprava súboru .eml

Technicky, súbor .eml je textový súbor. Môžete ho otvoriť v editore, zmeniť riadok Date:, uložiť. Ak tento súbor znovu importujete do lokálneho mailového klienta, zobrazený dátum sa môže zmeniť, závisí to od klienta.

Ale toto sa nezmení:

• INTERNALDATE na IMAP serveri (stále nedotknutý)
• Hlavičky Received: pridané medzistopovými servermi
• Doručovacie logy u Googlu, Microsoftu alebo vášho poskytovateľa
• DKIM podpis, ak správa nejaký mala

Výsledok: na vašom lokálnom počítači možno vidíte iný dátum. V Outlooku pripojenom k Exchange Online, alebo v Gmaile cez prehliadač, sa nič nezmenilo.

Zmena systémových hodín

Niektoré fóra navrhujú zmeniť hodiny pracovnej stanice, aby "oklamali" mailového klienta. Nefunguje to. Outlook ani Gmail nečítajú systémový čas na zobrazovanie dátumov prijatých emailov. Čítajú INTERNALDATE zo servera, alebo hlavičky správy. Lokálne hodiny do tohto procesu vôbec nevstupujú.

Manipulácia cez Thunderbird

Thunderbird ponúka väčšiu flexibilitu ako väčšina klientov. S rozšíreniami alebo priamou manipuláciou profilu (súbory mbox, súbory .msf) sa niektorí pokúšajú upraviť zobrazenie dátumov. V samotnom Thunderbirde to môže fungovať pre emaily uložené lokálne v režime POP3. Ale akonáhle je Thunderbird pripojený cez IMAP, resynchronizuje so serverom. "Oprava" zmizne pri najbližšej synchronizácii.

DKIM: neviditeľná bariéra, o ktorej nikto nehovorí

Väčšina emailov odoslaných od roku 2018 je podpísaná pomocou DKIM (DomainKeys Identified Mail). DKIM podpis vyzerá v hlavičkách 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= vymenúva hlavičky pokryté podpisom. V príklade vyššie je Date podpísaný. Ak zmeníte hlavičku Date: správy, overenie DKIM zlyhá. Akýkoľvek mailový server, akýkoľvek nástroj forenznej analýzy, dokáže zmenu odhaliť prepočítaním podpisu.

Nie je to dokonalá ochrana (zákerný odosielateľ kontroluje vlastný DKIM kľúč a môže podpísať čo chce v čase odoslania). Ale pre email, ktorý bol prijatý a podpísaný, zanecháva zmena hlavičky Date: detekovateľnú stopu.

Serverové logy: skutočný zdroj pravdy

Aj keby sa vám podarilo zmeniť všetky viditeľné metadáta emailu (hlavičky, INTERNALDATE, všetko), poskytovatelia si uchovávajú vlastné logy.

Google Workspace zaznamenáva každú správu v auditných logoch Admin Console. Microsoft 365 robí to isté v Centre súladu (Purview). Tieto logy obsahujú časové pečiatky doručenia, nezávisle od toho, čo je zobrazené v klientoch. Právnik, právne oddelenie alebo tím informačnej bezpečnosti môže tieto údaje získať. Dátum viditeľný v Outlooku nemá váhu pred súdom ani pri bezpečnostnom audite.

Ak sme presní: ani administrátor s prístupom k schránke cez doménovú delegáciu nemôže spätne prepísať tieto logy. Sú mimo dosahu používateľov, dokonca aj privilegovaných.

Legitímny prípad: oprava po migrácii

Práve ste dokončili migráciu 150 schránok z Exchange on-premise do Microsoft 365. V pondelok ráno prichádzajú tikety: "všetky moje staré emaily majú dátum minulého piatku". Dátum migrácie.

Toto je dobre zdokumentovaný problém a je úplne odlišný od toho, čo sme práve opísali. Tu nikto nič nesfalšuje. Skutočné pôvodné dátumy stále existujú, nedotknuté, v hlavičke Date: každej správy. Problém je inde: migračný nástroj (BitTitan MigrationWiz, CloudM, imapsync alebo iný) vložil hlavičku Received: s dátumom migrácie na začiatok reťazca. Outlook, ktorý sa v niektorých kontextoch spolieha na najnovšie hlavičky Received: skôr ako na INTERNALDATE, zobrazuje namiesto toho tento dátum.

V tomto prípade "oprava" spočíva v obnovení súladu medzi tým, čo správa hovorí (pôvodná hlavička Date:, stále tam) a tým, čo si myslí server (INTERNALDATE, nastavený v čase migrácie). Nie je to falšovanie. Je to obnova.

Presne toto opisuje problém, ktorý zle nastavená migrácia spôsobuje tisíckam schránok. A práve to Redate.io rieši.

Prečo "urobiť si sám" zlyháva vo väčšom rozsahu

Porozumieť problému je jedna vec. Opraviť ho na 40 000 emailoch rozdelených do 150 schránok bez straty jediného z nich je vec druhá.

Skripty z GitHubu alebo Stack Overflow fungujú na 20 testovacích emailoch. V produkcii narážajú na problémy, ktoré autor skriptu nepredvídal:

• Emaily podpísané S/MIME alebo šifrované PGP majú štruktúry, s ktorými sa nedá manipulovať ako s bežnými správami
• Viacčasticové správy s neštandardnými MIME hranicami spôsobujú chyby pri parsovaní
• Hlavičky kódované podľa RFC 2047 (ne-ASCII znaky v poliach From: alebo Subject:) rozbíjajú jednoduché parsery
• Google a Microsoft API majú limity rýchlosti (rate limiting): o 3:00 ráno počas dávkového spracovania 30 000 emailov nie je chyba 429 Too Many Requests ošetrená, skript sa zastaví a nikto nevie kde presne
• Žiadny mechanizmus na vrátenie zmien: ak sa správa poškodí počas spracovania, niet spôsobu ako sa vrátiť späť

Redate.io uchováva kópiu každého pôvodného emailu v záložnom priečinku viditeľnom po dobu 30 dní. Každá oprava je overovaná individuálne. Pipeline analýzy spracúva stovky podpisov známych migračných nástrojov, ako aj všetky hraničné prípady, ktoré domáci skript nezvládne.

Pre viac podrobností podľa konkrétneho nástroja: BitTitan MigrationWiz a dátumy emailov, alebo CloudM Migrate: oprava nesprávnych dátumov.

Čo sa zmení a čo sa nezmení nikdy

Rozdiel je zrejmý. Prvé tri riadky tabuľky opisujú povrchné alebo odhaliteľné úpravy. Posledný opisuje legitímnu opravu metadát, zosúladenú s pôvodným obsahom správy, po migrácii, ktorá zaviedla nekonzistentnosť.

Ak sa nachádzate v situácii opísanej v spodnom riadku tabuľky, po migrácii pomocou imapsync, BitTitan, CloudM alebo iného nástroja, Redate.io je tu práve na to.

Vaše emaily zobrazujú dátum migrácie namiesto skutočných dátumov? Naskenujte svoje schránky zadarmo pomocou Redate.io a zistite presne, koľko emailov je postihnutých, skôr ako sa rozhodnete.