Zmeniť dátum prijatého emailu: technické limity

Email má tri "dátumy". Nie jeden.

Keď sa hovorí o "zmene dátumu prijatého emailu", väčšina ľudí si predstaví úpravu nejakého poľa, podobne ako pri zmene dátumu vytvorenia súboru vo Windowse. Realita je o niečo zložitejšia. Každý email v sebe nesie tri odlišné vrstvy datovania, každá s vlastnými pravidlami, vlastnými obmedzeniami a vlastnými dôsledkami, ak do nej zasiahnete.

Pochopiť tieto tri vrstvy znamená pochopiť, prečo sú niektoré opravy technicky zdravé, a prečo iné sú buď nemožné, alebo okamžite detekovateľné ako falzifikáty.

Vrstva 1: INTERNALDATE IMAP

INTERNALDATE je metadáta uložená na strane servera, mimo samotnej správy. Nie je súčasťou obsahu emailu. Definuje ju IMAP server a práve ona je tá, ktorú väčšina emailových klientov používa na triedenie správ v zozname.

Outlook napríklad predvolene zobrazuje správy zoradené podľa INTERNALDATE. Gmail tiež, v určitých kontextoch. Takže ak je vaša INTERNALDATE nesprávna, všetky emaily sa v rozhraní javia ako keby mali rovnaký dátum, bez ohľadu na to, čo hovoria interné hlavičky správy.

INTERNALDATE sa nastavuje v momente, keď je správa uložená na server. Cez protokol IMAP je jediný spôsob, ako ju "upraviť", nepriamy: treba použiť príkaz APPEND na uloženie novej kópie správy s požadovaným dátumom. Príkaz IMAP SETINTERNALDATE jednoducho neexistuje. Tento detail bude za chvíľu dôležitý.

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

Toto je pole Date: v surových hlavičkách správy. Nastavuje ho emailový klient v čase odoslania a cestuje so správou zo servera na server. Je to deklarovaný dátum odoslania od odosielateľa.

(Mimochodom, ak ste nikdy nevideli surové hlavičky emailu, je to dosť zvláštne čítanie. Každá správa so sebou ťahá tak dvadsať technických riadkov, ktoré 99 % ľudí nikdy nevidelo.)

Technicky nič nebráni odoslať email s poľom Date: nastaveným do minulosti alebo budúcnosti. SMTP servery toto pole neoverujú. Ale cieľové servery si poznamenajú skutočný čas príchodu do hlavičiek Received:, čo okamžite vytvára nezrovnalosť viditeľnú pre akýkoľvek emailový klient alebo analytický nástroj.

Vrstva 3: naskupené hlavičky Received:

Zakaždým, keď SMTP server prepošle správu, pridá do vrchu zásobníka hlavičku Received: s časovou pečiatkou. Email, ktorý prešiel cez tri servery, bude mať tri hlavičky Received:. Čítajú sa zdola nahor: najstaršia je dole, najnovšia hore.

Práve tu migračné nástroje spôsobujú problém. Keď BitTitan MigrationWiz, CloudM, imapsync alebo GSMMO migrujú email, znovu ho vložia na nový server cez IMAP. Toto uloženie vygeneruje novú položku Received: s časovou pečiatkou z momentu migrácie. Výsledok: najstarší email vo vašej schránke, správa z roku 2019, má zrazu Received: datovaný novembrom 2024. A keďže niektorí emailoví klienti (Outlook na čele) používajú najnovší Received: ako zobrazovaný dátum...

Tu je ten problém. 15 000 emailov zobrazuje rovnaký dátum migrácie.

Dá sa tieto dátumy skutočne "upraviť"?

Technicky áno pre INTERNALDATE (s obmedzeniami). Technicky možné, ale zbytočné pre Date:. A pri Received: sa to oplatí rozobrať podrobnejšie.

Prepísať hlavičku Received: je jednoduché. A okamžite detekovateľné.

Hlavička Received: je len textový riadok v správe. Dá sa upraviť ako akýkoľvek textový súbor. Je to presne také jednoduché, ako to znie.

Ale tu je to, čo sa stane potom.

Prvý problém: DKIM. Podpis DKIM (DomainKeys Identified Mail) sa vypočítava z množiny hlavičiek správy, vrátane niekedy aj Received:. Zmena podpísanej hlavičky podpis zneplatní. Akýkoľvek cieľový server, ktorý overuje DKIM, okamžite uvidí, že správa bola pozmenená. Nejde o jemnú falzifikáciu, je to poplach.

Druhý problém: interné identifikátory. Moderné poštové servery (Google Workspace, Microsoft 365) každej správe priraďujú rastúci, jedinečný interný identifikátor. Tieto identifikátory sú prepojené s INTERNALDATE a poradím prijatia. Zmena Received: bez súladu s týmito identifikátormi vytvára nezrovnalosti, ktoré auditné nástroje odhalia bez ťažkostí.

Tretí problém, praktickejší: aj keď upravíte Received: v obsahu správy, INTERNALDATE ste sa nedotkli, zostáva taká, aká bola pri IMAP uložení. Emailový klient naďalej zobrazuje nesprávny dátum pri triedení. Správu ste zmenili nadarmo.

Jednoducho povedané: prepísať Received: s cieľom sfalšovať dátum emailu pre škodlivé účely je technicky triviálne a odhaliteľné za pár sekúnd odborníkom. Nie je to seriózna cesta.

Hlavička Date:: meniť minulosť na papieri

Rovnaká logika platí pre Date:. Dá sa upraviť v tele správy. Ale hlavičky Received: overené medziservermi zostávajú nedotknuté a rozprávajú iný príbeh. Časová postupnosť je nekonzistentná. Každý analytik alebo súd porovnávajúci tieto polia to okamžite uvidí.

