PST imports Outlook: kāpēc datumi kļūst nepareizi

Simptoms: visi e-pasti datēti ar šodienu

Jūs tikko pabeidzāt PST faila importēšanu Outlook. Progresa josla sasniedza 100 %, viss noritēja gludi. Tad jūs atverat iesūtni... un katrs importētais e-pasts rāda šodienas datumu. Ziņojums no 2019. gada, cits no 2021. gada, piecu gadu arhīvs - visi ar vienādu datumu. Importēšanas dienas datumu.

Tā nav attēlošanas kļūda. Tā nav laika joslas problēma. Tas ir pilnīgi dokumentēts uzvedības modelis, kas atbilst tam, kā IMAP pārvalda datuma metadatus. Taču tas joprojām ir katastrofa ikvienam, kam jāatrod vecie e-pasti pēc datuma.

Lokālais PST un IMAP: divas pilnīgi atšķirīgas pasaules

Pirms skaidrojam, kāpēc datumi tiek sabojāti, ir jāsaprot, kas ir PST fails no datumu pārvaldības viedokļa.

PST fails (Personal Storage Table) ir Microsoft patentēts formāts. Tas glabā e-pastus ar visiem to metadatiem: nosūtīšanas datumu, saņemšanas datumu, pielikumiem, kategorijām, lasīšanas indikatoriem. Šos metadatus Outlook pārvalda tieši, ārpus jebkura e-pasta protokola. Kad PST skats tiek atvērts Outlook bez savienojuma ar serveri, attēlotie datumi nāk tieši no PST faila iekšējiem laukiem. Tik tālu viss ir labi.

Problēma rodas, kad mēģina pārsūtīt šo saturu uz IMAP serverī mitinātu pastkasti - neatkarīgi no tā, vai tā ir Microsoft 365, Google Workspace vai kāds cits parastas hostinga pakalpojumu sniedzējs. Tur jūs atstājat PST pasauli un ienākat IMAP pasaulē, un noteikumi mainās radikāli.

IMAP APPEND un INTERNALDATE: problēmas kodols

IMAP protokolā katram serverī saglabātajam ziņojumam ir divu veidu datuma dati:

• Galvenes lauks Date: (RFC 2822), kas ir daļa no paša ziņojuma satura. Tas ir datums, ko nosūtītājs ierakstījis ziņojumā.
• INTERNALDATE - metadatu lauks, ko pārvalda IMAP serveris. Tas apzīmē brīdi, kad ziņojums tika ievietots serverī. Tieši šo vērtību Outlook izmanto, lai kārtotu ziņojumus skatā "Saņemšanas datums".

(Starp citu, ja kādreiz esat mēģinājuši lasīt e-pasta neapstrādātās galvenes, jūs zināt, ka tā nav tieši pludmales lasāmviela. Taču tieši tur viss notiek.)

Kad e-pasts normāli ierodas jūsu serverī, e-pasta serveris automātiski iestata INTERNALDATE uz precīzu saņemšanas brīdi. Rezultāts: Outlook rādītais datums atbilst tam, kad ziņojumu saņēmāt.

Kad Outlook importē PST failu uz IMAP pastkasti, tas izmanto komandu IMAP APPEND, lai nosūtītu katru ziņojumu serverim. IMAP standarts ļauj norādīt eksplicītu INTERNALDATE komandas APPEND izpildes laikā. Taču Outlook to nedara. Tas nosūta ziņojumus, nenorādot INTERNALDATE. IMAP serveris, saņemot ziņojumu bez norādījuma, piemēro noklusējuma noteikumu: INTERNALDATE tiek iestatīts uz pašreizējo laiku, tas ir, importēšanas brīdi.

Rezultāts: 8000 importētu e-pastu, 8000 e-pastu ar šodienas datumu.

Kāpēc Outlook tā rīkojas

Tā nav Microsoft aizmāršība. Tā ir ieviešanas izvēle, kas tolaik droši vien likās saprātīga: PST importēšanas sākotnējā lietošanas gadījumā lietotājs arhivē ziņojumus lokāli un tos "importē" savā pašreizējā pastkastē. Kārtošanai atbilstošais datums ir sākotnējais saņemšanas datums... taču Microsoft izvēlējās INTERNALDATE neizplatīt importēšanas operācijas laikā.

