Promjena datuma primljenog emaila: tehničke granice

Email ima tri "datuma". Ne jedan.

Kad se govori o "promjeni datuma primljenog emaila", većina ljudi zamišlja izmjenu nekog polja, slično kao što bi promijenili datum nastanka datoteke u Windowsima. Stvarnost je nešto složenija. Email zapravo nosi tri odvojena sloja datiranja, svaki s vlastitim pravilima, vlastitim "čuvarima" i vlastitim posljedicama ako se u njega zadire.

Razumjeti ta tri sloja znači razumjeti zašto su neke ispravke tehnički ispravne, a druge su ili nemoguće ili odmah prepoznatljive kao krivotvorine.

Sloj 1: IMAP INTERNALDATE

INTERNALDATE je metapodatak pohranjen na strani servera, izvan samog emaila. Nije dio sadržaja poruke. Definira ga IMAP server, i upravo njega većina email klijenata koristi za sortiranje poruka u popisu.

Outlook, primjerice, poruke prikazuje sortirane prema INTERNALDATE. Gmail isto, u određenim situacijama. Zbog toga, ako je Vaš INTERNALDATE neispravan, svi emailovi u sučelju izgledaju kao da imaju isti datum, bez obzira što kažu interni zaglavlja poruke.

INTERNALDATE se postavlja u trenutku kad se poruka pohrani na server. Putem IMAP protokola, jedini način da ga "promijenite" je neizravan: treba koristiti naredbu APPEND kako biste pohranili novu kopiju poruke s željenim datumom. Ne postoji IMAP naredba SETINTERNALDATE. Taj detalj bit će važan za trenutak.

Sloj 2: zaglavlje Date: (RFC 2822)

To je polje Date: u sirovim zaglavljima poruke. Definira ga email klijent u trenutku slanja i putuje s porukom od servera do servera. Radi se o datumu slanja koji je deklarirao pošiljatelj.

(Inače, ako nikada niste pogledali sirova zaglavlja emaila, to je poprilično neobično iskustvo. Svaka poruka vuče dvadesetak tehničkih redaka koje 99 % korisnika nikada nije vidjelo.)

Tehnički, ništa ne sprječava slanje emaila s antidatiranim ili postdatiranim poljem Date:. SMTP serveri ne provjeravaju to polje. Ali odredišni serveri bilježe stvarno vrijeme primitka u zaglavljima Received:, što odmah stvara neusklađenost vidljivu bilo kojem email klijentu ili analitičkom alatu.

Sloj 3: nakupljena zaglavlja Received:

Svaki put kad SMTP server prosljeđuje poruku, dodaje zaglavlje Received: na vrh skupa, s vremenskom oznakom. Email koji je prošao kroz tri servera imat će tri zaglavlja Received:. Čitaju se odozdo prema gore: najstarije je na dnu, najnovije na vrhu.

Upravo tu alati za migraciju stvaraju problem. Kad BitTitan MigrationWiz, CloudM, imapsync ili GSMMO migriraju email, ubacuju ga na novi server putem IMAP-a. To ubacivanje generira novi unos Received: s vremenskom oznakom trenutka migracije. Rezultat: najstarija poruka u Vašem sandučiću, email iz 2019., dobiva Received: datiran u studeni 2024. A kako određeni email klijenti (Outlook prednjači) koriste najnoviji Received: kao datum prikaza...

Evo problema. 15.000 emailova prikazuje isti datum migracije.

Može li se zaista "promijeniti" te datume?

Tehnički, da za INTERNALDATE (uz ograničenja). Tehnički moguće ali beskorisno za Date:. A što se tiče Received:, vrijedi malo zastati.

Prepisati zaglavlje Received: trivijalno je. I odmah uočljivo.

Zaglavlje Received: samo je tekstualni redak u poruci. Može se uređivati kao bilo koja tekstualna datoteka. Točno toliko je jednostavno koliko izgleda.

Ali evo što se zatim dogodi.

Prvi problem: DKIM. DKIM potpis (DomainKeys Identified Mail) izračunava se na skupu zaglavlja poruke, ponekad uključujući Received:. Izmjena potpisanog zaglavlja poništava potpis. Bilo koji odredišni server koji provjerava DKIM odmah će vidjeti da je poruka izmijenjena. To nije suptilna falsifikacija, to je alarm.

Drugi problem: interni identifikatori. Moderni email serveri (Google Workspace, Microsoft 365) svakoj poruci dodjeljuju rastuće i jedinstvene interne identifikatore. Ti su identifikatori vezani uz INTERNALDATE i redoslijed primitka. Izmjena Received: bez usklađenosti s tim identifikatorima stvara neusklađenosti koje revizijski alati bez poteškoća otkrivaju.

Treći problem, praktičniji: čak i ako promijenite Received: u sadržaju poruke, niste dotaknuli INTERNALDATE, koji ostaje onaj od IMAP pohrane. Email klijent i dalje prikazuje pogrešan datum za sortiranje. Promijenili ste poruku uzalud.

Ukratko. Prepisivanje Received: zaglavlja radi krivotvorenja datuma emaila u zlonamjerne svrhe: trivijalno tehnički, uočljivo za nekoliko sekundi od strane stručnjaka. To nije ozbiljan put.

Zaglavlje Date: mijenjanje prošlosti na papiru

Isti zaključak vrijedi za Date:. Može se izmijeniti u tijelu poruke. Ali zaglavlja Received: ovjerena od međuposredničkih servera ostaju netaknuta i govore drugu priču. Vremenski lanac je neusklađen. Svaki analitičar ili sud koji uspoređuje ta polja to će odmah primijetiti.

