Antidatarea unui email: ce este posibil și detectabil

Antidatarea unui email: despre ce vorbim, mai exact?

Întrebarea apare regulat pe forumurile de administrare de sisteme și în grupurile Slack ale MSP-urilor: este posibil să modifici data unui email după trimitere? Răspunsul scurt este da, tehnic vorbind. Dar răspunsul complet este mult mai puțin liniștitor pentru cei care ar vrea să o facă în scopuri dubioase.

Un email nu este un fișier monolitic. Este o colecție de antete textuale urmate de corpul mesajului. Printre aceste antete, mai multe conțin informații despre dată. Și unele sunt mai ușor de modificat decât altele.

Trei straturi de datare coexistă în fiecare email:

• Antetul Date: (RFC 2822), scris de clientul de email în momentul trimiterii
• Antetele Received:, adăugate de fiecare server care relayează mesajul
• INTERNALDATE IMAP, o metadată stocată pe server, independentă de conținutul mesajului

Fiecare dintre aceste straturi poate fi modificat. Niciunul nu poate fi modificat fără a lăsa urme.

Modificarea antetului Date:: manipularea cea mai evidentă

Antetul Date: este text simplu în fișierul .eml. Tehnic, orice editor hexazecimal sau script Python îl poate rescrie în câteva secunde. Dacă ați deschis vreodată antetele brute ale unui email în Gmail (micul meniu "Afișați originalul"), știți că este lizibil de oricine.

Problema? Din 2004, marea majoritate a serverelor de email semnează emailurile trimise cu DKIM (DomainKeys Identified Mail). Această semnătură criptografică acoperă explicit mai multe antete, inclusiv Date:, From:, Subject: și corpul mesajului. Semnătura este stocată în antetul DKIM-Signature:.

Modificarea Date: după semnare invalidează mecanic verificarea DKIM. Orice server receptor poate verifica semnătura recuperând cheia publică din DNS-ul domeniului expeditorului. Dacă semnătura nu mai corespunde, mesajul este marcat ca alterat. Gmail, Outlook.com și toți marii furnizori fac această verificare automat.

(Apropo, dacă vreți să vedeți concret o semnătură DKIM, deschideți antetele brute ale unui email primit de la Gmail sau Office 365: veți găsi o linie DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... care pare zgomot aleatoriu, dar este de fapt un hash criptografic al întregului mesaj.)

Concluzie: modificarea Date: pe un email semnat DKIM înseamnă ruperea sigiliului. Modificarea este vizibilă pentru orice administrator care știe unde să caute.

Rescrierea antetelor Received:: un lanț greu de falsificat

Antetele Received: trasează traseul parcurs de un email între expeditor și destinatar. Fiecare server SMTP care atinge mesajul adaugă câte unul, cu numele său, adresa IP și un timestamp. Un email care trece prin doi sau trei relee conține deci două sau trei antete Received: stivuite.

Se pot modifica? Tehnic, da, pe propria copie a mesajului. Dar iată capcana: destinatarul are și el o copie. Iar serverul său a adăugat propriul antet Received: ultimul. Acest antet este sub controlul destinatarului, nu al expeditorului. Este imposibil de falsificat din exterior.

Coerența lanțului este verificabilă. Dacă timestamp-urile antetelor Received: succesive sunt incoerente (un releu intermediar ar fi primit mesajul înainte ca expeditorul să îl fi trimis, de exemplu), este imediat suspect. Instrumentele de analiză forensică email precum MXToolbox sau instrumentele interne ale echipelor de securitate verifică exact acest lucru.

De fapt, nu este tocmai corect să spunem că antetele Received: sunt imposibil de falsificat integral: un atacator care controlează propria infrastructură de email poate fabrica antete credibile pentru releele pe care le controlează. Dar nu controlează niciodată ultima verigă: serverul destinatarului.

INTERNALDATE IMAP: cazul cel mai tehnic

INTERNALDATE este o metadată IMAP stocată pe server. Nu este un antet în mesajul propriu-zis: este o valoare pe care serverul o asociază mesajului în baza sa de date internă. Aceasta este valoarea pe care majoritatea clienților de email o folosesc pentru a sorta mesajele din inbox.

Comanda IMAP APPEND permite depunerea unui mesaj pe un server specificând explicit un INTERNALDATE. Este o funcționalitate legitimă a protocolului, documentată în RFC 3501. Instrumentele de migrare o folosesc constant: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... toate depun emailuri pe serverul destinație cu un INTERNALDATE specificat.

Teoretic, cineva cu acces IMAP la propria căsuță poștală ar putea depune un email cu orice INTERNALDATE. Dar această manipulare nu modifică antetele mesajului. Date: original rămâne intact, antetele Received: rămân intacte, semnătura DKIM rămâne intactă. Se schimbă doar metadatele de sortare de pe server.

Pentru un expert care examinează mesajul brut, discordanța dintre INTERNALDATE și Date: este imediat vizibilă. Iar dacă mesajul este semnat DKIM, data originală este atestată criptografic.

Message-ID: o amprentă greu de falsificat

