Spremeniti datum prejetega e-poštnega sporočila: res ali ne?

Vprašanje, ki ga vsi postavljajo (in zakaj skriva dve povsem različni situaciji)

Vpišite "spremeniti datum prejetega e-poštnega sporočila" v Google. Naletite na desetine niti na Microsoftovih forumih, Reddit razpravah, vprašanjih na Quori. Zahteva je jasna, a razlogi za njo so popolnoma različni glede na to, kdo postavi vprašanje.

Nekateri iščejo, kako bi retroaktivno ponaredili datum, iz razlogov, ki si jih raje ne predstavljamo. In potem so tu IT administratorji, ki po migraciji IMAP vidijo, da vsi njihovi e-poštni sporočili prikazujejo isti dan (dan migracije), in preprosto želijo povrniti prave datume. Ti dve situaciji nimata nič skupnega, delita pa isto iskalno poizvedbo.

Ta članek odgovori na obe. Spoiler: v prvem primeru sprememba ni resnično izvedljiva na nezaznavni način. V drugem je povsem legitimna in natanko to počne Redate.io.

Najprej: kaj sploh je "datum" e-poštnega sporočila?

E-poštno sporočilo ne vsebuje enega samega datuma. Vsebuje jih več, shranjenih na različnih mestih, ki jih nadzorujejo različni subjekti.

Glava Date: (RFC 2822)

To je datum, ki ga odjemalec pošiljatelja zapiše v sporočilo ob pošiljanju. V neobdelanih glavah je viden v obliki:

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

Ta glava je del telesa sporočila. Tehnično jo lahko spremenite, če dostopate do neobdelane datoteke. Toda "tehnično" je tukaj ključna beseda.

Glave Received:

Vsak poštni strežnik, skozi katerega gre e-poštno sporočilo, doda svojo glavo Received: s časovnim žigom. Te glave tvorijo kronološko verigo, od strežnika pošiljatelja do vaše nabiralne skrinjice. (Mimogrede, če ste že kdaj poskusili prebrati neobdelane glave e-poštnega sporočila, veste, da to ni ravno sproščeno branje. Več deset vrstic tehničnih metapodatkov, v vrstnem redu od najnovejšega do najstarejšega.)

IMAP INTERNALDATE

To je najpomembnejši metapodatek za razumevanje, zakaj nekatere spremembe nimajo nobenega vidnega učinka. INTERNALDATE je atribut, shranjen na strani strežnika IMAP, neodvisno od vsebine sporočila. Večina e-poštnih odjemalcev ga uporablja za razvrščanje e-pošte po mapah. Outlook ga uporablja. Gmail prav tako. Apple Mail v večini primerov tudi.

INTERNALDATE ni v sporočilu. Nahaja se v podatkovni bazi strežnika. Ne morete ga spremeniti z urejanjem datoteke .eml na disku.

Kaj se resnično zgodi, ko lokalno urejate sporočilo

Urejanje datoteke .eml

Tehnično gledano je datoteka .eml besedilna datoteka. Lahko jo odprete v urejevalniku, spremenite vrstico Date: in shranite. Če to datoteko znova uvozite v lokalnega e-poštnega odjemalca, se prikazani datum morda spremeni, odvisno od odjemalca.

Toda tukaj je, kaj se ne spremeni:

• INTERNALDATE na strežniku IMAP (ostane nedotaknjen)
• Glave Received:, ki so jih dodali posredniški strežniki
• Dnevniki dostave pri Googlu, Microsoftu ali vašem ponudniku
• Podpis DKIM, če ga je sporočilo imelo

Rezultat: na vaši lokalni napravi morda vidite drugačen datum. V Outlooku, povezanem z Exchange Online, ali Gmailu v brskalniku pa se ni nič spremenilo.

Sprememba sistemske ure

Nekateri forumi predlagajo, da spremenite uro na delovni postaji, da bi "prevarali" e-poštnega odjemalca. To ne deluje. Outlook in Gmail ne bereta sistemske ure za prikaz datumov prejetih sporočil. Bereta INTERNALDATE s strežnika ali glave sporočila. Lokalna ura pri tem procesu sploh ni udeležena.

Manipulacija prek Thunderbirda

Thunderbird ponuja več prilagodljivosti kot večina odjemalcev. Z razširitvami ali z neposrednim poseganjem v profil (datoteke mbox, datoteke .msf) nekateri poskušajo spremeniti prikaz datumov. To morda deluje v samem Thunderbirdu za e-poštna sporočila, shranjena lokalno v načinu POP3. Toda takoj, ko je Thunderbird povezan prek IMAP, se sinhronizira s strežnikom. "Popravek" izgine pri naslednji sinhronizaciji.

DKIM: nevidna ovira, ki je nihče ne omenja

Večina e-poštnih sporočil, poslanih od leta 2018 naprej, je podpisanih z DKIM (DomainKeys Identified Mail). Podpis DKIM je v glavah videti takole:

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= navaja glave, ki jih zajema podpis. V zgornjem primeru je Date podpisan. Če spremenite glavo Date: sporočila, preverjanje DKIM ne uspe. Kateri koli poštni strežnik ali orodje za forenzično analizo lahko zazna spremembo z ponovnim izračunom podpisa.

