Modificarea datei unui email primit: adevărat sau fals?

Întrebarea pe care toți o pun (și de ce ascunde două situații complet diferite)

Tastați "modificare data email primit" în Google. Găsiți zeci de fire pe forumurile Microsoft Q&A, threaduri Reddit, întrebări pe Quora. Cererea e clară, dar motivele din spatele ei sunt radical diferite în funcție de cine pune întrebarea.

Există cei care vor să falsifice o dată, retrospectiv, din motive pe care preferăm să nu le imaginăm. Și există administratori IT care, după o migrare IMAP, văd că toate emailurile lor afișează aceeași zi (cea a migrării), și vor pur și simplu să recupereze datele reale. Cele două situații nu au nimic în comun, dar împărtășesc aceeași formulare de căutare.

Acest articol răspunde la amândouă. Spoiler: în primul caz, modificarea nu este cu adevărat posibilă fără a lăsa urme detectabile. În al doilea, este complet legitimă și exact asta face Redate.io.

Mai întâi: ce este "data" unui email?

Un email nu conține o singură dată. Conține mai multe, stocate în locuri diferite, controlate de entități diferite.

Antetul Date: (RFC 2822)

Aceasta este data pe care clientul expeditorului o înscrie în mesaj la momentul trimiterii. Este vizibilă în anteturile brute sub forma:

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

Acest antet face parte din corpul mesajului. Poate fi tehnic modificat dacă accesați fișierul brut. Dar "tehnic" este cuvântul important aici.

Anteturile Received:

Fiecare server de email prin care trece un mesaj adaugă propriul antet Received: cu un timestamp. Aceste antete formează un lanț cronologic, de la serverul expeditorului până la căsuța dumneavoastră. (Dacă ați încercat vreodată să citiți anteturile brute ale unui email, știți că nu e exact lectură de vacanță. Zeci de linii de metadate tehnice, într-o ordine care merge de la cel mai recent la cel mai vechi.)

INTERNALDATE-ul IMAP

Acesta este metadatul cel mai important pentru a înțelege de ce anumite modificări nu au niciun efect vizibil. INTERNALDATE este un atribut stocat pe serverul IMAP, independent de conținutul mesajului. El este cel pe care majoritatea clienților de email îl folosesc pentru a sorta emailurile în dosare. Outlook îl folosește. Gmail la fel. Apple Mail, în marea majoritate a cazurilor, de asemenea.

INTERNALDATE nu se află în mesaj. Se află în baza de date a serverului. Nu îl puteți modifica editând un fișier .eml pe discul dumneavoastră.

Ce se întâmplă de fapt când modificați local

Editarea unui fișier .eml

Tehnic, un fișier .eml este un fișier text. Îl puteți deschide într-un editor, schimba linia Date:, salva. Dacă reimportați acest fișier într-un client de email local, data afișată se poate schimba, în funcție de client.

Dar iată ce nu se schimbă:

• INTERNALDATE pe serverul IMAP (rămâne intact)
• Anteturile Received: adăugate de serverele intermediare
• Logurile de livrare la Google, Microsoft sau furnizorul dumneavoastră
• Semnătura DKIM, dacă mesajul o avea

Rezultat: pe mașina dumneavoastră locală, vedeți poate o dată diferită. Din Outlook conectat la Exchange Online, sau Gmail într-un browser, nimic nu s-a schimbat.

Schimbarea orologiului sistem

Unele forumuri sugerează modificarea orologiului stației de lucru pentru a "păcăli" clientul de email. Nu funcționează. Outlook și Gmail nu citesc ora sistemului pentru a afișa datele emailurilor primite. Citesc INTERNALDATE de pe server, sau anteturile mesajului. Orologiul local nu intervine nicăieri în acest proces.

Manipularea prin Thunderbird

Thunderbird oferă mai multă flexibilitate decât majoritatea clienților. Cu extensii sau manipulând direct profilul (fișiere mbox, fișiere .msf), unii încearcă să modifice afișarea datelor. Poate funcționa în Thunderbird însuși, pentru emailurile stocate local în modul POP3. Dar de îndată ce Thunderbird este conectat în IMAP, se resincronizează cu serverul. "Corecția" dispare la următoarea sincronizare.

DKIM: bariera invizibilă pe care nimeni nu o menționează

Majoritatea emailurilor trimise din 2018 încoace sunt semnate cu DKIM (DomainKeys Identified Mail). O semnătură DKIM arată așa în antete:

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...

Câmpul h= listează anteturile acoperite de semnătură. În exemplul de mai sus, Date este semnat. Dacă modificați antetul Date: al mesajului, verificarea DKIM eșuează. Orice server de email, orice instrument de analiză forensică, poate detecta modificarea recalculând semnătura.

