Outlooki profiili taasloomine: miks kuupäevad muutuvad

Tõrkeotsingu samm, mis lõhub kuupäevad

Kasutaja kaebab, et Outlook ei sünkroniseeri enam. Meilid ei saabu, Saadetud-kaust ei uuene, laadimisnupp keerutab lõputult. Tehnik diagnoosib rikutud profiili, kustutab OST-faili ja loob Outlooki profiili nullist uuesti. Tulemus: Outlook ühendub uuesti, meilid ilmuvad tagasi, kõik näib töötavat.

Kuni järgmise hommikuni, kui kasutaja avab postkasti ja märkab, et 8 aasta kirjavahetus näitab üht ja sama kuupäeva: täna.

See on täpselt sama sümptom nagu ebaõnnestunud IMAP-migratsioonis. Ja täpselt samadel põhjustel.

Mis täpselt toimub tehniliselt

Et mõista, miks profiili taasloomine selle tulemuse annab, tuleb meenutada üht eristust, mida enamik tehnikuid hästi ei tunne: erinevust meili Date:-päise ja selle IMAP-INTERNALDATE vahel.

Igal meilil on RFC 2822 päistes väli Date:, mis näitab, millal sõnum saadeti. Selle välja kirjutab saatja meiliklient saatmise hetkel ja see kandub muutumatul kujul läbi kõigi serverite teie postkasti. See ei muutu kunagi. Meil, mis saadeti 14. märtsil 2019 kell 09:32, kannab alati sama Date:-välja, olenemata sellest, mis hiljem juhtub.

IMAP-INTERNALDATE on midagi muud. See on serveri hallatav metaandmeid, mis on sõltumatu sõnumi sisust. See näitab, millal sõnum postkasti "deponeeriti". Tavatingimustes, kui meil saabub SMTP kaudu, salvestab server vastuvõtmisaja INTERNALDATE'ina. Meil, mis saabus 14. märtsil 2019, kannab seega INTERNALDATE'i, mis ühtib saatmiskuupäevaga.

Outlook sordib ja kuvab vaikimisi meilid IMAP-serveri edastatud INTERNALDATE järgi, mitte sõnumi enda Date:-välja järgi. (Muide, kui olete kunagi avanud Outlookis meili täielikud atribuudid toorpäiste vaatamiseks, siis teate, et see ei ole just rannalugemise materjal.)

Mida OST-faili kustutamine käivitab

Kui Outlook kasutab IMAP-kontot, haldab ta kohalikku andmebaasi: OST-faili (Offline Storage Table). See fail on serveris talletatud meilide kohalik peegel koos nende metaandmete, lugemisseisundite, kategooriatega jne.

OST-faili kustutamine tähendab selle kohaliku peegli kustutamist. Outlook peab kõik IMAP-serverist uuesti alla laadima.

Probleem? Kui Outlook laeb sõnumi IMAP kaudu uuesti alla, kasutab ta sisu toomiseks käsku FETCH. Kuid ta ei kasuta alati käsku FETCH INTERNALDATE, et tõmmata ja säilitada algne IMAP-kuupäev. Mõnedes Outlooki konfiguratsioonides ja versioonides ehitab klient oma kohaliku indeksi kasutades kuupäeva, millal sõnum alla laeti, mitte serveris talletatud INTERNALDATE'i.

Ja nii ongi: kõik postkasti meilid saavad ühelaadse uuslaadimise päeva kuupäeva.

Kõik Outlooki versioonid ei käitu ühtmoodi

Täpsustus: see käitumine ei mõjuta kõiki Outlooki versioone ühtemoodi, ja just see teeb diagnoosimise keeruliseks.

Outlook 2016 ja 2019 IMAP-režiimis on dokumenteeritud kalduvusega indeksi valeks rekonstrueerimiseks pärast vahemälu kustutamist. Uus Outlook (veebiplatvormil põhinev, mida hakati järk-järgult juurutama 2023. aasta lõpus) haldab vahemälu teisiti ja võib anda varieeruvaid tulemusi. Exchange'i/Microsoft 365 kaudu Exchange-režiimis seadistatud Outlook on selle probleemi suhtes vähem haavatav, kuna MAPI/Exchange-protokoll haldab sünkroniseerimist IMAP-ist erinevalt.

