Promena datuma primljenog emaila: istina ili mit?

Pitanje koje svi postavljaju (i zašto krije dve potpuno različite situacije)

Ukucajte "promena datuma primljenog emaila" u Google. Naći ćete desetine diskusija na Microsoft Q&A forumima, Reddit threadovima, Quora pitanjima. Zahtev je jasan, ali razlozi iza njega su radikalno različiti zavisno od toga ko pita.

Ima onih koji žele da falsifikuju datum, retroaktivno, iz razloga koje ne treba ni zamišljati. A ima IT administratora koji su, posle IMAP migracije, primetili da svi emailovi prikazuju isti dan (onaj kada je migracija obavljena) i koji jednostavno žele da vrate prave datume. Te dve situacije nemaju ništa zajedničko, ali dele isti upit za pretragu.

Ovaj tekst odgovara na oba slučaja. Kratko: u prvom slučaju, promena nije zaista moguća na nedetektabilan način. U drugom, potpuno je legitimna i to je tačno ono što radi Redate.io.

Pre svega: šta je zapravo "datum" emaila?

Email ne sadrži jedan datum. Sadrži ih nekoliko, smeštenih na različitim mestima, pod kontrolom različitih entiteta.

Zaglavlje Date: (RFC 2822)

Ovo je datum koji klijent pošiljaoca upisuje u poruku u trenutku slanja. Vidljiv je u sirovim zaglavljima u obliku:

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

Ovo zaglavlje je deo tela poruke. Tehnički se može izmeniti ako pristupite sirovoj datoteci. Ali "tehnički" je ovde ključna reč.

Zaglavlja Received:

Svaki mail server kroz koji email prolazi dodaje sopstveno zaglavlje Received: sa vremenskim pečatom. Ta zaglavlja formiraju hronološki lanac, od servera pošiljaoca do Vaše pošte. (Uzgred, ako ste ikad pokušali da čitate sirova zaglavlja emaila, znate da to nije baš lagano štivo. Nekoliko desetina redova tehničkih metapodataka, u redosledu koji ide od najnovijeg ka najstarijem.)

IMAP INTERNALDATE

Ovo je najvažniji metapodatak za razumevanje zašto neke izmene nemaju vidljivog efekta. INTERNALDATE je atribut koji se čuva na strani IMAP servera, nezavisno od sadržaja poruke. Njega koristi većina mail klijenata za sortiranje emailova po fasciklama. Outlook ga koristi. Gmail takođe. Apple Mail, u većini slučajeva, isto.

INTERNALDATE nije u poruci. On se nalazi u bazi podataka servera. Ne možete ga izmeniti editovanjem .eml datoteke na Vašem disku.

Šta se zapravo dešava kad lokalno izmenite email

Editovanje .eml datoteke

Tehnički, .eml datoteka je tekstualna datoteka. Možete je otvoriti u editoru, promeniti liniju Date:, sačuvati. Ako ponovo uvezete tu datoteku u lokalni mail klijent, prikazani datum se može promeniti, zavisno od klijenta.

Ali evo šta se time ne menja:

• INTERNALDATE na IMAP serveru (ostaje netaknut)
• Zaglavlja Received: koja su dodali posrednički serveri
• Logovi isporuke kod Googlea, Microsofta ili Vašeg provajdera
• DKIM potpis, ako ga je poruka imala

Rezultat: na Vašoj lokalnoj mašini možda vidite drugačiji datum. U Outlooku povezanom na Exchange Online, ili u Gmailu u pregledaču, ništa se nije promenilo.

Promena sistemskog sata

Neki forumi predlažu menjanje sata na radnoj stanici da bi se "prevario" mail klijent. To ne funkcioniše. Outlook i Gmail ne čitaju sistemski sat da bi prikazali datume primljenih emailova. Čitaju INTERNALDATE sa servera, ili zaglavlja poruke. Lokalni sat ne igra nikakvu ulogu u tom procesu.

Manipulacija putem Thunderbirda

Thunderbird pruža veću fleksibilnost od većine klijenata. Uz ekstenzije ili direktnom manipulacijom profila (mbox datoteke, .msf datoteke), neki pokušavaju da izmene prikaz datuma. To može funkcionisati u samom Thunderbirdu, za emailove sačuvane lokalno u POP3 režimu. Ali čim se Thunderbird poveže putem IMAP-a, sinhronizuje se sa serverom. "Ispravka" nestaje pri sledećoj sinhronizaciji.

DKIM: nevidljiva barijera o kojoj niko ne govori

Većina emailova poslatih od 2018. potpisana je DKIM-om (DomainKeys Identified Mail). DKIM potpis u zaglavljima izgleda ovako:

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

Polje h= navodi zaglavlja pokrivena potpisom. U gornjem primeru, Date je potpisan. Ako izmenite zaglavlje Date: poruke, DKIM verifikacija ne prolazi. Bilo koji mail server, bilo koji forenzički alat, može detektovati izmenu ponovnim izračunavanjem potpisa.

