Svi stari emailovi imaju isti datum: šta se dešava?

Simptom: svi stari emailovi grupisani na isti datum

Otvorite Outlook, Gmail ili Apple Mail jednog jutra. Nešto ne štima. Stotine, ponekad hiljade starih emailova prikazuju isti datum: onaj od pre nekoliko dana, ili od pre nekoliko nedelja. Poruke iz 2021, iz 2019, iz 2016. izgledaju kao da su primljene juče. Sortiranje po datumu više ništa ne znaci. Tražite važan email od prošle godine, a on je zatrpan u bloku hiljada poruka koje kao da su stigle istog dana.

Novi emailovi prikazuju ispravne datume. Samo stare poruke su pogođene.

Šta se tačno desilo?

Prva reakcija: optužiti softver

Prirodno je pomisliti na bag. Outlook koji se srušio. Ažuriranje koje je pošlo naopako. Oštećena datoteka. I tu često počinje borba bez kraja: pretražujete "bag datum Outlook", nailazite na forume koji govore o OST datotekama, o SCANPST.exe alatu, o tome da treba kreirati Outlook profil od nule...

Proveli ste dva sata isprobavajući sve. Problem ostaje.

Uzgred, SCANPST je alat za popravku lokalnih Outlook podatkovnih datoteka. Može ispraviti određena oštećenja fajlova, ali ne dira podatke sačuvane na serveru za elektronsku poštu. Drugim rečima, čak i ako savršeno popravite OST fajl, datumi će i dalje biti pogrešni, jer problem nije kod vas.

Problem je u samim vašim emailovima, na serveru.

Šta se zaista desilo: migracija

U ogromnoj većini slučajeva, ovaj simptom se pojavljuje nakon migracije elektronske pošte. Vaša kompanija je prešla sa starog sistema na Google Workspace, Microsoft 365, ili novi server. Neko je negde upotrebio alat da premesti sve vaše emailove s jednog mesta na drugo.

Možda niste ni bili obavešteni. Ili jeste, ali niste povezali to s problemom datuma. To je potpuno normalno.

Ovi alati za migraciju obavljaju ogroman posao: kopiraju hiljade poruka, čitave foldere, priloge. Ali imaju jedan podmukao nuspojav. Kada se email prenosi s jednog servera na drugi, alat dodaje mali tehnički red u email, takozvano "Received:" zaglavlje, koje beleži kada je poruka stigla na novi server. To jest: datum migracije.

I tu leži suština problema.

Kako vaš email klijent odlučuje koji datum prikazati

Email zapravo sadrži nekoliko različitih datuma, skrivenih u tehničkim podacima. Postoji originalni datum slanja (onaj koji normalno vidite), ali i "Received:" zaglavlja koja beleže svaki korak puta poruke kroz Internet.

(Ako ste ikada kliknuli na "Prikaži izvorni kod" ili "Pogledaj sva zaglavlja" nekog emaila, možda ste videli te kriptične redove koji liče na nerazumljiv blok teksta. Upravo to su ona zaglavlja.)

U normalnim okolnostima, vaš email klijent gleda najnovije "Received:" zaglavlje da bi odredio kada prikazati email. Ova logika radi savršeno: poslednje "Received:" uvek odgovara dolasku poruke u vaše sanduče, nekoliko sekundi nakon slanja.

Ali nakon migracije, ta logika se okreće protiv vas. Alat za migraciju je dodao novo "Received:" zaglavlje na sam vrh, s datumom prenosa. Vaš email klijent čita to zaglavlje prvo, vidi datum migracije i prikazuje ga. Originalni datum slanja je i dalje tu, netaknut, zakopan dublje u podacima emaila. Ali vaš klijent ga ne vidi, jer staje na prvom zaglavlju.

Rezultat: 8.000 emailova koji kao da su svi stigli istog utorka u novembru.

Koji alati izazivaju ovaj problem?

Najčešći alati za migraciju imaju svi ovo ponašanje. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (Googlov besplatni alat za migraciju iz Outlooka), i mnogi drugi. To zapravo nije greška s njihove strane: to je posledica tehničkog funkcionisanja email protokola. Ovi alati dodaju ovo zaglavlje jer to protokol predviđa kada se poruka prenosi s jednog servera na drugi.

Problem je što niko ne upozorava korisnike da će se to desiti.

Ako je vaša kompanija nedavno promenila sistem za elektronsku poštu, ili je IT odeljenje izvršilo "migraciju u oblak", to je vrlo verovatno uzrok problema. Možete to proveriti tako što ćete pogledati pogođene datume: da li svi odgovaraju otprilike istom periodu? Ako da, taj period je period migracije.

Lažni tragovi koje treba izbegavati

