Vsi stari e-poštni sporočili imajo isti datum: kaj se dogaja?

Simptom: vsa stara sporočila se kopičijo pri istem datumu

Nekega jutra odprete Outlook, Gmail ali Apple Mail. Nekaj ni v redu. Stotine, včasih tisoče starih e-poštnih sporočil prikazuje isti datum: pred nekaj dnevi ali pred nekaj tedni. Sporočila iz leta 2021, 2019, 2016 se pojavljajo, kot da bi bila prejeta včeraj. Razvrščanje po datumu nič več ne pomeni ničesar. Iščete pomembno sporočilo izpred lanskega leta in ga ne najdete, ker je potopljeno v blok tisoč sporočil, ki zgleda, da so vsa prispela istega dne.

Nova e-poštna sporočila prikazujejo pravilne datume. Prizadeta so samo stara sporočila.

Kaj se je sploh zgodilo?

Prva misel: kriv je program

Seveda najprej pomislimo na hrošč. Outlook se je sesul. Posodobitev je šla narobe. Datoteka je poškodovana. In tu se pogosto začne boj: iščemo "napaka datum Outlook", naletimo na forume, ki govorijo o datotekah OST, o SCANPST.exe, o ponovni vzpostavitvi profila Outlook od začetka...

Porabimo dve uri za preizkušanje vsega. Težava ostane.

Mimogrede, SCANPST je orodje za popravilo lokalnih Outlookovih podatkovnih datotek. Popravi lahko določene poškodbe datotek, a ne dotakne se podatkov, shranjenih na poštnem strežniku. Z drugimi besedami: tudi če vaš OST popravite do popolnosti, datumi ostanejo napačni, ker težava ni pri vas.

Težava je v samih e-poštnih sporočilih, na strežniku.

Kar se je resnično zgodilo: selitev

V veliki večini primerov se ta simptom pojavi po selitvi e-pošte. Vaše podjetje je prešlo s starega sistema na Google Workspace, Microsoft 365 ali nov strežnik. Nekdo je uporabil orodje za prenos vseh vaših sporočil z enega mesta na drugo.

Morda vas o tem sploh niso obvestili. Ali pa ste vedeli, a niste povezali z datumsko težavo. To je popolnoma razumljivo.

Ta orodja za selitev opravijo obsežno delo: kopirajo tisoče sporočil, celotne mape, priponke. Ampak imajo precej zahrbtno stransko posledico. Ko se e-poštno sporočilo prenese z enega strežnika na drugega, orodje doda majhno tehnično vrstico v sporočilo, t. i. glavo "Received:", ki označuje, kdaj je sporočilo prispelo na novi strežnik. Torej: datum selitve.

In tu je jedro težave.

Kako vaš e-poštni odjemalec odloči, kateri datum prikazati

E-poštno sporočilo v resnici vsebuje več različnih datumov, skritih v tehničnih podatkih. Obstaja izvirni datum pošiljanja (tisti, ki ga normalno vidite), pa tudi glave "Received:", ki beležijo vsak korak poti sporočila po internetu.

(Če ste kdaj kliknili na "Prikaži vir" ali "Prikaži celotne glave" e-poštnega sporočila, ste morda videli te kriptične vrstice, ki izgledajo kot nerazumljiv blok besedila. Točno to so.)

V normalnih razmerah vaš e-poštni program pogleda najnovejšo glavo "Received:", da ugotovi, kdaj prikazati sporočilo. Ta logika deluje odlično: zadnja "Received:" glava vedno ustreza prihodu sporočila v vaš nabiralnik, torej nekaj sekund po pošiljanju.

Po selitvi pa se ta logika obrne proti vam. Orodje za selitev je dodalo novo glavo "Received:" na vrh, z datumom prenosa. Vaš e-poštni program prebere to glavo kot prvo, vidi datum selitve in ga prikaže. Izvirni datum pošiljanja je še vedno tam, neokrnjen, zakopan globlje v podatkih sporočila. Toda program ga ne vidi, ker se ustavi pri prvi glavi.

Rezultat: 8.000 sporočil, ki se zdijo, da so vsa prispela istega torkovega novembrskega dne.

Katera orodja povzročajo to težavo?

Najpogostejša orodja za selitev imajo vsa to vedenje. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (Googlovo brezplačno orodje za selitev iz Outlooka) in mnoga druga. To ni ravno pomanjkljivost njihove strani: je posledica tehničnega delovanja e-poštnega protokola. Ta orodja dodajo to glavo, ker to protokol zahteva, ko se sporočilo prenese z enega strežnika na drugega.

Težava je, da nihče ne opozori uporabnikov, da se bo to zgodilo.

Če je vaše podjetje nedavno zamenjalo e-poštni sistem ali je vaša IT ekipa izvedla "selitev v oblak", je to zelo verjetno izvor težave. Preverite lahko z ogledom prizadetih datumov: ali ustrezajo vsi priblizno istemu obdobju? Če da, je to obdobje selitve.

Lažne rešitve, ki jih je treba se izogniti

