Visi vecie e-pasti ar vienādu datumu: kas notika?

Simptoms: visi vecākie e-pasti sagrupēti ar vienu datumu

Jūs atverat Outlook, Gmail vai Apple Mail kādu rītu. Kaut kas nekavējoties liek saraukt uzaci. Simtiem, dažkārt tūkstošiem vecāku e-pastu rāda vienu un to pašu datumu: pirms dažām dienām vai pirms dažām nedēļām. Ziņojumi no 2021. gada, 2019. gada, pat 2016. gada izskatās tā, it kā tie būtu saņemti vakar. Kārtošana pēc datuma vairs neko nozīmē. Meklējat svarīgu e-pastu no pagājušā gada, un tas noslīcis tūkstošu ziņojumu blokā, kas šķiet atnākuši vienā dienā.

Jaunākie e-pasti turpretī rāda pareizus datumus. Tikai vecākie ziņojumi ir skarti.

Kas īsti varēja notikt?

Pirmā reakcija: vainot programmatūru

Dabiski, ka pirmais pieņēmums ir kļūda programmā. Outlook avarēja. Kāds atjauninājums nostrādāja nepareizi. Bojāts fails. Un tieši te bieži sākas ilga izmeklēšanas taka: meklē "Outlook datuma kļūda", atrod forumus, kas runā par OST failiem, par SCANPST.exe, par profila izveidi no jauna...

Divas stundas, un problēma joprojām tur.

Starp citu, SCANPST ir Outlook lokālo datu failu labošanas rīks. Tas var novērst noteiktus failu bojājumus, taču neskar e-pastus, kas glabājas uz pasta servera. Citiem vārdiem: pat ja jūsu OST fails tiek izlabots ideāli, datumi joprojām būs nepareizi, jo problēma nav jūsu datorā.

Problēma ir pašos e-pastos, uz servera.

Kas patiesībā notika: migrācija

Gandrīz visos gadījumos šis simptoms parādās pēc e-pasta migrācijas. Jūsu uzņēmums pārgāja no vecās sistēmas uz Google Workspace, Microsoft 365 vai citu serveri. Kāds, kaut kur, izmantoja rīku, lai pārsūtītu visus jūsu e-pastus no vienas vietas uz otru.

Varbūt jums par to nemaz neteica. Vai teica, bet nesaistījāt ar datumu problēmu. Tas ir pilnīgi normāli.

Migrācijas rīki paveic milzīgu darbu: kopē tūkstošiem ziņojumu, veselas mapju struktūras, pielikumus. Taču tiem ir diezgan negaidīta blakusparādība. Kad e-pasts tiek pārsūtīts no viena servera uz citu, rīks pievieno nelielu tehnisko rindiņu e-pasta iekšienē, ko sauc par "Received:" galveni. Šī galvene norāda, kad ziņojums ienāca jaunajā serverī, tas ir: migrācijas datumu.

Un tur slēpjas viss mezgls.

Kā jūsu pasta klients izlemj, kuru datumu rādīt

E-pastā patiesībā ir vairāki dažādi datumi, paslēpti tā tehniskajos datos. Ir oriģinālais sūtīšanas datums (tas, ko parasti redzat), bet ir arī "Received:" galvenes, kas reģistrē katru ziņojuma ceļa posmu internetā.

(Ja esat kādreiz klikšķinājis uz "Rādīt avotu" vai "Skatīt pilnās galvenes" kādam e-pastam, iespējams, esat redzējis šīs kriptiskās rindiņas, kas izskatās kā nesaprotams tekstu bloks. Tas tieši arī ir.)

Parasti jūsu pasta programma skatās uz jaunāko "Received:" galveni, lai noteiktu, kuru datumu rādīt. Šī loģika darbojas lieliski: pēdējā "Received:" vienmēr atbilst ziņojuma ienākšanai jūsu kastē, dažas sekundes pēc nosūtīšanas.

Taču pēc migrācijas šī loģika vēršas pret jums. Migrācijas rīks ir pievienojis jaunu "Received:" galveni pašā augšā, ar pārsūtīšanas datumu. Jūsu pasta programma nolasa šo galveni pirmā, redz migrācijas datumu un to parāda. Oriģinālais sūtīšanas datums joprojām ir tur, neskarts, dziļāk e-pasta datos. Bet pasta programma to neredz, jo apstājas pie pirmās galvenes.

Rezultāts: 8000 e-pastu, kas šķiet saņemti vienā novembra otrdienā.

Kuri rīki izraisa šo problēmu?

Visizplatītākajiem migrācijas rīkiem ir šāda uzvedība. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (Google bezmaksas rīks migrēšanai no Outlook) un daudzi citi. Tas nav īsti viņu trūkums: tas ir e-pasta protokola tehniskās darbības sekas. Šie rīki pievieno šo galveni, jo tā paredz protokols, kad ziņojums tiek pārsūtīts no servera uz serveri.

Problēma ir tā, ka neviens nebrīdina lietotājus, ka tā notiks.

Ja jūsu uzņēmums nesen mainīja pasta sistēmu vai IT nodaļa veica "migrāciju uz mākoni", tas visticamāk ir problēmas cēlonis. Varat pārbaudīt, apskatot skartās datumus: vai tie visi atbilst aptuveni vienam un tam pašam periodam? Ja jā, tas ir migrācijas laiks.