Nekoliko rešenja koja se često nalaze na forumima, a koja ne rade:

Popravka podatkovnog fajla pomoću SCANPST

Već smo to pomenuli: SCANPST popravlja lokalne Outlook fajlove (.pst ili .ost datoteke sačuvane na vašem računaru). Ne menja emailove na serveru. Nakon popravke, vaši emailovi će i dalje imati iste pogrešne datume, jer su ti datumi u samim emailovima, ne u lokalnom fajlu.

Kreiranje novog Outlook profila

Ista logika. Kreiranje novog Outlook profila znači polazak od prazne ploče lokalno, a zatim ponovo preuzimanje svih emailova sa servera. Ponovo preuzeti emailovi imaće potpuno iste pogrešne datume kao pre. Samo ste izgubili vreme rekonfigurisanjem svega.

Sortiranje po "datumu slanja" umesto "datumu prijema"

Neki forumi predlažu promenu kriterijuma sortiranja u Outlooku, prelazak s datuma prijema na datum slanja. To može pomoći u nekim slučajevima... ali ne uvek. I ne rešava ništa za druge softvere, druge uređaje, ili druge osobe koje pristupaju vašem sandučetu. Temeljni uzrok ostaje. Sortiranje po datumu slanja nije rešenje, to je flaster.

Ponovna instalacija email softvera

Ne. Emailovi su na serveru, ne u softveru. Ponovna instalacija Outlooka, Gmaila, Apple Maila ili Thunderbirda ne menja ništa na podacima sačuvanim u oblaku.

Dobra vest: pravi datumi su i dalje tu

Evo nečeg važnog za razumeti, a što čini ispravku mogućom: originalni datum slanja svakog emaila nije izbrisan. On je i dalje tu, u emailu, u zaglavlju pod nazivom "Date:" koje odgovara datumu slanja koji je odredio pošiljalac. To je email standard (definisan tehničkom specifikacijom zvanom RFC 2822) koji svi alati za migraciju poštuju, jer bi njegovo menjanje bilo ozbiljno kršenje standarda.

Drugim rečima, ako ste primili email 14. marta 2022, taj email još uvek negde u svojim podacima sadrži taj datum. Samo nije više onaj koji vaš softver prikazuje na prvom mestu.

To je upravo ono što čini ispravku mogućom. Problem nije gubitak podataka. Radi se o čitanju metapodataka: vaš email klijent čita pogrešan datum, dok je pravi datum i dalje prisutan.

Zašto ne pokušati ispraviti to sami?

Možda se pitate da li IT stručnjak može jednostavno napisati skriptu za rešavanje problema. Razumeti šta se dešava je jedno. Ispraviti to uredno na hiljadama emailova bez gubitka ijednog, to je sasvim druga priča.

Email nije jednostavan tekstualni fajl. Može sadržati priloge, digitalne potpise, sadržaj kodiran u složenim formatima. Menjanje metapodataka takve poruke bez narušavanja njene strukture zahteva upravljanje desetinama posebnih slučajeva: elektronski potpisane poruke (S/MIME), šifrovani emailovi (PGP), nestandardna kodiranja, višedelne strukture... Domaća skripta koja radi na 20 test emailova vrlo verovatno neće ispravno raditi na produkcionom sandučetu od 15.000 poruka. A ako nešto pođe naopako, kako se uveriti da nijedan email nije oštećen ili izgubljen? Sa domaćom skriptom: nemoguće.

Bez mehanizma rezervnih kopija i individualnog proveravanja svakog emaila, rizik od kolateralne štete je realan.

Šta radi Redate.io

Redate.io je servis dizajniran specifično za ovaj problem. Povezuje se s vašim sandučetom (Google Workspace, Microsoft 365, ili IMAP server), identifikuje emailove čiji su datumi izmenjeni migracijom i ispravlja ih putem vlasničkog mehanizma koji analizira ceo lanac zaglavlja i rekonstruiše metapodatke o datumu za svaku poruku.

Svaki ispravljeni email se proverava pojedinačno. Originali se čuvaju u vidljivom folderu za rezervnu kopiju tokom 30 dana. Ako nešto ne bude u redu, možete se vratiti unazad.

Početno skeniranje je besplatno: Redate.io analizira vaše sanduče i pokazuje vam tačno koliko emailova je pogođeno pre nego što se odlučite za bilo šta. Bez iznenađenja.

Cena je jednokratna uplata, zasnovana na obimu emailova koji treba ispraviti. Nema pretplate. Platite jednom, problem je rešen.

Želite da vidite razmere štete pre nego što se obavežete? Pokrenite besplatno skeniranje svog sandučeta na Redate.io i otkrijte za nekoliko minuta koliko emailova je pogođeno.