Rekreiranje profila Outlook: zašto se datumi mijenjaju

Uobičajeni ispravak koji kvari datume

Korisnik se žali da se Outlook više ne sinkronizira. Emailovi ne pristižu, mapa Poslano se ne ažurira, ikona učitavanja se vrti bez prestanka. Tehničar dijagnosticira oštećeni profil, briše OST datoteku, rekreira Outlook profil od nule. Rezultat: Outlook se ponovo spaja, emailovi se pojavljuju, sve izgleda uredno.

Sve do sljedećeg jutra, kada korisnik otvori sandučić i shvati da 8 godina prepiske prikazuje isti datum: danas.

Ovo je točno isti simptom kao kod neuspjele IMAP migracije. I iz istih razloga.

Što se događa tehnički

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

Svaki email sadrži u svojim RFC 2822 zaglavljima polje Date: koje označava kada je poruka poslana. To polje upisuje klijent pošiljatelja u trenutku slanja, a zatim se prenosi nepromijenjeno kroz sve poslužitelje do Vašeg sandučića. Nikad se ne mijenja. Email poslan 14. ožujka 2019. u 09:32 uvijek će imati to polje Date: netaknuto, bez obzira na sve što se poslije dogodi.

IMAP INTERNALDATE je nešto drugo. To je metapodatak kojim upravlja poslužitelj pošte, neovisan o sadržaju poruke. Označava kada je poruka „položena" u sandučić. U normalnim uvjetima, kada email pristiže putem SMTP-a, poslužitelj bilježi vrijeme primitka kao INTERNALDATE. Email primljen 14. ožujka 2019. imat će dakle INTERNALDATE koji odgovara datumu slanja.

Outlook po zadanim postavkama razvrstava i prikazuje emailove prema INTERNALDATE koji mu šalje IMAP poslužitelj, a ne prema polju Date: same poruke. (Inače, ako ste ikad otvorili potpuna svojstva emaila u Outlooku kako biste vidjeli sirova zaglavlja, znate da to nije baš lektira za plažu.)

Što pokreće brisanje OST datoteke

Kada Outlook koristi IMAP račun, održava lokalnu bazu podataka: OST datoteku (Offline Storage Table). Ta datoteka je lokalno zrcalo emailova pohranjenih na poslužitelju, s njihovim metapodacima, stanjima čitanja, kategorijama itd.

Brisanje OST datoteke jednako je brisanju tog lokalnog zrcala. Outlook mora sve ponovo preuzeti s IMAP poslužitelja.

Problem? Kada Outlook ponovo preuzima poruku putem IMAP-a, koristi naredbu FETCH za dohvaćanje sadržaja. Ali ne koristi uvijek naredbu FETCH INTERNALDATE da bi dohvatio i sačuvao originalni IMAP datum. U određenim konfiguracijama i verzijama Outlooka, klijent rekonstruira lokalni indeks koristeći datum kada je poruku ponovo preuzeo, umjesto INTERNALDATE pohranjenoga na poslužitelju.

I tada svi emailovi u sandučiću dobivaju datum dana ponovnog učitavanja.

Sve verzije Outlooka ne ponašaju se jednako

Zapravo, ovo ponašanje ne pogađa sve verzije Outlooka na isti način, i upravo tu dijagnoza postaje složena.

Outlook 2016 i 2019 u IMAP načinu rada imaju dokumentirana ponašanja neispravne rekonstrukcije indeksa nakon brisanja predmemorije. Novi Outlook (temeljen na webu, koji se postupno uvodi od kraja 2023.) upravljanje predmemorijom rješava drugačije i može davati različite rezultate. Outlook putem Exchange-a ili Microsoft 365-a s računom konfiguriranim u Exchange načinu rada manje je izložen ovom specifičnom problemu, jer MAPI/Exchange protokol sinkronizaciju obrađuje drugačije od IMAP-a.

Ali ako je Vaš korisnik na IMAP računu konfiguriranom u klasičnom Outlooku, a tehničar je obrisao OST datoteku ili rekreirao profil: rizik je stvaran.

Kako razlikovati ovaj slučaj od prave migracije

IT administrator koji prima tikete „moji datumi su krivi" nakon rekreiranja profila može pogrešno zaključiti da se radi o problemu migracije. Evo kako razlikovati ta dva slučaja.

Slučaj IMAP migracije

Kod IMAP migracije (BitTitan, CloudM, imapsync i sl.), alat za migraciju kopira emailove s jednog poslužitelja na drugi. Za svaku kopiranu poruku stvara novi unos na odredišnom poslužitelju putem naredbe IMAP APPEND. Ako alat u toj naredbi ne navede izričito originalni INTERNALDATE, odredišni poslužitelj bilježi trenutno vrijeme kao INTERNALDATE. Uz to, neki alati dodaju i zaglavlje Received: s datumom migracije, što u određenim klijentima pogoršava situaciju. Detalje ovog mehanizma možete pročitati u članku o IMAP INTERNALDATE i pokvarenim datumima.

Slučaj rekreiranja profila

Ovdje su emailovi i dalje na istom poslužitelju, s istim originalnim INTERNALDATE vrijednostima. Na strani poslužitelja ništa se nije promijenilo. Jedino što se promijenilo je Outlookov lokalni predmemorija, rekonstruirana s netočnim datumima. Vidljivi simptom je identičan (svi emailovi prikazuju isti nedavni datum), ali uzrok je drugačiji.

Za potvrdu: prijavite se u sandučić putem webmaila (Gmail, Outlook.com, ili webmail sučelje Vašeg pružatelja usluga). Ako su datumi u webmailu ispravni, problem je isključivo lokalan za Outlook. Ako su datumi netočni i u webmailu, problem je na strani poslužitelja (migracija ili izmjena INTERNALDATE vrijednosti na samom poslužitelju).

