Visi seni laiškai rodo tą pačią datą: kas nutiko?

Simptomas: visi seni laiškai sugrupuoti pagal tą pačią datą

Atidarote Outlook, Gmail ar Apple Mail vieną rytą. Kažkas ne taip. Šimtai, kartais tūkstančiai senų laiškų rodo tą pačią datą: prieš kelias dienas ar prieš kelias savaites. Žinutės iš 2021-ųjų, iš 2019-ųjų, iš 2016-ųjų atrodo tarsi gautos vakar. Rikiavimas pagal datą praranda bet kokią prasmę. Ieškote svarbaus laiško iš praėjusių metų, o jis paskęsta tarp tūkstančių žinučių, kurios, atrodo, visos atkeliavo tą pačią dieną.

Nauji laiškai rodo teisingas datas. Problema paliečia tik senus pranešimus.

Kas gi nutiko?

Pirma reakcija: kaltinti programinę įrangą

Natūralu pagalvoti apie klaidą. Outlook sugedo. Atnaujinimas nepasisekė. Failas sugadintas. Ir čia dažnai prasideda ilgas paieškos kelias: ieškote "Outlook datos klaida", tampate į forumus, kuriuose kalbama apie OST failus, SCANPST.exe, profilio Outlook kūrimą iš naujo...

Praleidžiate dvi valandas viską kartodami. Problema lieka.

Beje, SCANPST yra vietinių Outlook duomenų failų taisymo įrankis. Jis gali ištaisyti tam tikrus failo pažeidimus, tačiau nepaliečia duomenų, saugomų el. pašto serveryje. Kitaip tariant, net jei ištaisysite savo OST failą tobulai, datos liks klaidingos, nes problema yra ne jūsų pusėje.

Problema slypi pačiuose laiškuose, serveryje.

Kas iš tikrųjų nutiko: migracija

Beveik visais atvejais šis simptomas pasirodo po el. pašto migracijos. Jūsų įmonė perėjo nuo senos sistemos prie Google Workspace, Microsoft 365 ar naujo serverio. Kažkas, kažkur, panaudojo įrankį perkelti visus jūsų laiškus iš vienos vietos į kitą.

Galbūt jūsų apie tai neinformavo. Arba žinojote, bet nesusiejote su datų problema. Tai visiškai normalu.

Šie migracijos įrankiai atlieka didžiulį darbą: kopijuoja tūkstančius žinučių, ištisus aplankus, priedus. Tačiau jie turi gana klastingą šalutinį poveikį. Kai laiškas perkeliamas iš vieno serverio į kitą, įrankis į laišką prideda nedidelę techninę eilutę, vadinamą "Received:" antrašte, kuri nurodo, kada žinutė atkeliavo į naują serverį. Tai yra: migracijos data.

Ir štai čia slypi visa problema.

Kaip el. pašto programa nusprendžia, kurią datą rodyti

El. laiškas iš tikrųjų turi kelias skirtingas datas, paslėptas jo techninių duomenų viduje. Yra originali siuntimo data (ta, kurią paprastai matote), bet taip pat "Received:" antraštės, kurios fiksuoja kiekvieną žinutės kelionės etapą internete.

(Jei kada nors spustelėjote "Rodyti šaltinį" arba "Peržiūrėti visas antraštes" laiške, galbūt matėte tas kriptiškas eilutes, kurios atrodo kaip nesuprantamas teksto blokas. Tai kaip tik jos.)

Įprastai jūsų el. pašto programa žiūri į naujausią "Received:" antraštę, norėdama nustatyti, kada rodyti laišką. Ši logika veikia puikiai: paskutinė "Received:" visada atitinka žinutės atsiradimą jūsų dėžutėje, t. y. kelias sekundes po išsiuntimo.

Tačiau po migracijos ši logika ima veikti prieš jus. Migracijos įrankis pridėjo naują "Received:" antraštę pačiame viršuje, su perkėlimo data. Jūsų el. pašto programa pirmiausia perskaito šią antraštę, pamato migracijos datą ir ją rodo. Originali siuntimo data vis dar yra ten, nepaliesta, giliau laiško duomenyse. Tačiau programa jos nemato, nes sustoja ties pirmąja antrašte.

Rezultatas: 8 000 laiškų, kurie, atrodo, visi atkeliavo tą patį lapkričio antradienį.

Kokie įrankiai sukelia šią problemą?

Dažniausiai naudojami migracijos įrankiai visi turi šį elgesį. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (nemokamas Google įrankis migracijai iš Outlook) ir daugelis kitų. Tai nelabai galima vadinti jų trūkumu: tai el. pašto protokolo techninio veikimo pasekmė. Šie įrankiai prideda šią antraštę, nes taip protokolas ir numato, kai žinutė perkeliama iš vieno serverio į kitą.

Problema ta, kad niekas neperspėja naudotojų, jog taip nutiks.

Jei jūsų įmonė neseniai pakeitė el. pašto sistemą, arba jūsų IT tarnyba atliko "perkėlimą į debesį", tai labai tikėtina problemos priežastis. Galite patikrinti žiūrėdami į paveiktas datas: ar jos visos sutampa maždaug su tuo pačiu laikotarpiu? Jei taip, tas laikotarpis ir yra migracijos data.

Klaidingos pėdsakos, kurių geriau vengti

