Rekreiranje profila Outlook: zašto se datumi menjaju

Standardni postupak koji kvari datume

Korisnik se žali da se Outlook više ne sinhronizuje. Emailovi ne pristižu, folder Poslato se ne ažurira, ikonica učitavanja se vrti u krug. Tehničar dijagnostikuje oštećen profil, briše OST fajl, rekreira Outlook profil od nule. Rezultat: Outlook se ponovo povezuje, emailovi se ponovo pojavljuju, sve izgleda kako treba.

Sve dok sledećeg jutra korisnik ne otvori sandučić i shvati da 8 godina prepiske prikazuje isti datum: danas.

To je tačno isti simptom kao kod neuspele IMAP migracije. I iz istih razloga.

Šta se dešava na tehničkom nivou

Da bismo razumeli zašto rekreiranje profila proizvodi ovaj rezultat, moramo se osvrnuti na razliku koju većina tehničara slabo poznaje: razliku između zaglavlja Date: emaila i njegovog IMAP INTERNALDATE.

Svaki email sadrži u RFC 2822 zaglavljima polje Date: koje označava kada je poruka poslata. Ovo polje upisuje klijent pošiljaoca u trenutku slanja, a zatim se prenosi nepromenjeno kroz sve servere do Vašeg sandučića. Ono se nikada ne menja. Email poslat 14. marta 2019. u 09:32 uvek će imati to polje Date: netaknuto, bez obzira na sve što se dešava kasnije.

IMAP INTERNALDATE je nešto sasvim drugo. To je metapodatak kojim upravlja serverska strana, nezavisan od sadržaja poruke. Označava kada je poruka "položena" u sandučić. U normalnim uslovima, kada email pristiže putem SMTP-a, server beleži vreme prijema kao INTERNALDATE. Email primljen 14. marta 2019. imaće dakle INTERNALDATE koji odgovara datumu slanja.

Outlook podrazumevano sortira i prikazuje emailove prema INTERNALDATE koji prima od IMAP servera, a ne prema polju Date: u samoj poruci. (Inače, ako ste ikada otvorili potpuna svojstva emaila u Outlooku da vidite sirova zaglavlja, znate da to nije baš lektira za plažu.)

Šta pokreće brisanje OST fajla

Kada Outlook koristi IMAP nalog, održava lokalnu bazu podataka: OST fajl (Offline Storage Table). Taj fajl je lokalni mirror emailova uskladištenih na serveru, sa svim metapodacima, statusima čitanja, kategorijama i slično.

Brisanje OST fajla znači brisanje tog lokalnog mirrora. Outlook mora sve ponovo da preuzme sa IMAP servera.

Problem? Kada Outlook ponovo preuzima poruku putem IMAP-a, koristi komandu FETCH za preuzimanje sadržaja. Ali ne koristi uvek komandu FETCH INTERNALDATE da preuzme i sačuva originalni IMAP datum. U određenim konfiguracijama i verzijama Outlooka, klijent rekonstruiše lokalni indeks koristeći datum kada je poruku ponovo preuzeo, a ne INTERNALDATE uskladišten na serveru.

I tada svi emailovi u sandučiću dobijaju datum dana kada je vršeno preuzimanje.

Sve verzije Outlooka se ne ponašaju na isti način

Da budemo precizni: ovo ponašanje ne pogađa sve verzije Outlooka na identičan način, i upravo tu dijagnoza postaje složena.

Outlook 2016 i 2019 u IMAP modu imaju dokumentovane slučajeve pogrešne rekonstrukcije indeksa posle brisanja keša. Novi Outlook (baziran na webu, koji se postepeno uvodi od kraja 2023. godine) drugačije upravlja kešom i može davati promenljive rezultate. Outlook preko Exchange-a i Microsoft 365-a sa nalogom konfigurisanim u Exchange modu manje je izložen ovom konkretnom problemu, jer protokol MAPI/Exchange drugačije rešava sinhronizaciju od IMAP-a.

Ali ako je Vaš korisnik na IMAP nalogu konfigurisanom u klasičnom Outlooku, i tehničar je obrisao OST fajl ili rekreirao profil: rizik je sasvim realan.

Kako razlikovati ovaj slučaj od prave migracije

IT administrator koji prima tikete "moji datumi su pogrešni" posle rekreiranja profila može pogrešno pomisliti da se radi o problemu migracije. Evo kako se ta dva slučaja razlikuju.

Slučaj IMAP migracije

Kod IMAP migracije (BitTitan, CloudM, imapsync i sl.), alat za migraciju kopira emailove s jednog servera na drugi. Za svaku kopiranu poruku, kreira novi unos na odredišnom serveru putem komande IMAP APPEND. Ako alat ne navede eksplicitno originalni INTERNALDATE u toj komandi, odredišni server beleži trenutno vreme kao INTERNALDATE. Pored toga, neki alati dodaju i zaglavlje Received: sa datumom migracije, što situaciju u određenim klijentima dodatno pogoršava. Detalje ovog mehanizma možete pročitati u tekstu o IMAP INTERNALDATE i zašto se datumi kvare.

Slučaj rekreiranja profila

Ovde su emailovi i dalje na istom serveru, sa istim originalnim INTERNALDATE vrednostima. Na serverskoj strani se ništa nije promenilo. Jedino lokalni Outlookov keš je rekonstruisan sa pogrešnim datumima. Vidljivi simptom je identičan (svi emailovi prikazuju isti skorašnji datum), ali uzrok je drugačiji.