Viltus risinājumi, no kuriem jāizvairās

Daži risinājumi, ko bieži atrod forumos un kas nedarbojas:

Datu faila labošana ar SCANPST

Kā jau minēts: SCANPST labo lokālos Outlook failus (jūsu datorā glabātie .pst vai .ost faili). Tas nemaina e-pastus uz servera. Pēc labošanas jūsu e-pastiem joprojām būs tādi paši nepareizi datumi, jo šie datumi atrodas pašos e-pastos, nevis lokālajā failā.

Outlook profila atjaunošana no jauna

Tā pati loģika. Profila atjaunošana no jauna nozīmē sākt no tukšas lapas lokāli, tad lejupielādēt visus e-pastus no servera vēlreiz. Lejupielādētajiem e-pastiem būs tieši tādi paši nepareizī datumi kā iepriekš. Jūs tikko tērējāt laiku, visu no jauna konfigurējot.

Kārtošana pēc "nosūtīšanas datuma" nevis "saņemšanas datuma"

Daži forumi iesaka mainīt kārtošanas kritēriju Outlook programmā, pārejot no saņemšanas datuma uz nosūtīšanas datumu. Tas dažkārt palīdz... bet ne vienmēr. Un tas neatrisina neko citām programmām, citām ierīcēm vai citiem cilvēkiem, kas piekļūst jūsu kastei. Dziļais cēlonis paliek. Kārtošana pēc nosūtīšanas datuma nav risinājums, tas ir ielāps.

Pasta programmatūras pārinstalēšana

Nē. E-pasti atrodas uz servera, nevis programmā. Outlook, Gmail, Apple Mail vai Thunderbird pārinstalēšana neko nemaina datos, kas glabājas tiešsaistē.

Labā ziņa: patiesie datumi joprojām ir tur

Šeit ir kaut kas svarīgs, ko saprast, un tas dara labošanu iespējamu: katra e-pasta oriģinālais sūtīšanas datums nav dzēsts. Tas joprojām atrodas e-pastā, galvenē, ko sauc par "Date:", kas atbilst sūtītāja izvēlētajam sūtīšanas datumam. Tas ir e-pasta standarts (definēts tehniskajā specifikācijā RFC 2822), ko visi migrācijas rīki ievēro, jo tā mainīšana būtu smags standartu pārkāpums.

Citiem vārdiem: ja saņēmāt e-pastu 2022. gada 14. martā, šis e-pasts joprojām satur šo datumu kaut kur savos datos. Tas vienkārši vairs nav tas, ko jūsu programma rāda pirmā.

Tieši tas padara labošanu iespējamu. Problēma nav datu zudums. Tā ir metadatu nolasīšanas jautājums: jūsu pasta programma nolasa nepareizo datumu, bet labais datums joprojām ir klāt.

Kāpēc nemēģināt to izlabot pašam?

Jūs varbūt domājat, vai IT speciālists var vienkārši uzrakstīt skriptu problēmas labošanai. Saprast, kas notiek, ir viena lieta. To pareizi izlabot tūkstošiem e-pastu, nezaudējot nevienu, ir pavisam cita.

E-pasts nav vienkāršs teksta fails. Tas var saturēt pielikumus, ciparparakstus, sarežģītos formātos kodētus saturus. Šāda ziņojuma metadatu mainīšana, nesabojājot struktūru, prasa rīkoties ar desmitiem īpašu gadījumu: elektroniski parakstīti ziņojumi (S/MIME), šifrēti e-pasti (PGP), nestandarta kodējumi, daudzkomponentu struktūras... Mājas skripts, kas darbojas uz 20 testa e-pastiem, ļoti iespējams nedarbosies pareizi uz 15 000 ziņojumu ražošanas kastē. Un ja kaut kas noiet greizi, kā pārliecināties, ka neviens e-pasts nav bojāts vai pazudis? Ar mājas skriptu: nekādi.

Bez rezerves kopijas un individuālas pārbaudes mehānisma katram e-pastam, blakus bojājumu risks ir reāls.

Ko dara Redate.io

Redate.io ir serviss, kas izstrādāts speciāli šai problēmai. Tas savienojas ar jūsu pasta kasti (Google Workspace, Microsoft 365 vai IMAP serveris), identificē e-pastus, kuru datumi migrācijas laikā tika mainīti, un tos izlabo ar patentētu labošanas dzinēju, kas analizē pilno galveņu ķēdi un rekonstruē katra ziņojuma datuma metadatus.

Katrs izlabotais e-pasts tiek pārbaudīts individuāli. Oriģināli tiek glabāti redzamā rezerves kopiju mapē 30 dienas. Ja kaut kas nav kārtībā, varat atgriezties atpakaļ.

Sākotnējā skenēšana ir bezmaksas: Redate.io analizē jūsu kasti un parāda tieši, cik e-pastu ir skarti, pirms jūs izlemjat ko darīt. Nav pārsteigumu.

Cenas modelis ir vienreizējs maksājums, pamatojoties uz labojamo e-pastu apjomu. Nav abonementa. Jūs maksājat vienu reizi, problēma ir atrisināta.

Vai vēlaties redzēt bojājumu apmēru, pirms apņematies? Palaidiet bezmaksas skenēšanu savā pasta kastē vietnē Redate.io un dažu minūšu laikā uzziniet, cik e-pastu ir skarti.