Promena datuma primljenog mejla: tehnicka ogranicenja

Mejl ima tri "datuma". Ne jedan.

Kada neko pomene "promenu datuma primljenog mejla", vecina ljudi zamislja editovanje nekog polja, kao što bi se menjao datum kreiranja fajla u Windowsu. Stvarnost je nešto komplikovanija. Svaki mejl zapravo nosi tri razlicita sloja datiranja, svaki sa sopstvenim pravilima, sopstvenim cuvarimaа i sopstvenim posledicama ako se dotakne.

Razumeti ova tri sloja znaci razumeti zašto su neke ispravke tehnicki ispravne, a druge su ili nemoguce ili odmah prepoznatljive kao falsifikati.

Sloj 1: IMAP INTERNALDATE

INTERNALDATE je metapodatak koji se cuva na strani servera, izvan samog sadržaja poruke. Ne cini deo mejla kao takvog. Definiše ga IMAP server, i upravo njega vecina mejl klijenata koristi za sortiranje poruka u listi.

Outlook, na primer, po default-u prikazuje poruke sortirane po INTERNALDATE. Gmail takodje, u odredjenim kontekstima. Zbog toga, ako je Vaš INTERNALDATE pogrešan, svi mejlovi izgledaju kao da imaju isti datum u interfejsu, bez obzira šta kažu interni header-i poruke.

INTERNALDATE se definiše u trenutku kada se poruka deponuje na server. Putem IMAP protokola, jedini nacin da se "izmeni" je indirektan: potrebno je koristiti komandu APPEND da bi se deponovala nova kopija poruke sa željenim datumom. Ne postoji IMAP komanda SETINTERNALDATE. Ovaj detalj ce biti važan za trenutak.

Sloj 2: Date: header (RFC 2822)

Ovo je polje Date: u sirovim header-ima poruke. Definišega mejl klijent u trenutku slanja, i putuje sa porukom od servera do servera. To je datum slanja koji je deklarisao pošiljalac.

(Ako nikada niste gledali sirove header-e mejla, to je prililicno neobicno štivo. Svaka poruka vuci tridesetak tehnickih redova koje 99% ljudi nikada nije videlo.)

Tehnicki, ništa ne sprecava slanje mejla sa antidatiranim ili postdatiranim poljem Date:. SMTP serveri ne validiraju ovo polje. Ali odredišni serveri beleže stvarno vreme dolaska u Received: header-ima, što odmah stvara nekonzistentnost vidljivu svakom mejl klijentu ili alatu za analizu.

Sloj 3: nagomilani Received: header-i

Svaki put kada SMTP server prosledjuje poruku, dodaje Received: header na vrh gomile, sa vremenskim pečatom. Mejl koji je prošao kroz tri servera imaće tri Received: header-a. Citaju se odozdo prema gore: najstariji je dole, najnoviji gore.

Upravo tu migracioni alati prave problem. Kada BitTitan MigrationWiz, CloudM, imapsync ili GSMMO migriraju mejl, reinjekcijom ga ubacuju na novi server putem IMAP-a. Taj depozit generiše novi Received: unos sa vremenskim pečatom trenutka migracije. Rezultat: najstariji mejl u Vašem sandučetu, poruka iz 2019. godine, završava sa Received: datiranim novembrom 2024. A pošto odredjeni mejl klijenti (Outlook pre svega) koriste najnoviji Received: kao datum prikaza...

Eto problema. 15.000 mejlova prikazuje isti datum migracije.

Da li se ovi datumi zaista mogu "izmeniti"?

Tehnicki, da za INTERNALDATE (uz odredjena ogranicenja). Tehnicki moguce ali beskorisno za Date:. A za Received: header-e, vredi se malo zadržati.

Prepisivanje Received: header-a je trivijalno. I odmah detektabilno.

Jedan Received: header je samo red teksta u poruci. Može se editovati kao i svaki tekstualni fajl. Tacno onoliko jednostavno koliko izgleda.

Ali evo šta se dogadja zatim.

Prvi problem: DKIM. DKIM potpis (DomainKeys Identified Mail) se racuna na osnovu skupa header-a poruke, ponekad ukljucujuci i Received:. Izmena potpisanog header-a poništava potpis. Svaki odredišni server koji proverava DKIM odmah vidi da je poruka izmenjena. To nije suptilni falsifikat, to je alarm.

Drugi problem: interni identifikatori. Moderni mejl serveri (Google Workspace, Microsoft 365) dodeljuju svakoj poruci rastući jedinstveni interni identifikator. Ti identifikatori su vezani za INTERNALDATE i redosled prijema. Izmena Received: header-a bez konzistentnosti sa ovim identifikatorima stvara nekonzistentnosti koje alati za reviziju bez problema detektuju.

Treci problem, praktičniji: cak i ako izmenite Received: u sadržaju poruke, niste dirali INTERNALDATE, koji ostaje onaj od IMAP depozita. Mejl klijent i dalje prikazuje pogrešan datum za sortiranje. Izmenili ste poruku bez ikakve koristi.

Ukratko. Prepisivati Received: header-e radi falsifikovanja datuma mejla u maliciozne svrhe: trivijalno tehnicki, detektabilno za nekoliko sekundi od strane eksperta. Nije ozbiljan put.

Date: header: menjanje prošlosti na papiru

Isto rezonovanje važi i za Date:. Može se izmeniti u telu poruke. Ali Received: header-i autentifikovani od strane medjuservera ostaju netaknuti i pricaju drugu pricu. Vremenski lanac je nekonzistentan. Svaki analitičar ili sud koji uporedjuje ova polja to odmah vidi.

