Ponovna izgradnja profila Outlook: zakaj se datumi spremenijo

Poseg, ki odpravi težavo, a pokvari datume

Uporabnik se pritoži, da se Outlook ne sinhronizira več. E-pošta ne prihaja, mapa Poslano se ne posodablja, kolo se vrti v nedogled. Tehnik diagnosticira okvarjen profil, izbriše datoteko OST, od začetka ustvari nov profil Outlook. Rezultat: Outlook se znova poveže, e-poštna sporočila se prikažejo, vse deluje.

Do naslednjega jutra, ko uporabnik odpre nabiralnik in ugotovi, da 8 let korespondence prikazuje isti datum: danes.

To je točno isti simptom kot pri neuspeli IMAP migraciji. In iz istih razlogov.

Kaj se zgodi na tehnični ravni

Da bi razumeli, zakaj ponovna izgradnja profila povzroči ta rezultat, se moramo ustaviti pri razlikovanju, ki ga večina tehnikov slabo pozna: razlika med glavo Date: e-poštnega sporočila in njegovim IMAP INTERNALDATE.

Vsako e-poštno sporočilo vsebuje v svojih glavah RFC 2822 polje Date:, ki označuje, kdaj je bilo sporočilo poslano. To polje zapiše odjemalec pošiljatelja ob pošiljanju, nato pa potuje nespremenjeno skozi vse strežnike do vašega nabiralnika. Ne spremi se nikoli. Sporočilo, poslano 14. marca 2019 ob 9:32, bo vedno imelo to polje Date: nedotaknjeno, ne glede na to, kaj se zgodi pozneje.

IMAP INTERNALDATE je nekaj drugega. To je metapodatek, ki ga upravlja poštni strežnik, neodvisen od vsebine sporočila. Označuje, kdaj je bilo sporočilo "shranjeno" v nabiralnik. V normalnih razmerah, ko e-pošta prispe prek SMTP, strežnik zabeleži čas sprejema kot INTERNALDATE. Sporočilo, prejeto 14. marca 2019, bo imelo torej INTERNALDATE, ki je skladen z datumom pošiljanja.

Outlook privzeto razvršča in prikazuje e-pošto po INTERNALDATE, ki ga posreduje IMAP strežnik, ne po polju Date: v sporočilu samem. (Mimogrede, če ste kdaj odprli celotne lastnosti e-poštnega sporočila v Outlooku, da bi videli surove glave, veste, da to ni ravno sproščujoče branje.)

Kaj sproži brisanje datoteke OST

Ko Outlook uporablja IMAP račun, vzdržuje lokalno podatkovno zbirko: datoteko OST (Offline Storage Table). Ta datoteka je lokalno ogledalo e-poštnih sporočil, shranjenih na strežniku, z njihovimi metapodatki, stanji branja, kategorijami itd.

Brisanje datoteke OST je enako kot brisanje tega lokalnega ogledala. Outlook mora torej vse znova prenesti s strežnika IMAP.

Težava? Ko Outlook znova prenese sporočilo prek IMAP, za pridobitev vsebine uporabi ukaz FETCH. Toda ni sistematično, da bi uporabil ukaz FETCH INTERNALDATE za pridobitev in ohranitev originalnega IMAP datuma. Pri nekaterih konfiguracijah in različicah Outlooka odjemalec rekonstruira lokalni indeks z datumom, ko je sporočilo znova prenesel, namesto z INTERNALDATE, shranjenim na strežniku.

In takrat se vsa e-poštna sporočila v nabiralniku prikažejo z datumom ponovnega nalaganja.

Vse različice Outlooka se ne obnašajo enako

Pravzaprav ta težava ne prizadene vseh različic Outlooka na enak način, in prav tu postane diagnosticiranje zapleteno.

Outlook 2016 in 2019 v načinu IMAP imata dokumentirano napačno rekonstrukcijo indeksa po brisanju predpomnilnika. Novi Outlook (na osnovi spleta, ki se postopoma uvaja od konca leta 2023) upravlja predpomnilnik drugače in lahko daje spremenljive rezultate. Outlook prek Exchange/Microsoft 365 z računom, konfiguriranim v načinu Exchange, je manj izpostavljen tej specifični težavi, ker protokol MAPI/Exchange sinhronizacijo upravlja drugače kot IMAP.

