Uvoz PST v Outlook: zakaj se vsi datumi pokvarijo

Simptom: vsa vaša e-poštna sporočila so datirana z danes

Pravkar ste dokončali uvoz PST v Outlook. Napredek je dosegel 100 %, vse je šlo gladko. In potem odprete mapo Prejeto... vsako uvoženo sporočilo prikazuje današnji datum. Sporočilo iz leta 2019, drugo iz leta 2021, petletni arhiv: vsi nosijo isti datum. Dan uvoza.

To ni napaka prikaza. To ni težava s časovnim pasom. Gre za povsem dokumentirano vedenje, skladno z načinom, kako IMAP upravlja datumske metapodatke. Ampak za vsakogar, ki mora stara sporočila iskati po datumu, je to prava katastrofa.

Lokalni PST in IMAP: dva povsem različna svetova

Preden razložimo, zakaj se datumi pokvarijo, je treba razumeti, kaj PST datoteka pravzaprav je z vidika upravljanja datumov.

PST datoteka (Personal Storage Table) je Microsoftov lastniški format. Shranjuje e-pošto z vsemi metapodatki: datum pošiljanja, datum prejema, priloge, kategorije, oznake branja. Te metapodatke upravlja Outlook neposredno, neodvisno od katerega koli protokola za sporočila. Ko v Outlooku odprete PST brez povezave s strežnikom, prikazani datumi prihajajo neposredno iz notranjih polj PST datoteke. Do tu vse deluje pravilno.

Težava se pojavi, ko poskušate to vsebino prenesti v poštni nabiralnik, ki je gostovan na IMAP strežniku, bodisi Microsoft 365, Google Workspace ali kateri koli drug navaden ponudnik. Tam zapustite svet PST in vstopite v svet IMAP, kjer se pravila korenito spremenijo.

IMAP APPEND in INTERNALDATE: jedro problema

V IMAP ima vsako sporočilo, shranjeno na strežniku, dve vrsti datumskih podatkov:

• Glavo Date: (RFC 2822), ki je del vsebine sporočila samega. To je datum, ki ga je v sporočilo vpisal pošiljatelj.
• INTERNALDATE, ki je metapodatek, s katerim upravlja IMAP strežnik. Predstavlja trenutek, ko je bilo sporočilo shranjeno na strežnik. To vrednost Outlook uporablja za razvrščanje sporočil v pogledu "Datum prejema".

(Mimogrede, če ste kdaj poskusili brati surove glave e-pošte, veste, da to ni ravno lahkotno branje. A prav tam se vse dogaja.)

Ko sporočilo normalno prispe na vaš strežnik, poštni strežnik samodejno nastavi INTERNALDATE na točen trenutek prejema. Rezultat: datum, prikazan v Outlooku, ustreza temu, kdaj ste sporočilo prejeli.

Ko Outlook uvaža PST datoteko v IMAP nabiralnik, za pošiljanje vsakega sporočila na strežnik uporabi ukaz IMAP APPEND. Standard IMAP dovoljuje, da pri APPEND izrecno navedete INTERNALDATE. Toda Outlook tega ne stori. Sporočila pošlje brez določenega INTERNALDATE. IMAP strežnik v odsotnosti navodila uporabi privzeto pravilo: INTERNALDATE nastavi na trenutni čas, torej trenutek uvoza.

Rezultat: 8.000 uvoženih sporočil, 8.000 sporočil z današnjim datumom.

Zakaj se Outlook tako obnaša

To ni Microsoftova napaka. Gre za implementacijsko odločitev, ki je bila ob nastanku verjetno smiselna: v izvornem primeru uvoza PST uporabnik arhivira sporočila lokalno in jih "uvaža" v trenutni nabiralnik. Relevantni datum za razvrščanje bi bil izvirni datum prejema... a Microsoft se je odločil, da INTERNALDATE pri uvozu ne bo prenesel.

Da bomo natančni, to vedenje zadeva uvoz PST prek Outlookovega vgrajenega čarovnika (Datoteka > Odpri in izvozi > Uvozi/izvozi). Druge metode uvoza, kot so nekatera orodja tretjih strani ali migracije prek Exchange Admin Centra, se lahko obnašajo drugače, odvisno od implementacije IMAP APPEND.

To vedenje je znano in dokumentirano na Microsoftovih forumih že leta. Ni se spremenilo z Outlookom 2016, niti z Outlookom 2019, niti s trenutnimi različicami Microsoft 365. Uporabnik, ki danes uvaža PST, bo naletel točno na isti problem kot leta 2015.

Kako se to razlikuje od navadne IMAP selitve

Tu postane zanimivo, ker uvoz PST povzroči podoben rezultat kot navadna IMAP selitev z napačnimi datumi, a po drugačnem mehanizmu.

Pri tipični IMAP selitvi, na primer z BitTitan MigrationWiz ali imapsync, sporočila potujejo z izvornega IMAP strežnika na ciljnega. Orodje za selitev sporočila prenese in jih znova vstavi prek IMAP APPEND. Nekatera orodja pravilno ohranijo INTERNALDATE, druga ne. V vsakem primeru pa imajo sporočila že dodano glavo Received: z datumom selitve, kar lahko pri Outlooku zmede prikaz neodvisno od INTERNALDATE.

Pri uvozu PST je mehanizem preprostejši: ni dodane glave Received: iz selitve (PST datoteke ne potujejo prek vmesnega poštnega strežnika), toda INTERNALDATE preprosto nikoli ni nastavljen na pravilno vrednost. Vidni rezultat je enak, temeljni vzrok je rahlo drugačen.