Da budemo precizni, ovo ne sprecava neke mejl klijente da prikazuju izmenjeni Date: ako im se direktno prezentuje .eml fajl. Ali u kontekstu live mejl servera, sa autentifikacijom i logovima, izmena je transparentna.

IMAP migracija: jedini kontekst gde je ispravka datuma opravdana

Postoji jedan, i samo jedan slucaj u kome izmena datuma prijema mejla nije samo moguca nego i tehnicki opravdana: ispravka štete nastale lošom IMAP migracijom.

Evo konkretne situacije. Upravo ste migrirali 80 Exchange sandučeta na Microsoft 365. Migracija je završena u petak uvece. U ponedeljak ujutru poceli su prvi tiketi: "Svi moji mejlovi imaju isti datum", "Ne mogu da nadjem mejl od prošle godine", "Cela istorija sa ovim klijentom je potpuno pokvarena". Imate 80 blokiranih korisnika i Vašeg nadredjenog koji ceka odgovor.

U ovom kontekstu, problem je dokumentovan, prepoznatljiv i uzrok mu je jasan: alat za migraciju dodao je Received: header datiran danom migracije, i odredjeni mejl klijenti koriste taj novi header kao datum prikaza. Originalni Date: header, medjutim, netaknut je u svakoj poruci. Nikad nije izmenjen. I dalje sadrži originalni datum slanja, ispravan.

Ispravka stoga nije falsifikovanje: to je restauracija. Krece se od tacnih podataka (originalni Date:) da bi se rekonstruisali konzistentni metapodaci. To je fundamentalno drugacije od pokušaja da se mejl iz 2024. predstavi kao mejl iz 2019.

Za konkretne slucajeve po alatima, ovi vodicima detaljno objasnjavaju primere: ispravka BitTitan datuma u Microsoft 365, ispravka CloudM datuma u Outlooku, ili ispravka imapsync datuma u Google Workspace-u.

Zašto ne pisati skriptu samostalno

Osnovna logika je dostupna. Svaki IT admin koji je proveo vreme na IMAP forumima može rekonstruisati opšti pristup. To nije problem.

Problem je jaz izmedju skripte koja radi na 50 test mejlova i skripte koja obradjuje 40.000 poruka u produkciji bez gubitka ijednog mejla, bez kvarenja ijednog attachment-a, i bez kvarenja ijednog niza konverzacije.

Nekoliko konkretnih slucajeva koje kucne skripte obicno ne rešavaju:

• S/MIME potpisani mejlovi: potpis pokriva sadržaj i header-e. Svaka izmena strukture poruke poništava potpis. Nespretno ispravljen potpisani mejl stiže kao "nevažeci potpis" kod primalaca.
• PGP enkriptovane poruke: ista porodica problema, sa potencijalno gorim posledicama zavisno od implementacije.
• Non-ASCII kodiranja u header-ima: RFC 2047 opisuje kodiranje specijalnih znakova u header-ima. Skripta koja manipuliše header-ima bez rukovanja ovim slucajevima ce tiho kvariti predmete mejlova sa akcentima, japanskim karakterima ili arapskim imenima.
• API rate limiti: Google Workspace i Microsoft 365 primenjuju agresivni throttling. U 3 ujutru, batch od 10.000 mejlova koji naleti na grešku 429 Too Many Requests bez eksponencijalnog backoff-a ostavlja pola sandučeta napola ispravljenih.
• Korumpovane MIME granice: multipart poruke sa attachment-ima imaju precizne MIME granice. Njihovo pogrešno regenerisanje cini attachment-e neitljivim.

I pitanje koje nijedna kucna skripta ne rešava: kako proveriti da je svaki ispravljeni mejl neoštecen? Skripta koja menja 40.000 poruka bez individualne verifikacije je kockanje. Kockanje sa podacima koje Vaši korisnici cesto smatraju nezamenljivim.

Za detaljan pregled opcija, ovaj clanak o ispravci datuma posle migracije istražuje razlicite pristupe, ukljucujuci i njihova ogranicenja.

Šta Redate.io radi u ovom kontekstu

Redate.io je dizajniran specificno za ovaj slucaj: ispravka datuma pokvarenih IMAP migracijom, u velikom obimu, bez rizika po integritet poruka.

Servis se direktno konekcuje na odgovarajuca sandučeta (Google Workspace putem domain delegation, Microsoft 365 putem Azure AD, ili direktnim IMAP-om), besplatno skenira poruke sa pogrešnim datumima, a zatim primenjuje vlasnicki pipeline ispravke koji rukuje granicnim slucajevima dokumentovanim gore. Svaki mejl se individualno verifikuje nakon ispravke. Originali ostaju u vidljivom backup folderu tokom 30 dana.

Prepoznavanje šablona pokriva stotine potpisa poznatih alata za migraciju: BitTitan MigrationWiz, CloudM, imapsync, GSMMO, i njihove varijante. Detekcija je precizna: Redate.io ne dirа mejlove sa ispravnim datumom.

Cenovni model je jednostavan: jednokratno placanje po sandučetu, bez pretplate. Dijagnosticki sken je besplatan, što omogucava procenu obima štete pre donošenja bilo kakve odluke.

Ako upravljate sandučetima pogodjenima ovim problemom, ovaj clanak o pogrešnim datumima u Outlooku posle migracije detaljno opisuje najcešce simptome i kako ih razlikovati od drugih uzroka.

Želite da vidite obim problema na Vašim sandučetima? Pokrenite besplatan sken na Redate.io i vidite tacno koliko mejlova je pogodjenо pre bilo kakve ispravke.