Kõik vanad meilid on sama kuupäevaga: mis juhtus?

Sümptom: kõik vanad meilid on koondunud sama kuupäeva alla

Avate Outlooki, Gmaili või Apple Maili hommikul. Midagi on valesti. Sajad, mõnikord tuhanded vanad meilid näitavad kõik sama kuupäeva: mõni päev või mõni nädal tagasi. 2021., 2019. ja 2016. aasta sõnumid näivad olevat saabunud eile. Kuupäeva järgi sorteerimine kaotab mõtte täielikult. Otsid mõnda möödunud aastast olulist kirja, aga see on maetud tuhandete sõnumite plokki, mis kõik näivad tulevat samast päevast.

Uued meilid näitavad õigeid kuupäevi. Ainult vanad sõnumid on mõjutatud.

Mis siin üldse juhtus?

Esimene reaktsioon: süüdistada tarkvara

Loomulikult mõtled kohe vea peale. Outlook jooksis kokku. Uuendus läks halvasti. Fail on rikutud. Ja just sellest algab tihti pikk peavalu: otsid "Outlooki kuupäevaviga", jõuad foorumitesse, kus räägitakse OST-failidest, SCANPST.exe tööriistast, Outlooki profiili nullist uuesti loomisest...

Kulutad kaks tundi kõike proovima. Probleem jääb alles.

Muide, SCANPST on Outlooki kohalike andmefailide parandamise tööriist. See parandab teatud failide riknemisi, kuid ei puutu meiliserveri andmeid. Teiste sõnadega: isegi kui parandate oma OST-faili täiuslikult, jäävad kuupäevad valeks, sest probleem ei ole teie arvutis.

Probleem on teie meilides endis, serveril.

Mis tegelikult juhtus: migratsioon

Valdaval enamikul juhtudest ilmneb see sümptom pärast meilimigratsiooni. Teie ettevõte vahetas vana süsteemi Google Workspace'i, Microsoft 365 või uue serveri vastu. Keegi kusagil kasutas tööriista, et kõik teie meilid ühest kohast teise kanda.

Võimalik, et teid ei teavitatud sellest. Või teadsite, aga ei seostanud seda kuupäevaprobleemiga. See on täiesti normaalne.

Migratsioonitööriistad teevad märkimisväärse töö: kopeerivad tuhaneid sõnumeid, terveid kaustasid, manuseid. Kuid neil on üks üsna varjatud kõrvalmõju. Kui meil kantakse ühelt serverilt teisele, lisab tööriist kirjasse väikese tehnilise rea, mida nimetatakse "Received:"-päiseks. See näitab, millal sõnum uuele serverile jõudis. Ehk siis: migratsiooni kuupäev.

Siin ongi kogu probleemi tuum.

Kuidas teie meilirakendus otsustab, millist kuupäeva näidata

Meil sisaldab tegelikult mitmeid erinevaid kuupäevi, mis on peidetud tema tehnilistes andmetes. On algne saatmiskuupäev (see, mida te tavaliselt näete), aga ka "Received:"-päised, mis salvestavad iga etapi sõnumi teekonnal üle interneti.

(Kui olete kunagi klõpsanud "Kuva allikas" või "Vaata täielikke päiseid", olete võib-olla näinud neid krüptilisi ridu, mis meenutavad arusaamatut tekstiplokki. Täpselt nii see ongi.)

Tavaliselt vaatab teie meilirakendus kõige värskemat "Received:"-päist, et otsustada, millal meili kuvada. See loogika toimib suurepäraselt: viimane "Received:" vastab alati sõnumi saabumisele teie postkasti, mõni sekund pärast saatmist.

Aga pärast migratsiooni pöördub see loogika teie vastu. Migratsioonitööriist lisas päris ülaossa uue "Received:"-päise koos ülekande kuupäevaga. Teie meilirakendus loeb seda päist esimesena, näeb migratsiooni kuupäeva ja kuvab selle. Algne saatmiskuupäev on ikka seal, puutumata, maetud meili andmetes madalamale. Kuid teie rakendus ei näe seda, sest peatub esimese päise peale.

Tulemus: 8000 meili, mis näivad kõik saabuvat samalt novembri teisipäevalt.

Millised tööriistad selle probleemi põhjustavad?