Ta razlika ima neposredne posledice za popravek: pristop ni povsem enak, ne glede na to, ali obravnavate IMAP selitev ali uvoz PST. Glejte tudi zakaj INTERNALDATE povzroča pokvarjene datume za podrobno razlago obeh primerov.

Zakaj možnosti pogleda v Outlooku ne pomagajo

Tipična reakcija ob odkritju težave je brskanje po Outlookovih nastavitvah. In res obstaja nastavitev, ki se zdi obetavna: možnost razvrščanja sporočil po "Datumu" namesto po "Datumu prejema".

Razvrščanje po datumu pošiljanja ni rešitev. Je obliž.

Zakaj? Četudi spremenite razvrščanje za prikaz stolpca "Datum" (ki ustreza glavi Date: sporočila, torej izvirnemu datumu), ostane več težav:

• Outlookovo iskanje indeksira po INTERNALDATE. Iskanje "sporočila iz januarja 2020" ne bo vrnilo uvoženih sporočil iz januarja 2020, ker njihov INTERNALDATE kaže na dan uvoza.
• Mape "Danes", "Ta teden", "Ta mesec" v Outlookovem vmesniku temeljijo na INTERNALDATE, ne na glavi Date:.
• V spletnih vmesnikih (Outlook Web App, Gmail) in mobilnih odjemalcih prikazani datum in vedenje razvrščanja skoraj vedno temeljita na strežniškem INTERNALDATE.
• Pravila in samodejni filtri, ki se nanašajo na datum prejema, ne bodo delovali pravilno.

Skratka, sprememba pogleda reši prikaz za določenega uporabnika, na določenem odjemalcu, v določeni konfiguraciji. Težave pri viru ne popravi.

Ponovna sinhronizacija OST prav tako ne pomaga

Drugi klasičen poskus: izprazniti predpomnilnik OST in prisiliti popolno resinhronizacijo s strežnika. Ideja je, da morda težava izvira iz Outlookovega lokalnega predpomnilnika, ne s strežnika.

Napačna smer. Datoteka OST je lokalni predpomnilnik, ki odraža stanje IMAP strežnika. Če je INTERNALDATE napačen na strežniku, bo napačen v OST po resinhronizaciji. Brisanje OST ne spremeni podatkov, shranjenih na strežniku Exchange Online ali Google Workspace. Strežnik je avtoriteta.

Edini način za popravek datumov je popravljanje metapodatkov neposredno na strani strežnika, sporočilo za sporočilom. In prav tu postane ročno popravljanje zapleteno.

Težava z obsegom: 1 sporočilo je trivialno. 15.000 je druga zgodba

Tehnično gledano, če razumemo težavo, si lahko zamislimo skript, ki pregleduje nabiralnik, prebere glavo Date: vsakega sporočila in ustrezno popravi INTERNALDATE. Razumeti problem je eno. Popraviti 15.000 e-poštnih sporočil brez izgube enega samega je povsem drugo.

Nekaj realnih dejstev:

• Microsoft Graph in Gmail API uveljavljata omejitve hitrosti zahtevkov (rate limits). Naiven skript bo sprožil napake 429 Too Many Requests, prekinil izvajanje sredi popravljanja in pustil nabiralnik delno popravljenega, brez vednosti, katera sporočila so bila obdelana in katera ne.
• Nekatera sporočila v PST imajo lahko napačno oblikovane ali manjkajoče glave Date:. Skript brez upravljanja robnih primerov lahko taka sporočila pokvari ali tiho preskoči.
• Podpisana (S/MIME) ali šifrirana (PGP) e-poštna sporočila imajo dodatne omejitve glede celovitosti. Brezskrbno spreminjanje njihovih metapodatkov lahko razveljavi kriptografski podpis.
• Strukture multipart/alternative s kompleksnimi MIME mejami se včasih nepredvidljivo odzivajo na operacije spreminjanja.
• Brez mehanizma za povrnitev. Če gre kaj narobe sredi obdelave, kako se vrnete v začetno stanje?

Skript, ki deluje na 10 testnih sporočilih, ne bo deloval na produkcijskem nabiralniku s 50.000 sporočili. Lani je stranka s 40 GB PST arhivom poskušala to popraviti s Python skriptom, pobranim s Stack Overflowa. Rezultat: 3.000 podvojenih sporočil, 200 sporočil z nedostopnimi prilogami in dva tedna ročnega čiščenja.

Kaj Redate.io naredi v tem primeru

Redate.io analizira metapodatke vsakega sporočila v ciljnem nabiralniku, identificira sporočila z napačnimi datumi (vključno s tistimi, ki izvirajo iz uvoza PST) in izvede popravek prek lastninskega korektivnega mehanizma. Večstopenjski analizni cevovod primerja verigo glav vsakega sporočila, z validacijo RFC-skladnosti izlušči izvirni datum in izvede ciljano korekcijo metapodatkov brez spremembe vsebine sporočila.

Vsako popravljeno sporočilo je preverjeno posamično. Izvirniki so 30 dni shranjeni v vidni varnostni kopiji pred katero koli dokončno spremembo. Popravek deluje na treh glavnih platformah: Microsoft 365 (prek Azure AD), Google Workspace (prek domenske delegacije) in neposredno IMAP za navadne ponudnike.

Začetno skeniranje je brezplačno. Pokaže točno, koliko sporočil je prizadetih in kakšna je porazdelitev napačnih datumov, preden se odločite za karkoli.

Glejte tudi:

• Popravek datumov po selitvi Microsoft 365
• Outlook: datum prejema IMAP vs datum pošiljanja
• Ali se datumi e-pošte lahko popravijo po selitvi?

Uvoz PST je povozil vse datume vaše e-pošte? Brezplačno skenirajte nabiralnik na Redate.io in ugotovite obseg težave, preden ukrepate.