Svi stari emailovi imaju isti datum: što se dogodi?

Simptom: svi stari emailovi grupirani na isti datum

Otvorite Outlook, Gmail ili Apple Mail jednog jutra. Nešto ne štima. Stotine, ponekad tisuće starih emailova prikazuju isti datum: onaj od prije nekoliko dana ili nekoliko tjedana. Poruke iz 2021., iz 2019., iz 2016. pojavljuju se kao da su primljene jučer. Sortiranje po datumu više nema smisla. Tražite važan email od prošle godine, a on je zakopan u bloku tisuća poruka koje izgledaju kao da su sve stigle istog dana.

Novi emailovi i dalje prikazuju ispravne datume. Jedino su stare poruke pogođene.

Što se zapravo moglo dogoditi?

Prva reakcija: optužiti softver

Prirodno je pomisliti na bug. Outlook koji se srušio. Ažuriranje koje je krivo prošlo. Oštećena datoteka. I tu obično počinje pravi križ puta: tražite "bug datum Outlook", nailazite na forume koji govore o OST datotekama, SCANPST.exe, ponovnom stvaranju Outlook profila od nule...

Provedete dva sata pokušavajući sve. Problem ostaje.

Inače, SCANPST je alat za popravak lokalnih Outlook podatkovnih datoteka. Može popraviti određene oštećenja datoteke, ali ne dira podatke pohranjene na serveru za elektroničku poštu. Drugim riječima, čak i ako savršeno popravite svoju OST datoteku, datumi će i dalje biti krivi, jer problem nije na vašem računalu.

Problem je u samim emailovima, na serveru.

Što se zaista dogodilo: migracija

U gotovo svim slučajevima, ovaj simptom pojavljuje se nakon migracije elektroničke pošte. Vaša tvrtka prešla je sa starog sustava na Google Workspace, Microsoft 365 ili novi server. Netko je negdje upotrijebio alat za prijenos svih vaših emailova s jednog mjesta na drugo.

Možda niste bili obaviješteni. Ili jeste, ali niste povezali to s problemom datuma. Sasvim je normalno.

Ti alati za migraciju obavljaju ogroman posao: kopiraju tisuće poruka, cijele mape, privitke. No imaju jedan poprilično podmukao nuspojavu. Kada se email prenosi s jednog servera na drugi, alat dodaje mali tehnički redak u email, tzv. zaglavlje "Received:", koje označava kada je poruka stigla na novi server. To jest: datum migracije.

I tu leži korijen problema.

Kako vaš klijent za email 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 zaglavlja "Received:" koja bilježe svaki korak puta poruke Internetom.

(Ako ste ikad kliknuli na "Prikaži izvor" ili "Pogledaj cijela zaglavlja" nekog emaila, možda ste vidjeli te kriptične retke koji izgledaju kao nerazumljiv blok teksta. Upravo to je to.)

U normalnim okolnostima, vaš klijent za poštu gleda najnovije zaglavlje "Received:" kako bi odredio kada prikazati email. Ta logika savršeno funkcionira: zadnji "Received:" uvijek odgovara dolasku poruke u vašu pretinac, nekoliko sekundi nakon slanja.

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

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

Koji alati uzrokuju ovaj problem?

Najčešći alati za migraciju svi imaju ovo ponašanje. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (Googleov besplatni alat za migraciju iz Outlooka) i mnogi drugi. To zapravo nije pravi nedostatak s njihove strane: to je posljedica tehničkog funkcioniranja protokola elektroničke pošte. Ti alati dodaju to zaglavlje jer to protokol predviđa kada se poruka prenosi s jednog servera na drugi.

Problem je što nitko ne upozori korisnike da će se to dogoditi.

Ako je vaša tvrtka nedavno promijenila sustav pošte, ili je vaš IT odjel proveo "migraciju u oblak", to je vrlo vjerojatno uzrok problema. Možete provjeriti gledajući zahvaćene datume: odgovaraju li svi otprilike istom razdoblju? Ako da, to razdoblje je ono migracije.

Lažni trag: rješenja koja ne rade

Nekoliko rješenja koja se često nalaze na forumima, a ne funkcioniraju:

Popravak podatkovne datoteke pomoću SCANPST