Za potvrdu: prijavite se na sandučić putem webmail-a (Gmail, Outlook.com, ili webmail interfejs Vašeg provajdera). Ako su datumi u webmailu ispravni, problem je isključivo lokalan, u Outlooku. Ako su datumi pogrešni i u webmailu, problem je na serverskoj strani (migracija ili izmena INTERNALDATE vrednosti na samom serveru).

Zašto originalni datumi ostaju dostupni

Dobra vest: u oba slučaja (migracija ili rekreiranje profila), originalni datumi nisu izgubljeni.

RFC 2822 zaglavlje Date: sastavni je deo poruke. Jednako je nepromenjivo kao i telo teksta ili prilozi. Email poslat 2017. sadrži u sirovom tekstu nešto ovako:

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

Ovaj red postoji u poruci uskladištenoj na serveru. Nije izmenjen. Ono što Outlook prikazuje (pogrešno) jeste metapodatak koji je spoljašnji u odnosu na sadržaj poruke.

Upravo to čini ispravku mogućom. Redate.io analizira lanac zaglavlja svake poruke da bi izvukao pravi originalni datum, a potom vrši ciljanu korekciju metapodataka bez izmene sadržaja poruke. INTERNALDATE koji Outlook vidi rekonstruiše se na osnovu te autentične informacije, koja je uvek prisutna u samoj poruci.

Zamka "čistog" rekreiranja

Upravo ste rešili problem sinhronizacije za korisnika. Outlook mu radi, novi emailovi pristižu. Zatvarate tiket.

Tri dana kasnije, korisnik ponovo zove: traži email od dobavljača iz prošle godine, ali u Outlooku svi emailovi iz 2023. se prikazuju kao primljeni "juče". Ne može ništa da pronađe. Automatsko arhiviranje je možda razvrstalo skorašnje emailove kao stare. A šef traži email konverzaciju iz septembra 2022. za jedan spor.

Ovaj scenario se dešava redovno. Ne zato što je tehničar loše uradio posao, nego zato što ovo ponašanje Outlooka nije vidno dokumentovano u standardnim vodičima za otklanjanje grešaka.

Lažna rešenja koja ništa ne popravljaju

Sortiranje emailova po "Datumu slanja" umesto "Datumu prijema" u Outlooku prva je stvar koju korisnici probaju. I deluje da funkcioniše... dok ne shvate da sortiranje po datumu slanja nije dostupno za sve foldere, da nestaje kad se promeni prikaz, i da druge aplikacije (mobilna, webmail, pravila automatskog sortiranja) i dalje koriste pogrešni INTERNALDATE.

Sortiranje po datumu slanja nije rešenje. To je flaster koji skriva simptom, a ne rešava pravi problem. Detaljno smo to obradili u tekstu Sortiranje po datumu slanja nije rešenje.

Ponovo rekreirati profil? To ne menja ništa ako Outlook ponovo gradi keš sa tekućim datumom.

Eksportovati pa uvesti PST? Pažnja. Eksport PST fajla iz Outlooka sa pogrešnim datumima izvozi pogrešne metapodatke. PST fajl će sadržati pogrešne datume. Ponovni uvoz tog fajla ništa ne ispravlja, a može i pogoršati situaciju stvaranjem duplikata sa nekonzistentnim datumima. Ova tema je posebno obrađena u tekstu o PST importu i datumima koji postaju danas.

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

Bez obzira da li problem potiče od IMAP migracije ili rekreiranja Outlook profila, rezultat na serverskoj strani je sličan: emailovi čiji metapodaci datuma nisu konzistentni sa stvarnim sadržajem.

Redate.io se direktno povezuje na sandučić (Google Workspace, Microsoft 365 ili direktni IMAP), skenira sve poruke radi identifikacije onih sa pogrešnim metapodacima, a potom primenjuje višestepeni pipeline analize za ispravku svakog emaila pojedinačno. Svaka ispravka se verifikuje. Originalne poruke se čuvaju u vidljivoj fascikli Vašeg sandučića, sve dok ih sami ne obrišete.

Proces rešava granične slučajeve koje skripte pisane u kući sistematski ne obrađuju: S/MIME potpisane poruke, emailove sa non-ASCII kodovanjem u zaglavljima (RFC 2047), složene multipart strukture, zaglavlja Date: sa nestandardnim ili malformiranim vremenskim zonama. Skripta koja ispravno radi na 50 test emailova u razvojnom sandučiću može nepovratno da ošteti 2000 poruka u produkciji. U IMAP-u ne postoji nativni rollback kada se poruka jednom zameni bez prethodne rezervne kopije.

Za slučajeve vezane specifično za Outlook, stranica za ispravku ispravka datuma ručnog IMAP kopiranja u Outlook-u opisuje korake za povezivanje sandučića i pokretanje analize.

Sprečavanje problema pri narednim intervencijama

Ako ste tehničar ili IT administrator koji redovno radi na Outlook profilima, nekoliko navika može sprečiti ovu situaciju.

Pre brisanja OST fajla ili rekreiranja profila, proverite prikazane datume u webmailu. Ako su ispravni, zabeležite to u tiketu. Posle rekreiranja, ponovo se prijavite na webmail i uporedite prikazane datume sa onima u Outlooku. Ako se pojavi razlika, problem je odmah identifikovan, pre nego što se korisnik požali tri dana kasnije.

Za planirane migracije, kontrolna lista migracije emaila navodi provere koje treba uraditi pre i posle, kako bi se ovakvi problemi otkrili odmah po završetku operacije.

Rekreirali ste Outlook profil i svi datumi u sandučiću su sada pogrešni? Pokrenite besplatan sken na Redate.io da identifikujete pogođene emailove i ispravite metapodatke bez izmene sadržaja Vaših poruka.