Da budemo precizni, to ne sprječava određene email klijente da prikažu izmijenjeni Date: ako im se izravno predoči .eml datoteka. Ali u kontekstu aktivnog email servera, s autentikacijom i zapisnicima, izmjena je transparentna.

IMAP migracija: jedini kontekst u kojem je ispravak datuma opravdan

Postoji jedan, i samo jedan slučaj u kojem je izmjena datuma primitka emaila ne samo moguća već i tehnički opravdana: ispravak štete uzrokovane loše upravljanom IMAP migracijom.

Zamislite konkretnu situaciju. Upravo ste migrirali 80 Exchange sandučića na Microsoft 365. Migracija je završila u petak navečer. U ponedjeljak ujutro stižu prvi tiketi: "Svi moji emailovi imaju isti datum", "Ne mogu pronaći email od prošle godine", "Cijela povijest s tim klijentom je pokvarena". Imate 80 blokiranih korisnika i pretpostavljenog koji čeka odgovor.

U tom kontekstu, problem je dokumentiran, prepoznatljiv i uzrok je jasan: alat za migraciju dodao je Received: datiran danom migracije, a određeni email klijenti koriste to novo zaglavlje kao datum prikaza. Originalno zaglavlje Date: nedirnuto je u svakoj poruci. Nikada nije izmijenjeno. Još uvijek sadrži originalni, ispravni datum slanja.

Ispravak dakle nije krivotvorenje: to je obnova. Polazi se od točnih podataka (originalni Date:) kako bi se rekonstruirali usklađeni metapodaci. To je temeljno različito od pokušaja da se email iz 2024. prikaže kao email iz 2019.

Za detaljniji uvid u mehanizme specifične za svaki alat, ovi vodiči obrađuju konkretne slučajeve: ispravak datuma BitTitan u Microsoft 365, ispravak datuma CloudM u Outlooku, ili ispravak datuma imapsync u Google Workspaceu.

Zašto pisati vlastitu skriptu nije dobra ideja

Osnovna logika je dostupna. Svaki IT administrator koji je proveo neko vrijeme na IMAP forumima može rekonstruirati opći pristup. To nije problem.

Problem je razlika između skripte koja radi na 50 testnih emailova i skripte koja procesira 40.000 poruka u produkciji bez gubitka ijedne poruke, bez korupcije ijednog privitka i bez prekida ijednog niza razgovora.

Nekoliko konkretnih slučajeva koje domaće skripte obično ne obrađuju:

• S/MIME potpisani emailovi: potpis pokriva sadržaj i zaglavlja. Svaka izmjena strukture poruke poništava potpis. Nespretan ispravak potpisanog emaila dolazi do primatelja kao "nevažeći potpis".
• PGP šifrirane poruke: ista obitelj problema, s potencijalno gorima posljedicama ovisno o implementaciji.
• Non-ASCII kodiranja u zaglavljima: RFC 2047 opisuje kodiranje posebnih znakova u zaglavljima. Skripta koja manipulira zaglavljima bez rukovanja tim slučajevima tiho će pokvariti predmete emailova s naglascima, japanskim znakovima ili arapskim imenima.
• API ograničenja brzine: Google Workspace i Microsoft 365 primjenjuju agresivno usporavanje. U 3 ujutro, batch od 10.000 emailova koji naiđe na grešku 429 Too Many Requests bez upravljanja eksponencijalnim backoffom ostavlja polovicu sandučića napola ispravljenima.
• Pokvarene MIME granice: poruke s višestrukim dijelovima i privitcima imaju precizne MIME granice. Njihovo pogrešno regeneriranje čini privitke nečitljivima.

I pitanje koje nijedna domaća skripta ne rješava: kako provjeriti da je svaki ispravljeni email neokrnjen? Skripta koja mijenja 40.000 poruka bez individualnog provjere je kockanje. Kockanje s podacima koje Vaši korisnici često smatraju nezamjenjivima.

Članak o dostupnim opcijama za ispravak datuma nakon migracije istražuje različite pristupe, uključujući njihova odgovarajuća ograničenja.

Što Redate.io radi u tom kontekstu

Redate.io je dizajniran specifično za taj slučaj: ispravak datuma oštećenih IMAP migracijom, u velikom opsegu, bez rizika za integritet poruka.

Servis se izravno spaja na zahvaćene sandučiće (Google Workspace putem delegacije domene, Microsoft 365 putem Azure AD, ili izravno IMAP), besplatno skenira poruke s neispravnim datumima, zatim primjenjuje vlasnički pipeline za ispravak koji obrađuje rubne slučajeve dokumentirane gore. Svaki email se pojedinačno provjerava nakon ispravka. Originali ostaju u vidljivoj sigurnosnoj kopiji mape 30 dana.

Prepoznavanje uzoraka pokriva stotine potpisa poznatih alata za migraciju: BitTitan MigrationWiz, CloudM, imapsync, GSMMO i njihove varijante. Detekcija je precizna: Redate.io ne dirá emailove čiji je datum ispravan.

Model naplate je jednostavan: jednokratno plaćanje po sandučiću, bez pretplate. Dijagnostičko skeniranje je besplatno, što omogućuje procjenu opsega štete prije bilo kakve odluke.

Ako upravljate sandučićima zahvaćenim ovim problemom, ovaj članak o pogrešnim datumima u Outlooku nakon migracije detaljno opisuje najčešće simptome i kako ih razlikovati od drugih uzroka.

Spremni izmjeriti opseg problema na Vašim sandučićima? Pokrenite besplatno skeniranje na Redate.io i vidite točno koliko emailova je zahvaćeno prije bilo kakvog ispravka.