Kuid kui teie kasutaja kasutab klassikalises Outlookis seadistatud IMAP-kontot ja tehnik kustutas OST-faili või lõi profiili uuesti, on risk reaalne.

Kuidas eristada seda tõelisest migratsioonist

IT-administraator, kes saab pileteid "minu kuupäevad on valed" pärast profiili taasloomist, võib ekslikult arvata, et tegemist on migratsioonivigadega. Nii saab kahte juhtumit eristada.

IMAP-migratsiooni juhtum

IMAP-migratsiooni ajal (BitTitan, CloudM, imapsync jne) kopeerib migratsioonitööriist meilid ühelt serverilt teisele. Iga kopeeritud sõnumi jaoks loob see sihtserveris uue kirje käsu IMAP APPEND kaudu. Kui tööriist ei määra selles käsus selgesõnaliselt algset INTERNALDATE'i, salvestab sihtserver praeguse kellaaja INTERNALDATE'ina. Lisaks lisavad mõned tööriistad ka Received:-päise koos migratsiooni kuupäevaga, mis süvendab probleemi teatud klientides. Selle mehhanismi täpsema kirjelduse leiate artiklist IMAP INTERNALDATE ja katkised kuupäevad.

Profiili taasloomise juhtum

Siin on meilid endiselt samal serveril, samade algse INTERNALDATE'idega. Serveripoolel ei ole midagi muutunud. Ainult Outlooki kohalik vahemälu on rekonstrueeritud vale kuupäevaga. Nähtav sümptom on identne (kõik meilid näitavad sama hiljutist kuupäeva), kuid põhjus on erinev.