Nu este o protecție perfectă (un expeditor rău intenționat își controlează propria cheie DKIM și poate semna ce dorește la momentul trimiterii). Dar pentru un email deja primit și semnat, modificarea antetului Date: lasă o urmă detectabilă.

Logurile serverului: adevărata sursă de adevăr

Chiar dacă ați reuși să modificați toate metadatele vizibile ale unui email (antete, INTERNALDATE, totul), furnizorii păstrează propriile loguri.

Google Workspace jurnalizează fiecare mesaj în logurile de audit din Admin Console. Microsoft 365 face același lucru în Centrul de conformitate (Purview). Aceste loguri includ timestampurile de livrare, independent de ceea ce este afișat în clienți. Un avocat, un serviciu juridic sau o echipă de securitate informatică poate recupera aceste date. Data vizibilă în Outlook nu are valoare probatorie în fața unui tribunal sau în cadrul unui audit de securitate.

Ca să fiu precis: nici măcar un administrator cu acces la căsuță prin delegare de domeniu nu poate rescrie retrospectiv aceste loguri. Sunt în afara razei utilizatorilor, inclusiv a celor cu privilegii ridicate.

Cazul legitim: corecția post-migrare

Tocmai ați terminat o migrare a 150 de căsuțe de pe un Exchange on-premise spre Microsoft 365. Luni dimineața, tichetele încep să curgă: "toate emailurile mele vechi sunt datate cu vinerea trecută". Data migrării.

Aceasta este o problemă bine documentată și complet diferită de ce am descris până acum. Nimeni nu încearcă să falsifice ceva. Datele originale reale există în continuare, intacte, în antetul Date: al fiecărui mesaj. Problema vine de altundeva: instrumentul de migrare (BitTitan MigrationWiz, CloudM, imapsync sau altul) a inserat un antet Received: cu data migrării în fruntea lanțului. Outlook, care se bazează pe anteturile Received: cele mai recente în loc de INTERNALDATE în anumite contexte, afișează această dată în loc de cea reală.

În acest caz, "corecția" constă în restabilirea coerenței între ceea ce spune mesajul (antetul Date: original, încă acolo) și ceea ce crede serverul (INTERNALDATE, setat la momentul migrării). Nu este falsificare. Este restaurare.

Exact aceasta este problema pe care o migrare prost configurată o impune miilor de căsuțe. Și exact asta rezolvă Redate.io.

De ce "fă-o singur" eșuează la scară

A înțelege problema e un lucru. A o corecta pe 40.000 de emailuri distribuite în 150 de căsuțe fără a pierde niciunul, e cu totul altceva.

Scripturile găsite pe GitHub sau Stack Overflow funcționează pe 20 de emailuri de test. În producție, dau de probleme pe care autorul scriptului nu le-a anticipat:

• Emailurile semnate S/MIME sau criptate PGP au structuri care nu se manipulează ca mesajele obișnuite
• Mesajele multipart cu delimitatori MIME non-standard provoacă erori de parsare
• Anteturile encodate RFC 2047 (caractere non-ASCII în câmpurile From: sau Subject:) sparg parserii naivi
• API-urile Google și Microsoft impun limite de rată (rate limiting): la ora 3 dimineața în timpul unui batch de 30.000 de emailuri, eroarea 429 Too Many Requests nu e gestionată, scriptul se oprește, și nimeni nu știe unde s-a oprit
• Niciun mecanism de rollback: dacă un mesaj este corupt în timpul procesării, nu există nimic pentru a reveni înapoi

Redate.io păstrează o copie a fiecărui email original într-un dosar de backup vizibil timp de 30 de zile. Fiecare corecție este verificată individual. Pipeline-ul de analiză gestionează sute de semnături ale instrumentelor de migrare cunoscute, precum și toate cazurile limită pe care un script de casă nu le-ar trata.

Pentru mai multe detalii în funcție de instrumentul folosit: BitTitan MigrationWiz și datele emailurilor, sau CloudM Migrate: cum corectați datele e-mailurilor.

Ce se schimbă, ce nu se schimbă niciodată

Distincția este clară. Primele trei linii din tabel descriu modificări superficiale sau detectabile. Ultima descrie o corecție legitimă a metadatelor, aliniată cu conținutul original al mesajului, după o migrare care a introdus o incoerență.

Dacă vă aflați în situația descrisă în ultima linie din tabel, după o migrare cu imapsync, BitTitan, CloudM sau alt instrument, Redate.io este făcut pentru asta.

Emailurile dumneavoastră afișează data migrării în loc de datele reale? Scanați gratuit căsuțele cu Redate.io și vedeți exact câte emailuri sunt afectate înainte de a decide.