Već smo to spomenuli: SCANPST popravlja lokalne Outlook datoteke (.pst ili .ost datoteke pohranjene na vašem računalu). Ne mijenja emailove na serveru. Nakon popravka, vaši emailovi i dalje će imati iste krive datume, jer su ti datumi u samim emailovima, a ne u lokalnoj datoteci.

Ponovno stvaranje Outlook profila

Ista logika. Stvaranje novog Outlook profila znači lokalni svježi start, pa potom preuzimanje svih emailova sa servera. Vaši preuzeti emailovi imat će točno iste krive datume kao i prije. Samo ste izgubili vrijeme na ponovnu konfiguraciju.

Sortiranje po "datumu slanja" umjesto "datumu primitka"

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

Ponovna instalacija klijenta za email

Ne. Emailovi su na serveru, ne u softveru. Ponovna instalacija Outlooka, Gmaila, Apple Maila ili Thunderbirda ne mijenja ništa na podacima pohranjenim na mreži.

Dobra vijest: pravi datumi su još uvijek tu

Evo nečeg važnog za razumjeti, što čini ispravak mogućim: originalni datum slanja svakog emaila nije izbrisan. I dalje je tu, u emailu, u zaglavlju zvanom "Date:", koje odgovara datumu slanja koji je odabrao pošiljatelj. To je standard elektroničke pošte (definiran tehničkom specifikacijom RFC 2822) koji svi alati za migraciju poštuju, jer bi ga mijenjanje bila ozbiljna povreda standarda.

Drugim riječima, ako ste primili email 14. ožujka 2022., taj email i dalje negdje u podacima sadrži taj datum. Samo više nije onaj koji vaš softver prikazuje kao prvi.

Upravo to čini ispravak mogućim. Problem nije gubitak podataka. Radi se o čitanju metapodataka: vaš klijent za poštu čita krivi datum, dok je pravi datum i dalje prisutan.

Zašto ne pokušati ispraviti to sami?

Možda se pitate može li informatičar jednostavno napisati skriptu za rješavanje problema. Razumjeti što se dogodi jedna je stvar. Ispravno ispraviti tisuće emailova bez da se izgubi ijedan sasvim je druga stvar.

Email nije jednostavna tekstualna datoteka. Može sadržavati privitke, digitalne potpise, sadržaj kodiran u složenim formatima. Mijenjanje metapodataka takve poruke bez narušavanja njene strukture zahtijeva rukovanje desetinama posebnih slučajeva: elektronički potpisane poruke (S/MIME), šifrirani emailovi (PGP), nestandardna kodiranja, strukture s višestrukim dijelovima... Kućna skripta koja radi na 20 testnih emailova vrlo vjerojatno neće ispravno raditi na produkcijskom pretincu od 15.000 poruka. A ako nešto krene po zlu, kako se može osigurati da nijedan email nije oštećen ili izgubljen? S kućnom skriptom: nemoguće.

Bez mehanizma sigurnosne kopije i pojedinačne provjere za svaki email, rizik od popratne štete je stvaran.

Što radi Redate.io

Redate.io je servis osmišljen specifično za ovaj problem. Spaja se na vaš pretinac (Google Workspace, Microsoft 365 ili IMAP server), identificira emailove čiji su datumi izmijenjeni migracijom i ispravlja ih putem vlasničkog mehanizma koji analizira cijeli lanac zaglavlja te rekonstruira metapodatke datuma za svaku poruku.

Svaki ispravljeni email verificira se pojedinačno. Originali se čuvaju u vidljivoj mapi sigurnosne kopije 30 dana. Ako nešto ne valja, možete se vratiti na prethodno stanje.

Početno skeniranje je besplatno: Redate.io analizira vaš pretinac i pokazuje točno koliko je emailova zahvaćeno prije nego što odlučite išta. Bez iznenađenja.

Cijena je jednokratna uplata, temeljena na volumenu emailova koje treba ispraviti. Bez pretplate. Platite jednom, problem je riješen.

Želite vidjeti razmjere štete prije nego što se odlučite? Pokrenite besplatno skeniranje vašeg pretinca na Redate.io i saznajte za nekoliko minuta koliko je emailova zahvaćeno.