To ni popolna zaščita (zlonamerni pošiljatelj nadzoruje lastni ključ DKIM in lahko podpiše, kar želi ob pošiljanju). Toda za e-poštno sporočilo, ki je že bilo prejeto in podpisano, sprememba glave Date: pusti zaznavno sled.

Strežniški dnevniki: pravi vir resnice

Tudi če bi uspeli spremeniti vse vidne metapodatke e-poštnega sporočila (glave, INTERNALDATE, vse), ponudniki hranijo lastne dnevnike.

Google Workspace beleži vsako sporočilo v revizijskih dnevnikih Admin Console. Microsoft 365 počne enako v centru za skladnost (Purview). Ti dnevniki vključujejo časovne žige dostave, neodvisno od tega, kaj prikazujejo odjemalci. Odvetnik, pravna služba ali ekipa za informacijsko varnost lahko pridobi te podatke. Datum, prikazan v Outlooku, pred sodiščem ali pri varnostni reviziji ni dokazno gradivo.

Da bi bil natančen: tudi administrator, ki ima dostop do nabiralne skrinjice prek domenskega pooblastila, ne more retroaktivno prepisati teh dnevnikov. So zunaj dosega uporabnikov, tudi privilegiranih.

Legitimni primer: popravek po migraciji

Pravkar ste zaključili migracijo 150 nabiralnih skrinjic z lokalnega Exchange na Microsoft 365. V ponedeljek zjutraj se začnejo kopičiti zahtevki: "vsi moji stari e-poštni sporočili so datirani s preteklim petkom". Z datumom migracije.

To je dobro dokumentiran problem, ki se popolnoma razlikuje od tistega, kar smo pravkar opisali. Tukaj nihče ne poskuša ničesar ponarediti. Pravi izvirni datumi še vedno obstajajo, nedotaknjeni, v glavi Date: vsakega sporočila. Težava je drugje: orodje za migracijo (BitTitan MigrationWiz, CloudM, imapsync ali drugo) je na začetek verige vstavilo glavo Received: z datumom migracije. Outlook, ki se v nekaterih kontekstih zanaša na najnovejše glave Received: namesto na INTERNALDATE, prikaže ta datum namesto pravega.

V tem primeru "popravek" pomeni vzpostavitev skladnosti med tem, kar sporočilo pravi (izvirna glava Date:, ki je vedno tam), in tem, kar strežnik meni (INTERNALDATE, nastavljen ob času migracije). To ni ponarejanje. To je obnova.

Natanko to opisuje zakaj slabo konfigurirana migracija povzroči to težavo v tisočih nabiralnih skrinjicah. In natanko to rešuje Redate.io.

Zakaj domače rešitve ne zdržijo pri večjem obsegu

Razumeti težavo je ena stvar. Popraviti jo na 40.000 e-poštnih sporočilih, razporejenih po 150 nabiralnih skrinjicah, ne da bi izgubili eno samo, je povsem druga stvar.

Skripte, ki jih najdemo na GitHubu ali Stack Overflowu, delujejo na 20 testnih e-poštnih sporočilih. V produkciji naletijo na težave, ki jih avtor skripte ni predvidel:

• E-poštna sporočila, podpisana z S/MIME ali šifrirana z PGP, imajo strukture, ki jih ne moremo obravnavati kot navadna sporočila
• Sporočila multipart z nestandardnimi MIME mejami povzročajo napake pri razčlenjevanju
• Glave, kodirane po RFC 2047 (znaki, ki niso ASCII, v poljih From: ali Subject:), zlomijo naivne razčlenjevalce
• Google in Microsoft API-ji uveljavljajo omejitve hitrosti zahtevkov: ob 3. zjutraj med paketno obdelavo 30.000 e-poštnih sporočil napaka 429 Too Many Requests ni obravnavana, skripta se ustavi in nihče ne ve, kje točno
• Ni mehanizma za razveljavitev: če je sporočilo med obdelavo poškodovano, ni poti nazaj

Redate.io hrani kopijo vsakega izvirnega e-poštnega sporočila v vidni varnostni kopiji mape 30 dni. Vsak popravek je preverjen posamično. Analitični cevovod obravnava na stotine podpisov znanih orodij za migracijo, pa tudi vse mejne primere, ki jih domača skripta ne bi obdelala.

Za podrobnosti glede specifičnih orodij: BitTitan MigrationWiz in datumi e-pošte, ali CloudM Migrate: kako popraviti napačne datume.

Kaj se spremeni in kaj nikoli ne

Razlika je jasna. Prve tri vrstice v tabeli opisujejo površinske ali zaznavne spremembe. Zadnja opisuje legitimni popravek metapodatkov, usklajen z izvirno vsebino sporočila, po migraciji, ki je uvedla neskladnost.

Če ste v situaciji, opisani v zadnji vrstici tabele, po migraciji z imapsync, BitTitanom, CloudMom ali drugim orodjem, je Redate.io narejen točno za to.

Vaša e-poštna sporočila prikazujejo datum migracije namesto pravih datumov? Brezplačno preizkusite skeniranje nabiralnih skrinjic z Redate.io in preverite natanko, koliko sporočil je prizadetih, preden se odločite.