Kinnitamiseks: logige postkasti sisse veebimaili kaudu (Gmail, Outlook.com või teie hostimislahenduse veebiliides). Kui veebimailist nähtavad kuupäevad on õiged, on probleem puhtalt Outlooki-poolne. Kui kuupäevad on ka veebimailist vaadates valed, on probleem serveripoolne (migratsioon või INTERNALDATE'i muutmine serveris endas).

Miks algkuupäevad on taastataavad

Hea uudis: mõlemal juhul (nii migratsiooni kui profiili taasloomise korral) ei ole algkuupäevad kaotsi läinud.

RFC 2822 Date:-päis on sõnumi lahutamatu osa. See on sama muutumatu kui sõnumi tekst või manused. 2017. aastal saadetud meil sisaldab oma toortekstis midagi sellist:

Date: Mon, 12 Jun 2017 14:23:41 +0200

See rida on serveris talletatud sõnumis olemas. Seda ei ole muudetud. See, mida Outlook kuvab (valesti), on sõnumi sisust väline metaandmeid.

Just see teeb parandamise võimalikuks. Redate.io mootor analüüsib iga sõnumi päisteketti, et eraldada tegelik algkuupäev, seejärel teostab sihtotstarbelise metaandmete paranduse ilma sõnumi sisu muutmata. Outlooki poolt nähtav INTERNALDATE rekonstrueeritakse sellest autentsest teabest, mis on sõnumis alati olemas.

Lõks "puhta" taasloomisega

Te just lahendasite kasutaja sünkroniseerimisprobleemi. Tema Outlook töötab jälle, uued meilid saabuvad. Sulgete pileti.

Kolm päeva hiljem helistab kasutaja tagasi: ta otsib eelmise aasta tarnija meili, kuid Outlookis näivad kõik 2023. aasta meilid saabunud "eile". Ta ei leia midagi. Automaatne arhiveerimine võis uusi meile töödelda vanadena. Ja tema ülemus nõuab 2022. aasta septembrikuist meilivestlust vaidlusasjas.

See stsenaarium esineb regulaarselt. Mitte sellepärast, et tehnik tegi kehva tööd, vaid sellepärast, et see Outlooki käitumine ei ole standardsetes tõrkeotsingu juhendites selgelt dokumenteeritud.

Võltslahendused, mis ei aita

Meilide sortimine Outlookis "Vastuvõtukuupäeva" asemel "Saatmiskuupäeva" järgi on esimene asi, mida kasutajad proovivad. Ja näib toimivat... kuni nad märkavad, et saatmiskuupäeva järgi sortimine on saadaval ainult teatud kaustades, kaob vaate muutmisel ja et teised rakendused (mobiil, veebimeil, automaatsed sorteerimisreeglid) jätkavad vale INTERNALDATE'i kasutamist.

Saatmiskuupäeva järgi sortimine ei ole lahendus. See on plaaster, mis varjab sümptomit ilma tegelikku probleemi puudutamata. Selgitame seda üksikasjalikult artiklis Saatmiskuupäeva järgi sortimine ei lahenda probleemi.

Profiili teine kord uuesti luua? See ei muuda midagi, kui Outlooki käitumine rekonstrueerib vahemälu praeguse kuupäevaga.

Eksportida ja uuesti importida PST-na? Ettevaatust. PST-eksport valede kuupäevadega Outlookist ekspordib rikutud metaandmed. PST-fail sisaldab valesid kuupäevi. Selle faili uuesti importimine ei paranda midagi ja võib isegi olukorda halvendada, luues ebajärjekindlate kuupäevadega duplikaate. Seda teemat käsitletakse eraldi artiklis PST-import Outlookis: miks kõik kuupäevad lähevad katki.

Mida Redate.io teeb selles konkreetses juhtumis

Olgu probleem tingitud IMAP-migratsioonist või Outlooki profiili taasloomisest, serveripoolne tulemus on sarnane: meilid, mille kuupäeva metaandmed ei ühti nende tegeliku sisuga.

Redate.io ühendub otse postkastiga (Google Workspace, Microsoft 365 või otsene IMAP), skannib kõik sõnumid, et tuvastada need, mille metaandmed on valed, ning rakendab seejärel oma mitmeetapilist analüüsipipeline'i iga meili individuaalseks parandamiseks. Iga parandus kontrollitakse üle. Algkujul sõnumid säilitatakse nähtavas varukoopiakaustis, kuni te need kustutate.

Protsess käsitleb äärjuhtumeid, millega kodutehtud skriptid süstemaatiliselt hätta jäävad: S/MIME allkirjastatud sõnumid, päistes mitte-ASCII kodeeringutega meilid (RFC 2047), keerulised multipart-struktuurid, mittestandardsete või vigaselt vormistatud ajavöönditega Date:-päised. Skript, mis töötab korrektselt arenduspostkasti 50 testimeilil, võib tootmiskeskkonnas pöördumatult rikkuda 2000 sõnumit. IMAP-is ei ole natiivset tagasipööramise võimalust, kui sõnum on asendatud ilma eelneva varukoopiat tegemata.

Outlookiga seotud juhtumite jaoks kirjeldab paranduslehekülg käsitsi IMAP-kopeerimise kuupäevade parandamine Outlookis samme postkasti ühendamiseks ja analüüsi käivitamiseks.

Järgmiste sekkumiste ajal probleemi ennetamine

Kui olete tehnik või IT-administraator, kes tegeleb regulaarselt Outlooki profiilidega, aitavad mõned refleksid seda olukorda vältida.

Enne OST-faili kustutamist või profiili taasloomist kontrollige veebimailist kuvatavaid kuupäevi. Kui need on õiged, märkige see oma piletile. Pärast taasloomist logige uuesti veebimaili ja võrrelge seal kuvatavaid kuupäevi Outlooki omadega. Kui ilmneb erinevus, on probleem kohe tuvastatud, enne kui kasutaja kaebab kolme päeva pärast.

Planeeritud migratsioonide jaoks loetleb e-posti migratsiooni kuupäevaprobleemide ennetamise kontrollnimekiri kontrollid, mida teha enne ja pärast, et selline probleem operatsiooni lõpus kohe avastada.

Lõite Outlooki profiili uuesti ja kõik teie postkasti kuupäevad on nüüd valed? Käivitage tasuta skaneerimine Redate.io-s, et tuvastada mõjutatud meilid ja parandada metaandmed ilma sõnumite sisu puudutamata.