Aby som bol presný: to nezabraňuje niektorým emailovým klientom zobrazovať upravený Date:, ak im priamo predložíte súbor .eml. Ale v kontexte živého poštového servera s autentifikáciou a protokolmi je zmena transparentná.

Migrácia IMAP: jediný kontext, kde je oprava dátumov oprávnená

Existuje jeden, a iba jeden prípad, kde je zmena dátumu prijatia emailu nielen možná, ale technicky opodstatnená: oprava poškodenia spôsobeného zle zvládnutou migráciou IMAP.

Tu je konkrétna situácia. Práve ste migrovali 80 poštových schránok z Exchange do Microsoft 365. Migrácia skončila v piatok večer. V pondelok ráno prichádzajú prvé tikety: "Všetky moje emaily majú rovnaký dátum", "Nedokážem nájsť email z minulého roka", "Moja história s týmto klientom je úplne rozbita". Máte 80 zablokovaných používateľov a šéf čaká na odpoveď.

V tomto kontexte je problém zdokumentovaný, identifikovateľný a jeho príčina je jasná: migračný nástroj pridal Received: s dátumom z dňa migrácie a niektorí emailoví klienti používajú túto novú hlavičku ako zobrazovaný dátum. Pôvodná hlavička Date: je pritom v každej správe nedotknutá. Nikdy nebola zmenená. Stále obsahuje správny pôvodný dátum odoslania.

Oprava teda nie je falzifikácia: je to obnova. Vychádzame z pravdivých dát (pôvodný Date:) na rekonštrukciu konzistentných metadát. To je zásadne odlišné od pokusu vydávať email z roku 2024 za email z roku 2019.

Pre viac informácií o mechanizmoch špecifických pre jednotlivé nástroje tieto príručky popisujú konkrétne prípady: oprava dátumov BitTitan v Microsoft 365, oprava dátumov CloudM v Outlooku, alebo oprava dátumov imapsync v Google Workspace.

Prečo si nepísať vlastný skript

Základná logika je dostupná. Každý IT admin, ktorý strávil čas na IMAP fórach, dokáže zrekonštruovať všeobecný postup. To nie je ten problém.

Problém je priepasť medzi skriptom, ktorý funguje na 50 testovacích emailoch, a skriptom, ktorý beží na 40 000 správach v produkcii bez straty jediného emailu, bez poškodenia jedinej prílohy a bez prerušenia jediného vlákna konverzácie.

Niekoľko konkrétnych prípadov, s ktorými si domáce skripty väčšinou nevedia poradiť:

• S/MIME podpísané emaily: podpis pokrýva obsah aj hlavičky. Akákoľvek zmena štruktúry správy podpis zneplatní. Nešikovne opravený podpísaný email dorazí s hlásením "neplatný podpis".
• PGP šifrované správy: rovnaká rodina problémov, s potenciálne horšími dôsledkami v závislosti od implementácie.
• Kódovanie non-ASCII v hlavičkách: RFC 2047 popisuje kódovanie špeciálnych znakov v hlavičkách. Skript, ktorý manipuluje s hlavičkami bez ošetrenia týchto prípadov, potichu poškodí predmety emailov s diakritikou, japonskými znakmi alebo arabskými menami.
• Limity API rate: Google Workspace aj Microsoft 365 implementujú agresívne obmedzenie. O 3. ráno dávka 10 000 emailov, ktorá narazí na chybu 429 Too Many Requests bez správy exponenciálneho backoff, zanechá polovicu schránok napoly opravených.
• Poškodené MIME hranice: multipart správy s prílohami majú presné MIME hranice. Ich nesprávna regenerácia spôsobí, že prílohy budú nečitateľné.

A otázka, ktorú žiadny domáci skript nevyrieši: ako overiť, že každý opravený email je neporušený? Skript, ktorý upraví 40 000 správ bez individuálnej verifikácie, je hazard. Hazard s dátami, ktoré vaši používatelia považujú za nenahraditeľné.

Článok o dostupných možnostiach opravy dátumov po migrácii preskúmava rôzne prístupy vrátane ich príslušných obmedzení.

Čo robí Redate.io v tomto kontexte

Redate.io je navrhnutý špeciálne pre tento prípad: oprava dátumov poškodených migráciou IMAP, vo veľkom rozsahu, bez rizika pre integritu správ.

Služba sa priamo pripája k dotknutým schránkam (Google Workspace cez delegovanie domény, Microsoft 365 cez Azure AD alebo priamo cez IMAP), bezplatne skenuje správy s nesprávnymi dátumami a potom aplikuje proprietárny opravný pipeline, ktorý ošetruje okrajové prípady opísané vyššie. Každý email je po oprave individuálne overený. Originály zostávajú v viditeľnom zálohovacom priečinku po dobu 30 dní.

Rozpoznávanie vzorcov pokrýva stovky signatúr známych migračných nástrojov: BitTitan MigrationWiz, CloudM, imapsync, GSMMO a ich varianty. Detekcia je presná: Redate.io sa nedotýka emailov, ktorých dátum je správny.

Cenový model je jednoduchý: jednorazová platba za poštovú schránku, bez predplatného. Diagnostický sken je bezplatný, čo umožňuje posúdiť rozsah poškodenia pred akýmkoľvek rozhodnutím.

Ak spravujete schránky postihnuté týmto problémom, tento článok o nesprávnych dátumoch v Outlooku po migrácii podrobne popisuje najbežnejšie príznaky a ako ich odlíšiť od iných príčin.

Chcete zistiť rozsah problému vo vašich schránkach? Spustite bezplatný sken na Redate.io a zistite presne, koľko emailov je postihnutých, ešte pred akoukoľvek opravou.