Uvoz PST u Outlook: zašto svi datumi postaju danas

Simptom: svi vaši e-mailovi datiraju od danas

Upravo ste završili uvoz PST datoteke u Outlook. Traka napretka dostigla je 100 %, sve je prošlo glatko. I onda otvorite ulaznu poštu... i svaki uvezeni e-mail prikazuje današnji datum. Poruka iz 2019., druga iz 2021., arhiva stara pet godina: sve nosi isti datum. Datum dana uvoza.

Ovo nije vizualni bug. Nije problem s vremenskim pojasom. To je ponašanje savršeno dokumentirano, konzistentno s načinom na koji IMAP upravlja metapodacima datuma. Ali ostaje katastrofa za svakoga tko treba pronaći stare e-mailove po datumu.

Lokalni PST i IMAP: dva potpuno različita svijeta

Prije nego što objasnimo zašto se datumi kvare, treba razumjeti što je PST datoteka sa stajališta upravljanja datumima.

PST datoteka (Personal Storage Table) je Microsoftov vlasnički format. Pohranjuje e-mailove s potpunim metapodacima: datum slanja, datum primitka, privitke, kategorije, zastavice čitanja. Tim metapodacima upravlja Outlook izravno, neovisno o bilo kojem protokolu za razmjenu poruka. Kada pregledavate PST u Outlooku bez veze na server, prikazani datumi dolaze izravno iz internih polja PST datoteke. Do tu sve štima.

Problem nastaje kada pokušate prenijeti taj sadržaj u poštanski sandučić koji se nalazi na IMAP serveru, bio to Microsoft 365, Google Workspace ili bilo koji uobičajeni hosting. Tada napuštate PST svijet i ulazite u IMAP svijet, a pravila se drastično mijenjaju.

IMAP APPEND i INTERNALDATE: srž problema

U IMAP-u svaka poruka pohranjena na serveru ima dvije vrste podataka o datumu:

• Zaglavlje Date: (RFC 2822), koje je dio samog sadržaja poruke. To je datum koji je pošiljatelj upisao u poruku.
• INTERNALDATE, koji je metapodatak kojim upravlja IMAP server. Predstavlja trenutak kada je poruka položena na server. Ova vrijednost je ono što Outlook koristi za sortiranje poruka u prikazu "Datum primitka".

(Inače, ako ste ikad pokušali čitati sirova zaglavlja e-maila, znate da to nije baš lektira za plažu. Ali upravo se tu sve događa.)

Kada e-mail normalno stigne na vaš server, poslužitelj automatski postavlja INTERNALDATE na točan trenutak primitka. Rezultat: datum prikazan u Outlooku odgovara tome kada ste primili poruku.

Kada Outlook uvozi PST datoteku u IMAP sandučić, koristi naredbu IMAP APPEND za slanje svake poruke na server. IMAP standard dopušta navođenje eksplicitnog INTERNALDATE-a prilikom APPEND operacije. Ali Outlook to ne radi. Šalje poruke bez navođenja INTERNALDATE-a. Server, bez ikakvih uputa, primjenjuje zadano pravilo: INTERNALDATE se postavlja na trenutno vrijeme, tj. trenutak uvoza.

Rezultat: 8.000 uvezenih e-mailova, 8.000 e-mailova s današnjim datumom.

Zašto se Outlook ponaša na ovaj način

Ovo nije Microsoftov propust. To je implementacijski izbor koji je vjerojatno izgledao razumno u to vrijeme: u izvornom slučaju uporabe uvoza PST-a, korisnik arhivira poruke lokalno i "uvozi" ih u svoju trenutnu poštu. Relevantan datum za sortiranje je tada originalni datum primitka... ali Microsoft je odlučio ne prenijeti INTERNALDATE tijekom operacije uvoza.

Da budemo precizni, ovo ponašanje odnosi se na uvoz PST-a putem nativnog čarobnjaka Outlooka (Datoteka > Otvori i izvezi > Uvezi/Izvezi). Druge metode uvoza, poput nekih alata trećih strana ili migracija putem Exchange Admin Centra, mogu se ponašati drugačije ovisno o njihovoj implementaciji IMAP APPEND.

Ovo ponašanje je poznato i dokumentirano na Microsoftovim forumima godinama. Nije se promijenilo s Outlookom 2016., ni s Outlookom 2019., ni s trenutnim verzijama Microsoft 365. Korisnik koji danas uvozi PST naići će na potpuno isti problem kao 2015.

Kako se ovo razlikuje od klasične IMAP migracije

Ovdje postaje zanimljivo, jer uvoz PST-a daje sličan rezultat kao klasična IMAP migracija s pokvarenim datumima, ali putem drugačijeg mehanizma.

U tipičnoj IMAP migraciji, recimo s BitTitan MigrationWiz ili imapsync, e-mailovi prelaze s izvornog IMAP servera na odredišni IMAP server. Alat za migraciju dohvaća poruke i reinjectira ih putem IMAP APPEND. Neki alati ispravno čuvaju INTERNALDATE, drugi ne. Ali u svakom slučaju, poruke već imaju zaglavlje Received: s datumom migracije dodanim usput, što može poremetiti prikaz u Outlooku neovisno o INTERNALDATE-u.

Kod uvoza PST-a mehanizam je jednostavniji: nema dodanog zaglavlja Received: od migracije (PST datoteke ne prolaze kroz posredni server za poštu), ali INTERNALDATE jednostavno nikad nije postavljen na ispravnu vrijednost. Vidljivi rezultat je identičan, a temeljna uzrok je nešto drugačiji.

Ova razlika ima izravne posljedice na ispravak: pristup nije posve isti ovisno o tome radi li se o IMAP migraciji ili uvozu PST-a. Pogledajte i zašto INTERNALDATE uzrokuje pokvarene datume za detaljno objašnjenje obaju slučajeva.