Fiecare email generează un identificator unic, antetul Message-ID:. Acest identificator este construit de serverul SMTP expeditor în momentul trimiterii, combinând de obicei un timestamp, un identificator aleatoriu și numele de domeniu al serverului.

Un Message-ID tipic arată astfel: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Timestamp-ul este adesea codificat direct în identificator. Modificarea datei mesajului lăsând un Message-ID cu un timestamp incompatibil creează o incoerență imediat observabilă.

În plus, Message-ID-urile sunt indexate de marile sisteme de mesagerie. Google, Microsoft și alți actori mențin jurnale care permit reconstituirea momentului în care un mesaj a circulat efectiv pe infrastructurile lor. Într-un context legal sau forensic, aceste jurnale sunt accesibile prin proceduri judiciare.

În practică: cine poate detecta o tentativă de manipulare?

Să formulăm concret întrebarea. Primiți un email despre care bănuiți că data a fost modificată. Ce poate face un administrator IT sau un avocat cu un minim de bagaj tehnic?

• Verificare DKIM: în Gmail, meniul "Afișați originalul" afișează direct rezultatul verificării DKIM în partea de sus a paginii. Un "PASS" confirmă integritatea mesajului de la trimitere. Un "FAIL" sau "SOFTFAIL" semnalează o alterare.
• Analiza antetelor: instrumente precum MXToolbox Header Analyzer sau Google Admin Toolbox parsează automat lanțul Received: și semnalează incoerențele temporale.
• Coerența Message-ID / Date: un analist poate compara timestamp-ul codificat în Message-ID cu valoarea Date: declarată.
• Jurnale server: dacă emailul a tranzitat printr-un server pe care îl administrați, jurnalele SMTP conțin data și ora reale de acceptare a mesajului, independent de orice antet.

Pe scurt, instrumentele de detecție sunt accesibile, gratuite și nu necesită expertiză forensică avansată. Un administrator IT un pic curios poate verifica integritatea unui email în mai puțin de două minute.

Singurul caz legitim de modificare masivă a datelor: migrarea IMAP

Există un scenariu în care sute de mii de emailuri ajung să aibă date incorecte fără nicio intenție malițioasă: migrarea IMAP.

Tocmai ați terminat o migrare a 150 de căsuțe Exchange spre Google Workspace. Luni dimineață, tichetele încep să curgă. Utilizatorii raportează că toate emailurile vechi se afișează cu aceeași dată, cea a weekend-ului de migrare. Inbox-urile lor sunt de nefolosit.

Ce s-a întâmplat este documentat și previzibil: instrumentul de migrare (BitTitan, CloudM, imapsync, oricare ar fi) a depus emailurile pe Google Workspace via IMAP APPEND. A specificat un INTERNALDATE corespunzând datei migrării, nu datei originale a emailului. Rezultat: Outlook, care sortează după INTERNALDATE implicit, afișează data migrării pentru toate mesajele. Articolul despre datele greșite după migrare explică acest mecanism în detaliu.

Antetul Date: original este intact în fiecare mesaj. Semnăturile DKIM sunt intacte. Conținutul nu s-a mișcat. Doar INTERNALDATE de pe server este incorect.

Această problemă afectează BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO și toate instrumentele care folosesc IMAP APPEND fără a preserva corect INTERNALDATE. Articolul dedicat BitTitan MigrationWiz acoperă particularitățile acestui instrument. Checklist-ul de migrare email listează punctele de verificat înainte și după o migrare pentru a evita acest tip de problemă.

Diferența dintre corectare și falsificare

Corectarea pe care o efectuează Redate.io este opusul unei tentative de falsificare. Motorul proprietar de corectare analizează lanțul de antete al fiecărui mesaj, identifică data originală codificată în antetul Date: (RFC 2822) care nu s-a modificat niciodată, și corectează metadatele de dată pentru a le alinia cu această informație autentică deja prezentă în mesaj.

Antetul Date: este sursa de adevăr. A fost scris de clientul de email al expeditorului în momentul trimiterii. Este acoperit de semnătura DKIM. Nu este modificat de Redate.io. Ceea ce se corectează este discordanța introdusă de instrumentul de migrare, nu data originală.

Corectarea a 47.000 de emailuri după o migrare eșuată fără a pierde niciunul, fără a strica firele de discuție, fără a corupe atașamentele, fără a declanșa erori 429 la 3 dimineața pe API-ul Google: înseamnă un pipeline de analiză multi-etape cu gestionarea cazurilor limită (S/MIME, PGP, encodări non-ASCII conform RFC 2047, structuri multipart complexe). Un script Python de cinci linii nu ar supraviețui primei căsuțe de producție. Articolul despre corectarea datelor după migrare detaliază de ce abordarea DIY este riscantă la volume reale.

Redate.io scanează căsuțele poștale gratuit, identifică emailurile cu date incorecte și corectează printr-un pipeline de validare care verifică fiecare mesaj individual. Originalele sunt păstrate într-un dosar de backup vizibil timp de 30 de zile. Dacă ceva merge prost, rollback-ul este posibil.

Migrarea dumneavoastră a decalat datele emailurilor? Lansați un scan gratuit pe Redate.io pentru a măsura amploarea problemei înainte de a decide ce să faceți.