Zašto originalni datumi ostaju dostupni

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

Zaglavlje Date: prema RFC 2822 sastavni je dio poruke. Jednako je nepromjenjivo kao i tijelo teksta ili privici. Email poslan 2017. u svom sirovom tekstu sadrži nešto poput:

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

Taj redak je prisutan u poruci pohranjenoj na poslužitelju. Nije promijenjen. Ono što Outlook prikazuje (netočno) je metapodatak vanjski za sadržaj poruke.

To je ono što ispravak čini mogućim. Redate.io-ov mehanizam analizira lanac zaglavlja svake poruke kako bi izvukao stvarni originalni datum, a zatim provodi ciljanu korekciju metapodataka bez izmjene sadržaja poruke. INTERNALDATE koji Outlook vidi rekonstruira se iz te autentične informacije, koja je uvijek prisutna u poruci.

Zamka „čistog" rekreiranja

Upravo ste riješili problem sinkronizacije za korisnika. Njegov Outlook ponovo radi, novi emailovi pristižu. Zatvarate tiket.

Tri dana kasnije, korisnik zove ponovo: traži email od dobavljača iz prošle godine, ali u Outlooku svi njegovi emailovi iz 2023. pojavljuju se kao da su primljeni „jučer". Ništa ne može pronaći. Automatsko arhiviranje je možda razvrstalo nedavne emailove tretirajući ih kao stare. A šef od njega traži e-mail konverzaciju iz rujna 2022. za jedan spor.

Ovaj scenarij se redovito događa. Ne zato što je tehničar loše obavio posao, nego zato što ovo ponašanje Outlooka nije vidljivo dokumentirano u standardnim priručnicima za rješavanje problema.

Lažna rješenja koja ništa ne rješavaju

Razvrstavanje emailova po „Datum slanja" umjesto „Datum primitka" u Outlooku prva je stvar koju korisnici isprobaju. I čini se da funkcionira... sve dok ne shvate da sortiranje po datumu slanja nije dostupno za sve mape, da nestaje kad promijene prikaz, i da druge aplikacije (mobitel, webmail, pravila automatskog sortiranja) i dalje koriste netočan INTERNALDATE.

Sortiranje po datumu slanja nije rješenje. To je flaster koji skriva simptom, a ne dotiče stvarni problem. Detaljno to objašnjavamo u članku Sortiranje po datumu slanja nije rješenje.

Rekreirati profil još jednom? To ništa ne mijenja ako Outlookovo ponašanje rekonstruira predmemoriju s trenutnim datumom.

Izvesti pa uvesti u PST? Pažnja. PST izvoz iz Outlooka s pogrešnim datumima izvozi netočne metapodatke. PST datoteka sadržavat će pogrešne datume. Uvoz te datoteke ništa ne ispravlja, a može čak pogoršati situaciju stvarajući duplikate s neusklađenim datumima. Ova tema se posebno obrađuje u članku o uvozu PST-a i datumima koji postaju danas.

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

Bez obzira dolazi li problem od IMAP migracije ili rekreiranja Outlook profila, rezultat na strani poslužitelja je sličan: emailovi čiji su metapodaci o datumu neusklađeni s njihovim stvarnim sadržajem.

Redate.io se izravno spaja na sandučić (Google Workspace, Microsoft 365 ili izravni IMAP), skenira sve poruke kako bi identificirao one s netočnim metapodacima, zatim primjenjuje višestupanjski analitički pipeline za ispravljanje svakog emaila pojedinačno. Svaka korekcija se provjerava. Originalne poruke ostaju u vidljivoj sigurnosnoj kopiji u Vašem sandučiću sve dok ih sami ne izbrišete.

Proces obrađuje rubne slučajeve koje vlastiti skripti sustavno propuštaju: S/MIME potpisane poruke, emailove s ne-ASCII enkodiranjem u zaglavljima (RFC 2047), složene multipart strukture, zaglavlja Date: s nestandardnim ili neispravno oblikovanim vremenskim zonama. Skripta koja ispravno radi na 50 testnih emailova u razvojnom sandučiću može nepopravljivo oštetiti 2000 poruka u produkciji. U IMAP-u nema nativnog mehanizma povrata nakon što je poruka zamijenjena bez prethodne sigurnosne kopije.

Za slučajeve specifično vezane uz Outlook, stranica za ispravak ispravak datuma IMAP kopiranja u Outlooku detaljno opisuje korake za spajanje sandučića i pokretanje analize.

Prevencija problema pri sljedećim intervencijama

Ako ste tehničar ili IT administrator koji redovito intervenirate na Outlook profilima, nekoliko navika može spriječiti ovu situaciju.

Prije brisanja OST datoteke ili rekreiranja profila, provjerite datume prikazane u webmailu. Ako su ispravni, zabilježite to u tiketu. Nakon rekreiranja, ponovo se prijavite u webmail i usporedite prikazane datume s onima u Outlooku. Ako se pojavi razlika, problem je identificiran odmah, prije nego se korisnik požali tri dana kasnije.

Za planirane migracije, kontrolni popis za migraciju emailova navodi provjere koje treba napraviti prije i poslije kako biste ovakvu vrstu problema otkrili odmah po završetku operacije.

Rekreirali ste Outlook profil i datumi u Vašem sandučiću su sada svi pogrešni? Pokrenite besplatno skeniranje na Redate.io kako biste identificirali zahvaćene emailove i ispravili metapodatke bez dodirivanja sadržaja Vaših poruka.