Zašto opcije prikaza u Outlooku ne rješavaju ništa

Uobičajena reakcija kada otkrijete problem je kopanje po postavkama Outlooka. I postoji postavka koja izgleda obećavajuće: mogućnost sortiranja e-mailova po "Datumu" umjesto po "Datumu primitka".

Sortiranje po datumu slanja nije rješenje. To je flaster.

Evo zašto: čak i ako promijenite sortiranje na prikaz stupca "Datum" (koji odgovara zaglavlju Date: poruke, dakle originalnom datumu), ostaje nekoliko problema:

• Outlookova pretraga indeksira prema INTERNALDATE-u. Pretraga za "e-mailovi iz siječnja 2020." neće vratiti vaše uvezene e-mailove iz siječnja 2020., jer njihov INTERNALDATE kaže da datiraju od dana uvoza.
• Mape "Danas", "Ovaj tjedan", "Ovaj mjesec" u Outlookovom sučelju temelje se na INTERNALDATE-u, ne na zaglavlju Date:.
• U web sučeljima (Outlook Web App, Gmail) i na mobilnim klijentima prikazani datum i ponašanje sortiranja gotovo uvijek ovise o INTERNALDATE-u servera.
• Pravila i automatski filtri primijenjeni na datum primitka neće ispravno raditi.

Ukratko, promjena prikaza rješava prikaz za određenog korisnika, na određenom klijentu, u određenoj konfiguraciji. Ne ispravlja problem na izvoru.

Ni re-sinkronizacija OST-a ne pomaže

Još jedan klasičan pokušaj: ispražniti OST predmemoriju i prisiliti potpunu re-sinkronizaciju sa servera. Ideja je da problem možda dolazi iz lokalne Outlookove predmemorije, a ne sa servera.

Pogrešan trag. OST datoteka je lokalna predmemorija koja odražava stanje IMAP servera. Ako je INTERNALDATE pogrešan na serveru, bit će pogrešan u OST-u nakon re-sinkronizacije. Brisanje OST-a ne mijenja podatke pohranjene na Exchange Online ili Google Workspace serveru. Server je onaj koji ima autoritet.

Jedini način ispravka datuma je ispraviti metapodatke izravno na strani servera, poruku po poruku. I upravo tu postaje komplicirano raditi ručno.

Problem razmjera: 1 e-mail je trivijalan. 15.000 je sasvim druga priča

Tehnički, ako razumijemo problem, mogli bismo zamisliti pisanje skripte koja prolazi kroz sandučić, čita zaglavlje Date: svake poruke i ispravlja INTERNALDATE u skladu s tim. Razumjeti problem je jedno. Ispraviti ga na 15.000 e-mailova bez gubitka ijednog je nešto sasvim drugo.

Nekoliko realnosti iz prakse:

• Microsoft Graph i Gmail API-ji nameću ograničenja broja zahtjeva (rate limits). Naivna skripta će izazvati greške 429 Too Many Requests, prekinuti izvođenje usred ispravka i ostaviti Vam sandučić djelomično ispravljen, bez informacije koji su e-mailovi obrađeni a koji nisu.
• Neki e-mailovi u PST-u mogu imati malformirana ili nedostajuća zaglavlja Date:. Skripta bez upravljanja ovim rubnim slučajevima može oštetiti te poruke ili ih tiho preskočiti.
• Potpisani (S/MIME) ili šifrirani (PGP) e-mailovi imaju dodatna ograničenja integriteta. Izmjena njihovih metapodataka bez opreza može poništiti kriptografski potpis.
• Strukture multipart/alternative s kompleksnim MIME granicama ponekad reagiraju nepredvidivo na operacije izmjene.
• Nema mehanizma za povrat (rollback). Ako nešto krene po zlu usred obrade, kako se vraća na početno stanje?

Skripta koja radi na 10 testnih e-mailova neće raditi na produkcijskom sandučiću od 50.000 poruka. Prošle godine, jedan klijent s PST arhivom od 40 GB pokušao je ispraviti to Python skriptom preuzetom sa Stack Overflowa. Rezultat: 3.000 e-mailova u duplikatu, 200 poruka s nedostupnim privitcima i dva tjedna ručnog čišćenja.

Što Redate.io radi u ovom konkretnom slučaju

Redate.io analizira metapodatke svake poruke u odredišnom sandučiću, identificira e-mailove s netočnim datumima (uključujući one iz uvoza PST-a) i primjenjuje ispravak putem svog vlasničkog mehanizma korekcije. Višefazni pipeline analize uspoređuje lanac zaglavlja svake poruke, izvlači originalni datum s RFC validacijom usklađenosti i provodi ciljanu korekciju metapodataka bez izmjene sadržaja poruke.

Svaki ispravljen e-mail verificira se pojedinačno. Originali se čuvaju u vidljivoj sigurnosnoj mapi 30 dana prije bilo kakve konačne izmjene. Ispravak radi na tri glavne platforme: Microsoft 365 (putem Azure AD), Google Workspace (putem domenskog delegiranja) i izravnog IMAP-a za uobičajene hostinge.

Početno skeniranje je besplatno. Omogućuje Vam da vidite točno koliko e-mailova je zahvaćeno i kakva je raspodjela netočnih datuma, prije nego što odlučite išta poduzeti.

Pogledajte i:

• Ispravak datuma e-mailova nakon migracije na Microsoft 365
• Outlook: datum primitka IMAP migracije vs datum slanja
• Mogu li se datumi e-mailova ispraviti nakon migracije?

Vaš uvoz PST-a je prepisao sve datume e-mailova? Skenirajte svoj sandučić besplatno na Redate.io i izmjerite opseg problema prije nego što poduzmete bilo što.