Keletas sprendimų, kuriuos dažnai rasite forumuose ir kurie neveikia:

Duomenų failo taisymas naudojant SCANPST

Minėjome aukščiau: SCANPST taiso vietinius Outlook failus (.pst arba .ost failus, saugomus jūsų kompiuteryje). Jis nekeičia laiškų serveryje. Po taisymo jūsų laiškai vis tiek turės tas pačias klaidingas datas, nes tos datos yra pačiuose laiškuose, o ne vietiniame faile.

Outlook profilio kūrimas iš naujo

Ta pati logika. Iš naujo sukurti Outlook profilį reiškia pradėti nuo švaraus lapo vietoje, tada iš naujo atsisiųsti visus laiškus iš serverio. Iš naujo atsisiųsti laiškai turės lygiai tas pačias klaidingas datas kaip anksčiau. Tiesiog sugaišote laiką viską konfigūruodami iš pradžių.

Rikiavimas pagal "siuntimo datą" vietoj "gavimo datos"

Kai kurie forumai siūlo keisti rikiavimo kriterijų Outlook programoje, perjungiant nuo gavimo datos prie siuntimo datos. Tai gali padėti kai kuriais atvejais... bet ne visada. Ir tai nieko neišsprendžia kitiems programiniams įrankiams, kitiems įrenginiams ar kitiems asmenims, turintiems prieigą prie jūsų el. pašto dėžutės. Pagrindinė priežastis lieka. Rikiavimas pagal siuntimo datą nėra sprendimas, tai tik pleistras.

El. pašto programos perinstaliavimas

Ne. Laiškai yra serveryje, o ne programoje. Outlook, Gmail, Apple Mail ar Thunderbird perinstaliavimas niekaip nepakeičia internete saugomų duomenų.

Gera žinia: tikrosios datos vis dar ten

Štai kas svarbu suprasti ir kas daro taisymą įmanomu: originali kiekvieno laiško siuntimo data nebuvo ištrinta. Ji vis dar yra laiške, antraštėje, vadinamoje "Date:", kuri atitinka siuntėjo pasirinktą siuntimo datą. Tai el. pašto standartas (apibrėžtas techninėje specifikacijoje RFC 2822), kurio visi migracijos įrankiai laikosi, nes jį keisti būtų rimtas standartų pažeidimas.

Kitaip tariant, jei gavote laišką 2022 m. kovo 14 d., tas laiškas vis dar kažkur savo duomenyse turi šią datą. Ji tiesiog nebėra ta, kurią jūsų programa rodo pirmiausia.

Būtent tai ir daro taisymą įmanomu. Problema nėra duomenų praradimas. Tai metaduomenų skaitymo klausimas: jūsų el. pašto programa skaito neteisingą datą, nors teisingoji data vis dar yra.

Kodėl neverta bandyti taisyti pačiam?

Galbūt klausiate, ar IT specialistas gali tiesiog parašyti skriptą šiai problemai išspręsti. Suprasti, kas vyksta, yra viena. Tinkamai tai ištaisyti su tūkstančiais laiškų neprarandant nė vieno yra visai kas kita.

El. laiškas nėra paprastas teksto failas. Jis gali turėti priedų, skaitmeninių parašų, turinio, užkoduoto sudėtingais formatais. Keisti tokio pranešimo metaduomenis jo nesugadinant reikalauja valdyti dešimtis ypatingų atvejų: elektroniškai pasirašytas pranešimas (S/MIME), šifruotas el. paštas (PGP), nestandartiniai kodavimai, kelių dalių struktūros... Naminis skriptas, kuris veikia su 20 bandomųjų laiškų, labai tikėtinai netinkamai veiks su 15 000 žinučių turinčia darbine dėžute. O jei kas nors nupuls, kaip įsitikinti, kad nė vienas laiškas nebuvo sugadintas ar pamestas? Su namiuku skriptu: neįmanoma.

Be atskiro atsarginės kopijos ir kiekvieno laiško tikrinimo mechanizmo, šalutinių pažeidimų rizika yra reali.

Ką daro Redate.io

Redate.io yra paslauga, sukurta specialiai šiai problemai spręsti. Ji prisijungia prie jūsų el. pašto dėžutės (Google Workspace, Microsoft 365 ar IMAP serverio), nustato laiškus, kurių datos buvo pakeistos migracijos metu, ir jas taiso naudodama patentuotą variklį, kuris analizuoja visą antraščių grandinę ir rekonstruoja kiekvieno pranešimo datos metaduomenis.

Kiekvienas pataisytas laiškas tikrinamas atskirai. Originalai saugomi matomame atsarginės kopijos aplanke 30 dienų. Jei kažkas negerai, galite grįžti atgal.

Pradinis nuskaitymas yra nemokamas: Redate.io analizuoja jūsų dėžutę ir parodo tiksliai, kiek laiškų yra paveikta, prieš jums priimant bet kokį sprendimą. Jokių staigmenų.

Kainodara paremta vienkartinis mokėjimu, atsižvelgiant į taisomų laiškų kiekį. Jokio prenumeratos. Mokate vieną kartą, problema išspręsta.

Norite pamatyti žalos mastą prieš įsipareigodami? Paleiskite nemokamą savo el. pašto dėžutės nuskaitymą Redate.io ir per kelias minutes sužinokite, kiek laiškų yra paveikta.