Toda če je vaš uporabnik na IMAP računu, konfiguriranem v klasičnem Outlooku, in je tehnik izbrisal datoteko OST ali znova ustvaril profil: tveganje je realno.

Kako ločiti ta primer od prave migracije

IT skrbnik, ki prejme zahtevke "moji datumi so napačni" po ponovni izgradnji profila, lahko napačno sklepa, da gre za težavo z migracijo. Evo kako ločiti oba primera.

Primer IMAP migracije

Pri IMAP migraciji (BitTitan, CloudM, imapsync itd.) orodje za migracijo kopira e-pošto z enega strežnika na drugega. Za vsako kopirano sporočilo ustvari nov vnos na ciljnem strežniku prek ukaza IMAP APPEND. Če orodje v tem ukazu ne določi izvirnega INTERNALDATE, ciljni strežnik zabeleži trenutni čas kot INTERNALDATE. Poleg tega nekatera orodja dodajo tudi glavo Received: z datumom migracije, kar pri nekaterih odjemalcih stvar še poslabša. Podroben opis tega mehanizma je na voljo v članku IMAP INTERNALDATE: zakaj se datumi pokvarijo.

Primer ponovne izgradnje profila

Tukaj so e-poštna sporočila še vedno na istem strežniku, z enakimi originalnimi INTERNALDATE vrednostmi. Na strani strežnika se ni nič premaknilo. Samo lokalni predpomnilnik Outlooka je bil rekonstruiran z napačnimi datumi. Vidni simptom je enak (vsa e-poštna sporočila prikazujejo isti nedavni datum), toda izvor je drugačen.

Za potrditev: prijavite se v nabiralnik prek spletne pošte (Gmail, Outlook.com ali spletni vmesnik vašega gostitelja). Če so datumi v spletni pošti pravilni, je težava zgolj lokalna za Outlook. Če so datumi napačni tudi v spletni pošti, je težava na strani strežnika (migracija ali sprememba INTERNALDATE na strežniku).

Zakaj originalni datumi ostanejo obnovljivi

Dobra novica: v obeh primerih (migracija ali ponovna izgradnja profila) originalni datumi niso izgubljeni.

Glava Date: RFC 2822 je sestavni del sporočila. Je tako nespremenljiva kot besedilo ali priponke. E-poštno sporočilo, poslano leta 2017, v svoji surovi obliki vsebuje nekaj takega:

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

Ta vrstica je prisotna v sporočilu, shranjenem na strežniku. Ni bila spremenjena. Kar Outlook prikazuje (napačno) je metapodatek zunaj vsebine sporočila.

Prav to omogoča popravek. Redateov pogon za analizo pregleda verigo glav vsakega sporočila, iz nje izlušči pravi originalni datum, nato pa izvede ciljno korekcijo metapodatkov, ne da bi spremenil vsebino sporočila. INTERNALDATE, viden Outlooku, je rekonstruiran na osnovi te avtentične informacije, ki je v sporočilu vedno prisotna.

Past "čiste" ponovne izgradnje

Ravno ste odpravili težavo s sinhronizacijo za uporabnika. Njegov Outlook znova deluje, nova e-pošta prihaja. Zaprete zahtevek.

Tri dni pozneje vas uporabnik pokliče: išče e-poštno sporočilo od dobavitelja iz lanskega leta, toda v Outlooku se vsa njegova sporočila iz leta 2023 prikazujejo kot prejeta "včeraj". Ne najde ničesar. Samodejno arhiviranje je morda razvrstilo nedavna sporočila, ker jih je obravnavalo kot stara. In šef ga prosi za e-poštno korespondenco iz septembra 2022 za spor.

Ta scenarij se dogaja redno. Ne zato, ker bi tehnik slabo opravil svoje delo, ampak ker to vedenje Outlooka ni vidno dokumentirano v standardnih vodnikih za odpravljanje težav.