Ovo nije savršena zaštita (zlonamerni pošiljalac kontroliše sopstveni DKIM ključ i može potpisati šta god želi u trenutku slanja). Ali za email koji je već primljen i potpisan, izmena zaglavlja Date: ostavlja detektabilan trag.

Serverski logovi: pravi izvor istine

Čak i kad biste uspeli da izmenite sve vidljive metapodatke emaila (zaglavlja, INTERNALDATE, sve), provajderi čuvaju sopstvene logove.

Google Workspace beleži svaku poruku u audit logove Admin konzole. Microsoft 365 isto radi u Centru za usklađenost (Purview). Ti logovi sadrže vremenske pečate isporuke, nezavisno od onoga što je prikazano u klijentima. Advokat, pravna služba ili tim za informatičku bezbednost može doći do tih podataka. Datum vidljiv u Outlooku ne važi kao dokaz na sudu niti tokom bezbednosne revizije.

Da budemo precizni: čak ni administrator koji ima pristup poštanskom sandučiću putem delegacije domena ne može retroaktivno prepisati te logove. Oni su van domašaja korisnika, čak i privilegovanih.

Legitimni slučaj: ispravka posle migracije

Upravo ste završili migraciju 150 poštanskih sandučića sa Exchange on-premise na Microsoft 365. Sledećeg ponedeljka pristižu tiketi: "svi moji stari emailovi imaju datum od petka". Datum migracije.

Ovo je dobro dokumentovan problem koji je potpuno drugačiji od onoga što smo gore opisali. Ovde niko ne pokušava da falsifikuje bilo šta. Pravi originalni datumi i dalje postoje, netaknuti, u zaglavlju Date: svake poruke. Problem dolazi od drugde: alat za migraciju (BitTitan MigrationWiz, CloudM, imapsync ili neki drugi) ubacio je zaglavlje Received: sa datumom migracije na čelo lanca. Outlook, koji se u određenim kontekstima oslanja na najnovija Received: zaglavlja umesto na INTERNALDATE, prikazuje taj datum umesto pravog.

U ovom slučaju, "ispravka" se svodi na uspostavljanje konzistentnosti između onoga što poruka kaže (originalno zaglavlje Date:, koje je uvek tu) i onoga što server misli (INTERNALDATE, postavljen u trenutku migracije). Ovo nije falsifikovanje. Ovo je restauracija.

To je tačno problem koji loše konfigurisana migracija nameće hiljadama poštanskih sandučića. I to je ono što Redate.io rešava.

Zašto "uradi sam" ne funkcioniše na velikom obimu

Razumeti problem je jedno. Ispraviti ga na 40.000 emailova raspoređenih po 150 sandučića bez da se izgubi ijedan, sasvim je drugo.

Skripte koje se nalaze na GitHubu ili Stack Overflowu rade na 20 test emailova. U produkciji nailaze na probleme koje autor skripte nije predvideo:

• Emailovi potpisani S/MIME ili šifrovani PGP imaju strukture koje se ne mogu manipulisati kao obične poruke
• Multipart poruke sa nestandardnim MIME granicama izazivaju greške pri parsovanju
• Zaglavlja enkodovana po RFC 2047 (non-ASCII znakovi u poljima From: ili Subject:) ruše naivne parsere
• Google i Microsoft API-ji nameću ograničenja brzine (rate limiting): u 3 ujutru tokom batch obrade 30.000 emailova, greška 429 Too Many Requests nije obrađena, skripta staje, i niko ne zna gde je stala
• Nema mehanizma za povratak: ako se poruka ošteti tokom obrade, ne postoji način da se vrati u prvobitno stanje

Redate.io čuva kopiju svakog originalnog emaila u vidljivoj backup fascikli tokom 30 dana. Svaka ispravka se proverava pojedinačno. Pipeline analize obrađuje stotine potpisa poznatih alata za migraciju, kao i sve granične slučajeve koje kućna skripta ne bi obradila.

Za više detalja prema konkretnom alatu: BitTitan MigrationWiz i datumi emailova, ili CloudM Migrate: kako ispraviti pogrešne datume.

Šta se menja, a šta se nikad ne menja

Razlika je jasna. Prva tri reda tabele opisuju površne ili detektabilne izmene. Poslednji red opisuje legitimnu ispravku metapodataka, usklađenu sa originalnim sadržajem poruke, nakon migracije koja je unela nekonzistentnost.

Ako se nalazite u situaciji opisanoj u poslednjem redu tabele, posle migracije putem imapsync-a, BitTitana, CloudM-a ili nekog drugog alata, Redate.io je napravljen upravo za to.

Vaši emailovi prikazuju datum migracije umesto pravih datuma? Besplatno skenirajte Vaše sandučiće uz Redate.io i tačno vidite koliko je emailova zahvaćeno pre nego što odlučite.