PST import u Outlook: zašto datumi postaju danas

Simptom: svi Vaši emailovi datiraju od danas

Završili ste PST import u Outlook. Traka napretka dostigla je 100%, sve je prošlo bez problema. Otvarate prijemno sanduče... i svaki uvezeni email prikazuje današnji datum. Poruka iz 2019, jedna iz 2021, arhiva stara pet godina: sve nosi isti datum. Datum dana kada ste radili import.

Ovo nije greška u prikazu. Nije problem sa vremenskom zonom. Reč je o savršeno dokumentovanom ponašanju, konzistentnom sa načinom na koji IMAP upravlja metapodacima o datumu. Ali to je katastrofa za svakoga kome treba da pronađe stare emailove po datumu.

Lokalni PST i IMAP: dva potpuno različita sveta

Pre nego što objasnimo zašto se datumi kvare, treba razumeti šta je PST fajl sa stanovišta upravljanja datumima.

PST fajl (Personal Storage Table) je Microsoftov vlasnički format. Čuva emailove sa svim metapodacima: datum slanja, datum prijema, prilozi, kategorije, indikatori čitanja. Tim metapodacima Outlook upravlja direktno, van svakog protokola za razmenu poruka. Kada otvarate PST u Outlooku bez konekcije na server, datumi koje vidite dolaze direktno iz internih polja PST fajla. Do tu, sve funkcioniše kako treba.

Problem se javlja kada pokušate da prebacite taj sadržaj u poštansko sanduče koje se nalazi na IMAP serveru, bilo da je reč o Microsoft 365, Google Workspace-u ili bilo kom klasičnom hostingu. U tom trenutku napuštate svet PST-a i ulazite u svet IMAP-a, a pravila se drastično menjaju.

IMAP APPEND i INTERNALDATE: srž problema

U IMAP-u, svaka poruka na serveru ima dve vrste podataka o datumu:

• Zaglavlje Date: (RFC 2822), koje je deo sadržaja same poruke. To je datum koji je pošiljalac upisao u poruku.
• INTERNALDATE, koji je metapodatak kojim upravlja IMAP server. Predstavlja trenutak kada je poruka dodata na server. Upravo tu vrednost Outlook koristi za sortiranje poruka u prikazu "Datum prijema".

(Ako ste ikada pokušali da čitate sirova zaglavlja emaila, znate da to nije baš lagano štivo. Ali upravo tamo se sve odlučuje.)

Kada email normalno stigne na server, server automatski postavlja INTERNALDATE na tačan trenutak prijema. Rezultat: datum koji vidite u Outlooku odgovara trenutku kada ste primili poruku.

Kada Outlook uvozi PST fajl u IMAP sanduče, koristi komandu IMAP APPEND da pošalje svaku poruku na server. IMAP standard dozvoljava prosleđivanje eksplicitnog INTERNALDATE tokom APPEND operacije. Ali Outlook to ne radi. Šalje poruke bez navođenja INTERNALDATE vrednosti. IMAP server, ne dobivši nikakvu instrukciju, primenjuje podrazumevano pravilo: INTERNALDATE se postavlja na trenutno vreme, tj. na momenat importa.

Rezultat: 8.000 uvezenih emailova, 8.000 emailova sa današnjim datumom.

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

Ovo nije Microsoftov propust. Reč je o implementacionom izboru koji je u vreme nastanka verovatno izgledao razumno: u originalnom slučaju upotrebe PST importa, korisnik arhivira poruke lokalno i "uvozi" ih u tekuće sanduče. Relevantan datum za sortiranje bio bi originalni datum prijema... ali Microsoft je odlučio da ne prosleđuje INTERNALDATE tokom import operacije.

Da budemo precizni: ovo ponašanje se odnosi na PST import putem Outlookovog ugrađenog čarobnjaka (Datoteka > Otvori i izvezi > Uvezi/Izvezi). Druge metode importa, kao što su određeni alati trećih strana ili migracije putem Exchange Admin Centra, mogu se ponašati drugačije zavisno od njihove implementacije IMAP APPEND komande.

Ovo ponašanje je poznato i dokumentovano na Microsoft forumima godinama unazad. Nije se promenilo u Outlooku 2016, ni u 2019, ni u trenutnim verzijama za Microsoft 365. Korisnik koji danas radi PST import naiće na potpuno isti problem kao i 2015. godine.

Razlika u odnosu na klasičnu IMAP migraciju

Ovde stvari postaju zanimljive, jer PST import daje sličan rezultat kao klasična IMAP migracija sa pokvarenim datumima, ali kroz drugačiji mehanizam.

U tipičnoj IMAP migraciji, recimo putem BitTitan MigrationWiz-a ili imapsync-a, emailovi prelaze sa izvornog IMAP servera na odredišni. Alat za migraciju preuzima poruke i ponovo ih ubacuje putem IMAP APPEND komande. Neki alati ispravno čuvaju INTERNALDATE, drugi ne. Ali u svakom slučaju, poruke već dobijaju zaglavlje Received: sa datumom migracije, što može narušiti prikaz u Outlooku nezavisno od INTERNALDATE-a.

Kod PST importa, mehanizam je jednostavniji: nema dodatog zaglavlja Received: sa datumom migracije (PST fajlovi ne prolaze kroz posredni server za razmenu poruka), ali INTERNALDATE jednostavno nikada nije postavljen na ispravnu vrednost. Vidljivi rezultat je identičan, ali osnovni uzrok je nešto drugačiji.