Precīzāk sakot, šī uzvedība attiecas uz PST importēšanu ar Outlook iebūvēto vedni (Fails > Atvērt un eksportēt > Importēt/Eksportēt). Citas importēšanas metodes, piemēram, daži trešo pušu rīki vai migrācijas, izmantojot Exchange administrēšanas centru, var uzvesties atšķirīgi atkarībā no to IMAP APPEND implementācijas.

Šī uzvedība ir zināma un dokumentēta Microsoft forumos jau gadiem. Tā nemainījās ar Outlook 2016, nedz ar Outlook 2019, nedz ar pašreizējām Microsoft 365 versijām. Lietotājs, kas šodien importē PST failu, saskarsies ar tieši to pašu problēmu kā 2015. gadā.

Kā tas atšķiras no parastas IMAP migrācijas

Šeit kļūst interesanti, jo PST importēšana rada rezultātu, kas līdzīgs parastajai IMAP migrācijai ar sabojātiem datumiem, bet ar atšķirīgu mehānismu.

Tipiskā IMAP migrācijā, piemēram, ar BitTitan MigrationWiz vai imapsync, e-pasti pārvietojas no avota IMAP servera uz galamērķa IMAP serveri. Migrācijas rīks izgūst ziņojumus un tos atkārtoti ievada, izmantojot IMAP APPEND. Daži rīki pareizi saglabā INTERNALDATE, citi - nē. Taču visos gadījumos ziņojumiem jau ir pievienots Received: galvenes lauks ar migrācijas datumu, kas var traucēt attēlošanu Outlook neatkarīgi no INTERNALDATE.

PST importēšanas gadījumā mehānisms ir vienkāršāks: migrācijas Received: galvenes lauks netiek pievienots (PST faili netransitē caur starpposma e-pasta serveri), taču INTERNALDATE vienkārši nekad netiek iestatīts uz pareizo vērtību. Redzamais rezultāts ir identisks, bet pamatcēlonis nedaudz atšķiras.

Šai atšķirībai ir tieša ietekme uz labošanu: pieeja nav pilnīgi identiska atkarībā no tā, vai tiek apstrādāta IMAP migrācija vai PST importēšana. Sk. arī kāpēc INTERNALDATE izraisa nepareizus datumus - detalizēts abu gadījumu skaidrojums.

Kāpēc Outlook skata opcijas neko nelabo

Tipiskā reakcija, atklājot šo problēmu, ir meklēt Outlook iestatījumos. Un tiešām ir viens parametrs, kas šķiet daudzsološs: iespēja kārtot e-pastus pēc "Datuma", nevis "Saņemšanas datuma".

Kārtošana pēc nosūtīšanas datuma nav risinājums. Tā ir ielāps.

Lūk, kāpēc: pat mainot kārtošanu, lai rādītu kolonnu "Datums" (kas atbilst ziņojuma galvenes laukam Date:, tātad sākotnējam datumam), vairākas problēmas saglabājas:

• Outlook meklēšana indeksē pēc INTERNALDATE. Meklēšana "e-pasti no 2020. gada janvāra" neatgriezīs importētos e-pastus no 2020. gada janvāra, jo to INTERNALDATE norāda importēšanas dienas datumu.
• Outlook interfeisa mapes "Šodien", "Šonedēļ", "Šomēnes" balstās uz INTERNALDATE, nevis galvenes lauku Date:.
• Tīmekļa saskarnēs (Outlook Web App, Gmail) un mobilajos klientos attēlotais datums un kārtošanas uzvedība gandrīz vienmēr ir atkarīga no servera INTERNALDATE.
• Automātiskie noteikumi un filtri, kas piemēroti saņemšanas datumam, nedarbosies pareizi.

Citiem vārdiem, skata maiņa atrisina attēlošanu konkrētam lietotājam, konkrētā klientā, konkrētā konfigurācijā. Tā nelabo problēmu pie tās cēloņa.

OST resinhronizācija arī nepalīdz

Vēl viens klasisks mēģinājums: iztīrīt OST kešatmiņu un piespiest pilnu resinhronizāciju no servera. Ideja ir tāda, ka problēma varētu būt Outlook lokālajā kešatmiņā, nevis serverī.