Nekatere rešitve, ki jih pogosto najdemo na forumih, a ne delujejo:

Popravilo podatkovne datoteke s SCANPST

Omenili smo že: SCANPST popravlja lokalne Outlookove datoteke (datoteke .pst ali .ost, shranjene na vašem računalniku). Ne spreminja sporočil na strežniku. Po popravilu bodo vaša sporočila imela enake napačne datume, ker so ti datumi v samih sporočilih, ne v lokalni datoteki.

Ponovna vzpostavitev profila Outlook

Enaka logika. Ponovna vzpostavitev profila Outlook pomeni lokalni začetek od začetka in nato ponoven prenos vseh sporočil s strežnika. Znova prenesena sporočila bodo imela popolnoma enake napačne datume kot prej. Samo čas ste izgubili s ponovnim nastavljanjem vsega.

Razvrščanje po "datumu pošiljanja" namesto "datumu prejema"

Nekateri forumi predlagajo spremembo merila razvrščanja v Outlooku, s prehoda z datuma prejema na datum pošiljanja. V nekaterih primerih to pomaga... toda ne vedno. In ne reši ničesar za druge programe, druge naprave ali druge osebe, ki dostopajo do vašega nabiralnika. Globoki vzrok ostane. Razvrščanje po datumu pošiljanja ni rešitev, je obliž.

Ponovna namestitev e-poštnega programa

Ne. Sporočila so na strežniku, ne v programu. Ponovna namestitev Outlooka, Gmaila, Apple Maila ali Thunderbirda ne spremeni ničesar pri podatkih, shranjenih v spletu.

Dobra novica: pravi datumi so še vedno tam

Tukaj je nekaj pomembnega, kar morate razumeti in kar popravek sploh omogoča: izvirni datum pošiljanja vsakega sporočila ni bil izbrisan. Še vedno je tam, v sporočilu, v glavi, ki se imenuje "Date:" in ustreza datumu pošiljanja, ki ga je izbral pošiljatelj. To je e-poštni standard (opredeljen v tehničnih specifikacijah, imenovanjih RFC 2822), ki ga vsa orodja za selitev spoštujejo, ker bi ga spremeniti pomenilo resno kršitev standardov.

Z drugimi besedami: če ste prejeli e-poštno sporočilo 14. marca 2022, to sporočilo nekje v svojih podatkih še vedno vsebuje ta datum. Samo to ni več tisto, kar vaš program prikaže najprej.

Prav to popravek sploh omogoča. Težava ni izguba podatkov. Je vprašanje branja metapodatkov: vaš e-poštni program bere napačen datum, medtem ko je pravi datum vedno prisoten.

Zakaj tega ne poskusiti popraviti sami?

Morda se sprašujete, ali bi informatik preprosto napisal skript za odpravo težave. Razumeti, kaj se dogaja, je ena stvar. Pravilno popraviti tisoče sporočil brez izgube enega samega je pa povsem druga stvar.

E-poštno sporočilo ni preprosta besedilna datoteka. Lahko vsebuje priponke, digitalne podpise, vsebino, kodirano v zapletenih formatih. Spreminjanje metapodatkov takšnega sporočila brez razpadanja zahteva obvladovanje desetine posebnih primerov: elektronsko podpisana sporočila (S/MIME), šifrirana e-poštna sporočila (PGP), nestandardne kodiranja, večdelne strukture... Domač skript, ki deluje na 20 testnih sporočilih, zelo verjetno ne bo pravilno deloval na produkcijskem nabiralniku s 15.000 sporočili. In če gre kaj narobe, kako zagotoviti, da nobeno sporočilo ni bilo poškodovano ali izgubljeno? Z domačim skriptom: nemogoče.

Brez mehanizma varnostnega kopiranja in individualne preverbe za vsako sporočilo je tveganje za kolateralno škodo resnično.

Kaj počne Redate.io

Redate.io je storitev, zasnovana posebej za to težavo. Poveže se z vašim nabiralnikom (Google Workspace, Microsoft 365 ali IMAP strežnik), identificira sporočila, katerih datumi so bili prizadeti pri selitvi, in jih popravi z lastninskim korektivnim mehanizmom, ki analizira celotno verigo glav in rekonstruira metapodatke datuma za vsako sporočilo.

Vsako popravljeno sporočilo je preverjeno posamično. Izvirniki so 30 dni hranjeni v vidni varnostni mapi. Če gre kaj narobe, se lahko vrnete nazaj.

Začetno skeniranje je brezplačno: Redate.io analizira vaš nabiralnik in vam natančno pokaže, koliko sporočil je prizadetih, preden se odločite karkoli. Brez presenečenj.

Cena je enkratno plačilo, ki temelji na obsegu sporočil za popravek. Brez naročnine. Plačate enkrat, težava je rešena.

Želite videti obseg škode, preden se odločite? Zaženite brezplačno skeniranje vašega nabiralnika na Redate.io in v nekaj minutah odkrijte, koliko sporočil je prizadetih.