Ova razlika ima direktnu posledicu na ispravku: pristup nije sasvim isti zavisno od toga da li se radi o IMAP migraciji ili PST importu. Pročitajte i zašto INTERNALDATE uzrokuje pokvarene datume za detaljno objašnjenje oba slučaja.

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

Uobičajena reakcija kada se otkrije problem je da se zaroni u Outlook podešavanja. I zaista postoji jedna opcija koja izgleda obećavajuće: mogućnost sortiranja emailova po "Datumu" umesto po "Datumu prijema".

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

Evo zašto: čak i ako promenite sortiranje da prikazuje kolonu "Datum" (koja odgovara zaglavlju Date: poruke, dakle originalnom datumu), ostaju brojni problemi:

• Outlook indeksira pretragu po INTERNALDATE vrednosti. Pretraga "emailovi iz januara 2020." neće vratiti Vaše uvezene emailove iz januara 2020, jer njihov INTERNALDATE govori da datiraju od dana importa.
• Fascikle "Danas", "Ova nedelja", "Ovaj mesec" u Outlook interfejsu baziraju se na INTERNALDATE, ne na zaglavlju Date:.
• U web interfejsima (Outlook Web App, Gmail) i na mobilnim klijentima, prikazani datum i ponašanje sortiranja gotovo uvek zavise od INTERNALDATE vrednosti na serveru.
• Pravila i automatski filteri koji se primenjuju na datum prijema neće ispravno raditi.

Ukratko, promena prikaza rešava prikazivanje za jednog korisnika, na jednom klijentu, u jednoj konfiguraciji. Ne ispravlja problem na izvoru.

Resinhronizacija OST fajla takođe ne pomaže

Još jedan klasičan pokušaj: brisanje OST keša i prisilna potpuna resinhronizacija sa servera. Ideja je da problem možda dolazi iz lokalnog Outlook keša, a ne sa servera.

Pogrešan trag. OST fajl je lokalni keš koji odražava stanje IMAP servera. Ako je INTERNALDATE pogrešan na serveru, biće pogrešan i u OST-u nakon resinhronizacije. Brisanje OST-a ne menja podatke koji se čuvaju na Exchange Online ili Google Workspace serveru. Server je taj koji ima autoritet.

Jedini način da se datumi isprave jeste da se metapodaci koriguju direktno na strani servera, poruka po poruka. I upravo tu stvari postaju komplikovane za ručno rešavanje.

Problem razmere: 1 email je trivijalno. 15.000 je druga priča

Tehnički, ako razumete problem, mogli biste zamisliti pisanje skripte koja prolazi kroz sanduče, čita zaglavlje Date: svake poruke i ispravlja INTERNALDATE vrednost. Razumeti problem je jedna stvar. Ispraviti ga na 15.000 emailova bez gubitka ijednog, to je nešto sasvim drugo.

Nekoliko realnosti iz prakse:

• Microsoft Graph i Gmail API-ji nameću ograničenja broja zahteva (rate limits). Naivna skripta će izazivati greške 429 Too Many Requests, prekidati izvršavanje usred ispravke i ostaviti Vas sa delimično ispravljenim sandučetom, bez znanja koji emailovi su obrađeni, a koji nisu.
• Neki emailovi u PST fajlu mogu imati neispravna ili nedostajuća zaglavlja Date:. Skripta bez upravljanja ovim rubnim slučajevima može oštetiti te poruke ili ih preskočiti bez upozorenja.
• Potpisani (S/MIME) ili šifrovani (PGP) emailovi imaju dodatna ograničenja integriteta. Izmena njihovih metapodataka bez opreza može poništiti kriptografski potpis.
• Multipart/alternative strukture sa složenim MIME granicama ponekad reaguju nepredvidivo na operacije izmene.
• Nema mehanizma za vraćanje na prethodno stanje. Ako nešto pođe po zlu usred obrade, kako se vraćate na početno stanje?

Skripta koja radi na 10 test emailova neće raditi na produkcijskom sandučetu od 50.000 poruka. Prošle godine, klijent sa PST arhivom od 40 GB pokušao je to da reši Python skriptom pronađenom na Stack Overflowu. Rezultat: 3.000 emailova u duplikatu, 200 poruka sa nedostupnim prilozima i dve nedelje ručnog čišćenja.

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

Redate.io analizira metapodatke svake poruke u ciljnom sandučetu, identifikuje emailove sa netačnim datumima (uključujući i one koji potiču iz PST importa), i primenjuje ispravku putem svog vlasničkog motora za korekciju. Pipeline višestepene analize poredi lanac zaglavlja svake poruke, izvlači originalni datum uz validaciju usklađenosti sa RFC standardima i vrši ciljanu korekciju metapodataka bez izmene sadržaja poruke.

Svaki ispravljeni email se proverava pojedinačno. Originali se čuvaju u vidljivoj backup fascikli 30 dana pre bilo kakve definitivne izmene. Ispravka funkcioniše na sve tri glavne platforme: Microsoft 365 (putem Azure AD), Google Workspace (putem domenskog delegiranja) i direktni IMAP za klasičan hosting.

Inicijalno skeniranje je besplatno. Ono omogućava da tačno vidite koliko emailova je pogođeno i kakva je distribucija netačnih datuma, pre nego što donesete bilo kakvu odluku.

Pogledajte i:

• Ispravka datuma emailova posle migracije na Microsoft 365
• Outlook: datum prijema IMAP vs datum slanja
• Da li se datumi emailova mogu ispraviti posle migracije?

PST import je uništio sve datume Vaših emailova? Besplatno skenirajte Vaše sanduče na Redate.io i saznajte obim problema pre nego što preduzmete bilo šta.