Nepareizs pieņēmums. OST fails ir lokāla kešatmiņa, kas atspoguļo IMAP servera stāvokli. Ja INTERNALDATE serverī ir nepareizs, pēc resinhronizācijas tas būs nepareizs arī OST failā. OST dzēšana neko nemaina datos, kas glabājas Exchange Online vai Google Workspace serverī. Serveris ir autoritāte.

Vienīgais veids, kā labot datumus, ir labot metadatus tieši servera pusē, ziņojums pēc ziņojuma. Un tieši tur manuāla veikšana kļūst sarežģīta.

Mēroga problēma: 1 e-pasts ir vienkārši. 15 000 - pavisam cita stāsts

Tehniski, ja problēma ir saprotama, varētu iedomāties uzrakstīt skriptu, kas šķērso pastkasti, nolasa katra ziņojuma galvenes lauku Date: un attiecīgi labo INTERNALDATE. Saprast problēmu ir viena lieta. Labot to 15 000 e-pastos, nezaudējot nevienu, ir pavisam cita lieta.

Daži praktiski fakti:

• Microsoft Graph un Gmail API uzliek pieprasījumu biežuma ierobežojumus (rate limits). Naivs skripts ģenerēs 429 Too Many Requests kļūdas, pārtrauks izpildi labošanas vidū un atstās daļēji labotu pastkasti - bez ziņas, kuri e-pasti apstrādāti un kuri nav.
• Daži e-pasti PST failā var saturēt nepareizi formatētus vai trūkstošus Date: galvenes laukus. Skripts bez šādu robežgadījumu apstrādes var sabojāt šos ziņojumus vai tos klusējot izlaist.
• Parakstīti (S/MIME) vai šifrēti (PGP) e-pasti ir papildu integritātes ierobežojumi. Metadatu maiņa bez piesardzības var anulēt kriptogrāfisko parakstu.
• Multipart/alternative struktūras ar sarežģītām MIME robežām dažkārt reaģē negaidīti uz modifikācijas operācijām.
• Nav atcelšanas mehānisma. Ja kaut kas noiet greizi apstrādes vidū, kā atgriezties sākotnējā stāvoklī?

Skripts, kas darbojas uz 10 testa e-pastiem, nedarbosies ražošanas pastkastē ar 50 000 ziņojumiem. Pagājušajā gadā klients ar 40 GB PST arhīvu mēģināja to labot ar Python skriptu, kas iegūts no Stack Overflow. Rezultāts: 3000 dublētu e-pastu, 200 ziņojumi ar nepieejamiem pielikumiem un divas nedēļas manuālas tīrīšanas.

Ko Redate.io dara šajā konkrētajā gadījumā

Redate.io analizē katra ziņojuma metadatus mērķa pastkastē, identificē e-pastus ar nepareiziem datumiem (ieskaitot tos, kas iegūti no PST importēšanas) un piemēro korekciju ar patentētu labošanas dzinēju. Daudzpakāpju analīzes cauruļvads salīdzina katra ziņojuma galvenes ķēdi, iegūst sākotnējo datumu ar RFC atbilstības validāciju un veic mērķtiecīgu metadatu korekciju, nemainot ziņojuma saturu.

Katrs labotais e-pasts tiek individuāli pārbaudīts. Oriģināli tiek saglabāti redzamā rezerves kopiju mapē 30 dienas pirms jebkādām galīgajām izmaiņām. Labošana darbojas visās trijās galvenajās platformās: Microsoft 365 (caur Azure AD), Google Workspace (caur domēna delegāciju) un tiešo IMAP parasto hostinga pakalpojumu sniedzēju gadījumā.

Sākotnējā skenēšana ir bezmaksas. Tā ļauj precīzi redzēt, cik e-pastu ir ietekmēti un kāda ir nepareizo datumu sadalījums - pirms jebkāda lēmuma pieņemšanas.

Sk. arī:

• E-pastu datumu labošana pēc Microsoft 365 migrācijas
• Outlook: IMAP saņemšanas datums vs nosūtīšanas datums
• Vai e-pastu datumus var labot pēc migrācijas?

PST importēšana pārrakstīja visus jūsu e-pastu datumus? Skenējiet savu pastkasti bez maksas vietnē Redate.io, lai novērtētu problēmas apmēru pirms rīcības.