Navidezne rešitve, ki ne pomagajo

Razvrščanje e-pošte po "Datumu pošiljanja" namesto po "Datumu prejema" v Outlooku je prva stvar, ki jo uporabniki poskusijo. In zdi se, da deluje... dokler ne ugotovijo, da razvrščanje po datumu pošiljanja ni na voljo za vse mape, da izgine, ko spremenijo pogled, in da druge aplikacije (mobilna, spletna pošta, pravila za samodejno razvrščanje) še naprej uporabljajo napačni INTERNALDATE.

Razvrščanje po datumu pošiljanja ni rešitev. To je obliž, ki skrije simptom, ne da bi se dotaknil prave težave. Podrobno to razlagamo v članku Razvrščanje po datumu pošiljanja ni rešitev.

Znova ustvariti profil drugič? To nič ne spremeni, če Outlook še naprej rekonstruira predpomnilnik s trenutnim datumom.

Izvoz in ponoven uvoz v PST? Pozor. Izvoz PST iz Outlooka z pokvarjenimi datumi izvozi pokvarjene metapodatke. Datoteka PST bo vsebovala napačne datume. Ponoven uvoz te datoteke ne popravi ničesar in lahko stvar celo poslabša z ustvarjanjem dvojnikov z neskladnimi datumi. Ta tema je podrobno obravnavana v članku Uvoz PST v Outlook: zakaj se vsi datumi pokvarijo.

Kaj Redate.io stori v tem konkretnem primeru

Ne glede na to, ali težava izvira iz IMAP migracije ali ponovne izgradnje profila Outlook, je rezultat na strani strežnika podoben: e-poštna sporočila, katerih metapodatki datuma so neskladni z njihovo dejansko vsebino.

Redate.io se neposredno poveže z nabiralnikom (Google Workspace, Microsoft 365 ali neposreden IMAP), pregleda vsa sporočila, da identificira tista z napačnimi metapodatki, nato pa za vsako sporočilo posebej uporabi večstopenjski analitični cevovod za korekcijo. Vsak popravek je preverjen. Originalna sporočila ostanejo v vidni varnostni mapi vašega nabiralnika, dokler jih ne izbrišete sami.

Postopek obravnava robne primere, ki jih domači skripti sistematično spregledajo: S/MIME podpisana sporočila, e-pošta z ne-ASCII kodiranji v glavah (RFC 2047), kompleksne multipart strukture, glave Date: z nestandardnimi ali napačno oblikovanimi časovnimi pasovi. Skript, ki pravilno deluje na 50 testnih sporočilih v razvojnem nabiralniku, lahko v produkciji nepopravljivo pokvari 2000 sporočil. V IMAP ne obstaja nativni povratek, ko je sporočilo zamenjano brez predhodne varnostne kopije.

Za primere, specifične za Outlook, stran za popravek Popravek datumov ročnega IMAP kopiranja v Outlooku opisuje korake za povezavo nabiralnika in zagon analize.

Preprečevanje težave pri prihodnjih posegih

Če ste tehnik ali IT skrbnik in redno posegate v profile Outlook, vam bo par navad pomagalo, da se tej situaciji izognete.

Preden izbrišete datoteko OST ali znova ustvarite profil, preverite prikazane datume v spletni pošti. Če so pravilni, si to zabeležite v zahtevku. Po ponovni izgradnji se znova prijavite v spletno pošto in primerjajte datume z datumi v Outlooku. Če se pojavi razlika, je težava takoj identificirana, še preden se uporabnik pritoži tri dni pozneje.

Za načrtovane migracije kontrolni seznam selitve e-pošte navaja preverjanja, ki jih je treba opraviti pred selitivjo in po njej, da se tovrstne težave odkrijejo takoj po koncu operacije.

Znova ste ustvarili profil Outlook in datumi v vašem nabiralniku so zdaj vsi napačni? Zaženite brezplačno skeniranje na Redate.io, da identificirate prizadeta sporočila in popravite metapodatke, ne da bi se dotaknili vsebine vaših sporočil.