Kõigil levinumatel migratsioonitööriistadel on see käitumine. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (Google'i tasuta tööriist Outlookist migreerimiseks) ja paljud teised. See ei ole tegelikult nende viga: see on meiliprotokolli tehnilise toimimise tagajärg. Need tööriistad lisavad päise, sest protokoll näeb seda ette, kui sõnum kantakse ühelt serverilt teisele.

Probleem on selles, et keegi ei hoiata kasutajaid, et see juhtub.

Kui teie ettevõte vahetas hiljuti meiliplatvormi või teie IT-osakond tegi "pilvemigratsioon", on see väga tõenäoliselt probleemi allikas. Saate kontrollida, vaadates mõjutatud kuupäevi: kas need kõik vastavad ligikaudu samale perioodile? Kui jah, on see periood migratsiooni aeg.

Valeteede vältimine

Mõned lahendused, mida foorumites sageli pakutakse ja mis ei toimi:

Andmefaili parandamine SCANPST-iga

Mainisime seda juba: SCANPST parandab Outlooki kohalikke faile (.pst või .ost failid teie arvutis). See ei muuda serveril olevaid meile. Pärast parandamist on teie meilidel ikka samad valed kuupäevad, sest need kuupäevad on meilides endis, mitte kohalikus failis.

Outlooki profiili uuesti loomine

Sama loogika. Outlooki profiili uuesti loomine tähendab kohalikult tühja lehega alustamist, seejärel kõigi meilide serverist uuesti allalaadimist. Uuesti allalaaditud meilidel on täpselt samad valed kuupäevad nagu varemgi. Kaotatsite lihtsalt aega kõike uuesti seadistades.

Sortimine "saatmiskuupäeva" järgi "vastuvõtmiskuupäeva" asemel

Mõned foorumid soovitavad Outlookis sortimiskriteeriumit muuta, minnes vastuvõtukuupäevalt saatmiskuupäevale. See võib mõnel juhul aidata... aga mitte alati. Ja see ei lahenda midagi teiste rakenduste, seadmete ega teiste inimeste jaoks, kes teie postkastile ligi pääsevad. Põhjus jääb alles. Saatmiskuupäeva järgi sortimine ei ole lahendus, see on laastlapp.

Meilirakenduse uuesti installimine

Ei. Meilid on serveril, mitte rakenduses. Outlooki, Gmaili, Apple Maili või Thunderbirdi uuesti installimine ei muuda midagi veebis salvestatud andmetes.

Hea uudis: õiged kuupäevad on ikka olemas

Siin on midagi olulist mõista, ja see teeb parandamise võimalikuks: iga meili algne saatmiskuupäev ei ole kustutatud. See on ikka seal, kirjas, päises nimega "Date:", mis vastab saatja valitud saatmiskuupäevale. See on meilstandard (määratletud tehnilises spetsifikatsioonis nimega RFC 2822), mida kõik migratsioonitööriistad austavad, sest selle muutmine oleks standardite tõsine rikkumine.

Teiste sõnadega, kui saite meili 14. märtsil 2022, sisaldab see meil ikka seda kuupäeva kusagil oma andmetes. See lihtsalt ei ole enam see, mida teie rakendus esimesena kuvab.

See ongi täpselt see, mis parandamise võimalikuks teeb. Probleem ei ole andmekadu. See on metaandmete lugemise küsimus: teie meilirakendus loeb valet kuupäeva, samas kui õige kuupäev on ikka kohal.

Miks mitte proovida seda ise parandada?

Võib-olla mõtlete, kas IT-spetsialist saab lihtsalt kirjutada skripti probleemi parandamiseks. Aru saada, mis juhtub, on üks asi. Seda korralikult parandada tuhandete meilide peal, kaotamata ühtegi, on hoopis teine asi.

Meil ei ole lihtne tekstifail. See võib sisaldada manuseid, digitaalallkirju, keerukates vormingutes kodeeritud sisu. Sellise sõnumi metaandmete muutmine ilma seda lõhkumata nõuab kümnete erijuhtumite käsitlemist: elektrooniliselt allkirjastatud sõnumid (S/MIME), krüpteeritud meilid (PGP), mittestandardsed kodeeringud, mitmeosalised struktuurid... Kodutehtud skript, mis töötab 20 testimeilil, ei tööta tõenäoliselt korralikult 15 000 sõnumiga tootmispostkastis. Ja kui midagi läheb valesti, kuidas veenduda, et ühtegi meili ei ole kahjustatud ega kaotatud? Kodutehtud skriptiga: võimatu.

Ilma iga meili jaoks eraldi varundus- ja kontrollimehhanismita on kõrvalkahju risk reaalne.

Mida Redate.io teeb

Redate.io on teenus, mis on loodud spetsiaalselt selle probleemi jaoks. See ühendub teie postkastiga (Google Workspace, Microsoft 365 või IMAP-server), tuvastab meilid, mille kuupäevi migratsioon on muutnud, ja parandab need patenteeritud mootori abil, mis analüüsib päiste täielikku ahelat ja rekonstrueerib iga sõnumi kuupäeva metaandmed.

Iga parandatud meili kontrollitakse eraldi. Originaalid säilitatakse nähtavas varukaustas 30 päeva. Kui midagi läheb valesti, saate tagasi pöörduda.

Esialgne skaneerimine on tasuta: Redate.io analüüsib teie postkasti ja näitab täpselt, kui palju meile on mõjutatud, enne kui midagi otsustate. Üllatusi ei tule.

Hinnastamine põhineb ühekordsel maksel, lähtudes parandatavate meilide mahust. Tellimust ei ole. Maksate korra, probleem on lahendatud.

Tahate näha kahju ulatust enne otsustamist? Käivitage oma postkasti tasuta skannimine Redate.io lehel ja avastage mõne minutiga, kui palju meile on mõjutatud.