Novi Outlook: krivi datumi nakon migracije, pravi razlozi

Dva Outlooka, dva ponašanja prema istim emailovima

Ako ste nedavno migrirali poštanske sandučiće na Microsoft 365 i neki korisnici se žale da svi njihovi stari emailovi prikazuju isti datum (datum migracije), možda ste primijetili nešto čudno: korisnici na klasičnom Outlooku ponekad vide ispravan datum u oknu za čitanje, dok oni na novom Outlooku za Windows sustavno vide datum migracije. Isti sandučić. Isti emailovi. Različiti rezultati.

To nije bug u klasičnom smislu. Radi se o arhitekturnoj odluci koja ima izravne posljedice na prikaz datuma nakon IMAP migracije. Da bismo razumjeli što se događa, moramo zaroniti u detalje email zaglavlja i IMAP protokola, što nije baš lako štivo, ali objašnjava zašto nikakva manipulacija na strani klijenta nije dovoljna za rješavanje problema.

IMAP INTERNALDATE: pravi krivac

Kada se email pohrani na IMAP server, ima dvije vrste datuma koji koegzistiraju i ne miješaju se.

Prva je zaglavlje Date:, definirano RFC 2822 standardom. To je datum upisan u samu poruku, onaj koji je pošiljatelj postavio u trenutku slanja emaila. Dio je tijela poruke i nikada se ne mijenja, bez obzira kojim putem email putuje nakon toga.

Druga je INTERNALDATE, metapodatak kojim upravlja IMAP server, izvan same poruke. To je datum kada je server zabilježio poruku. Kod uredne migracije, ozbiljni alati čuvaju izvorni INTERNALDATE. No kod pogrešno konfigurirane migracije, ili s određenim alatima koji ne upravljaju ispravno tim metapodatkom, INTERNALDATE se resetira na današnji datum migracije. Rezultat: svi migrirani emailovi nose isti datum primitka u očima servera.

(Inače, ako ste ikad čitali logove imapsynca ili MigrationWiza, znate da postoje specifične opcije za pokušaj čuvanja INTERNALDATE. Te opcije ne funkcioniraju uvijek, a neki odredišni serveri ih odbijaju poštivati.)

Klasični Outlook: kako čita datume

Klasični Outlook, tj. COM verzije instalirane lokalno (Outlook 2016, 2019, 2021 i Microsoft 365 Apps desktop klijent), koristi nešto složeniji mehanizam za određivanje koji datum prikazati u popisu poruka.

Za emailove u mapi Poslano oslanja se na zaglavlje Date:. Za primljene emailove, primarno koristi INTERNALDATE servera, ali u određenim kontekstima (posebno kada je OST cache uključen ili pri prvom prikazu u oknu za čitanje) može pročitati i lanac zaglavlja Received: kako bi rekonstruirao aproksimativni izvorni datum.

Upravo zbog toga se primjećuje to nekonzistentno ponašanje: klasični Outlook ponekad može prikazati ispravan datum u oknu za čitanje, jer čita izvorni Date: header poruke za detaljni pregled, čak i ako sam popis emailova koristi pokvareni INTERNALDATE. Ali oprez, to nije pouzdano i ne ispravlja ništa. Sortiranje ostaje pokvareno, pretraživanje po datumu ostaje iskrivljeno.

Novi Outlook: radikalno drugačija arhitektura

Novi Outlook za Windows, koji se postupno uvodi od kraja 2023. godine, više nije COM aplikacija. U biti je Progressive Web App (PWA) temeljena na istoj bazi koda kao Outlook na webu (OWA). Ta preinaka ima dalekosežne posljedice.

Novi Outlook u potpunosti delegira prikaz datuma Microsoft 365 API-ju. Ne čita zaglavlja Received:, ne koplje po lancu zaglavlja kako bi pronašao izvorni datum, i ne pokušava nikakvu rekonstrukciju na strani klijenta. Jednostavno prikazuje ono što mu server vrati: INTERNALDATE.

Rezultat: ako je INTERNALDATE pokvaren tijekom migracije, novi Outlook nema nikakve dvojbe. Prikazuje datum migracije za svaki zahvaćeni email, bez iznimke, bez nijanse. To je konzistentnije i predvidljivije ponašanje od klasičnog Outlooka, ali čini problem migracije odmah vidljivim i nemogućim za ignorirati.

Admin koji migrira 300 sandučića u petak navečer otkrit će u ponedjeljak ujutro da svi korisnici na novom Outlooku vide cijele arhive datirane prošlog vikenda. Tiketi dolaze brzo.

Zašto zaobilazna rješenja na strani klijenta ne funkcioniraju

Mnogi admini pokušavaju rješenja na strani klijenta prije nego shvate da je problem u podacima na serveru. Evo klasičnih pokušaja i razloga zašto ne uspijevaju.

Sortiranje po "Datumu slanja" umjesto "Datumu primitka"

Sortiranje po datumu slanja u Outlooku oslanja se na zaglavlje Date: poruke, koje je netaknuto. Dakle, to sortiranje može funkcionirati. Ali to je flaster, ne rješenje. Pretraživanje po datumu ostaje pokvareno. Pravila temeljena na datumu ostaju neupotrebljiva. A povrh svega, korisnik mora ručno rekonfigurirati svaku mapu, svaki sandučić. Na 300 sandučića, to je nerealno. Sortiranje po datumu slanja nije rješenje, a krajnji korisnici ne razumiju zašto ih se traži da mijenjaju navike.

Brisanje Outlook cachea ili kreiranje novog profila

To ne utječe na INTERNALDATE na serveru. Nakon ponovnog kreiranja profila, Outlook sinkronizira emailove sa servera i povlači točno iste pokvarene metapodatke. Cache nije problem.

Korištenje OWA umjesto Outlooka

OWA i novi Outlook dijele istu bazu podataka. Ako je INTERNALDATE pokvaren na Exchange Online serveru, OWA prikazuje točno isti pogrešni datum. Promjena klijenta ne mijenja podatke.

Problem je na serveru, u metapodacima svake poruke. Nikakva akcija na strani klijenta ne može ispraviti podatke pohranjene na serveru.

Zamka Received zaglavlja: zašto sve kompliciraju

Kada alat za migraciju kopira email s jednog servera na drugi putem IMAP-a, odredišni server automatski dodaje zaglavlje Received: na vrh lanca, s datumom i vremenom umetanja. To je normalno ponašanje SMTP i IMAP servera koji su u skladu s RFC standardima.

Ta se zaglavlja akumuliraju obrnutim redoslijedom puta kojim je email putovao. Najnovije je na vrhu. Neki email klijenti čitaju prvi Received: za procjenu datuma primitka, što daje datum migracije umjesto izvornog datuma.

Napomena: to ponašanje nije karakteristično za jedan alat. BitTitan MigrationWiz, CloudM, imapsync, GSMMO, pa čak i ručno IMAP kopiranje između dva Thunderbird klijenta, svi daju isti rezultat. Izvorni Date: header ostaje netaknut u poruci. Upravo to čini ispravak tehnički mogućim. Ali INTERNALDATE je zasebni metapodatak kojim upravlja server i ne može se ispraviti jednostavnom manipulacijom zaglavlja poruke na strani klijenta.

Za dublje razumijevanje tog mehanizma, članak o IMAP INTERNALDATE i pokvarenim datumima detaljno opisuje kako se tim metapodatkom upravlja na različitim serverima.

Koji alati za migraciju uzrokuju taj problem na Microsoft 365

Pitanje se često ponavlja: uzrokuju li svi alati za migraciju taj problem?

Kratki odgovor je da ovisi o konfiguraciji i odredišnoj platformi. Na Exchange Online / Microsoft 365, server je posebno strog u upravljanju INTERNALDATE. Čak i alati koji ga pokušavaju sačuvati ponekad ne uspijevaju, jer Graph API i EWS (Exchange Web Services) imaju različita ponašanja ovisno o korištenom putu umetanja.

BitTitan MigrationWiz jedan je od najraširenijih alata za migracije na Microsoft 365, a ujedno i jedan od onih čiji su problemi s datumima najbolje dokumentirani. Stranica ispravak datuma migracije BitTitan u Microsoft 365 pokriva specifične konfiguracije na koje treba paziti. CloudM i imapsync imaju svoje posebnosti, dokumentirane redom na ispravak datuma migracije CloudM u Microsoft 365 i ispravak datuma migracije imapsync u Microsoft 365.

Što je zajedničko svim tim alatima: izvorni Date: header preživljava migraciju. To je temelj na kojemu je ispravak moguć.

Zašto je vlastiti skript loša ideja u ovom slučaju

Razumijevanje problema ponekad stvara privid da je rješenje jednostavno. Nije, ne u produkcijskom okruženju.

Mijenjanje metapodataka emailova pohranjenih na Exchange Onlineu nije trivijalno. Microsoft Graph API nameće stroga ograničenja brzine (greška 429 Too Many Requests na noćnom batchu dolazi brzo). Upravljanje emailovima potpisanim S/MIME ili šifriranim PGP zahtijeva posebnu pažnju kako se potpisi ne bi poništili. Multipart strukture s velikim privitcima dodaju ograničenja vezana uz mrežne timeout-ove. I iznad svega: kako verificirati, email po email, da je ispravak uspio bez izmjene sadržaja ili privitaka?

Skript koji dobro radi na 50 testnih emailova neće se jednako ponašati na sandučiću od 40.000 poruka s 8 godina povijesti. Vjerojatnost da neki rubni slučaj nešto pokvari raste sa svakih tisuću dodatnih poruka. A bez mehanizma vraćanja u prethodno stanje, greška na pola puta ostavlja sandučić u nekonzistentnom stanju.

Vidi i: ispravak datuma emailova nakon Microsoft 365 migracije za cjelovit pregled dostupnih mogućnosti.

Što Redate.io konkretno radi

Redate.io se povezuje na Microsoft 365 tako da se svaki korisnik prijavi svojim Microsoft računom, bez portala i registracije aplikacije, besplatno skenira emailove s neispravnim datumima, a zatim primjenjuje vlasnički mehanizam ispravka na identificirane poruke. Višestupanjski pipeline analize provodi prepoznavanje uzoraka na stotinama poznatih potpisa alata za migraciju, validaciju RFC usklađenosti i analizu lanca zaglavlja za rekonstrukciju ispravnih metapodataka datuma.

Svaki ispravljeni email verificira se pojedinačno. Izvorne poruke čuvaju se u vidljivoj mapi sigurnosne kopije dok ih sami ne obrišete. Model naplate je jednokratno plaćanje po poštanskom sandučiću, bez pretplate.

Novi Outlook tada prikazuje ispravne datume, jer su podaci na serveru ispravljeni, ne maskirani.

Imate zahvaćene sandučiće na novom Outlooku? Pokrenite besplatno skeniranje na Redate.io kako biste točno utvrdili koliko je emailova zahvaćeno prije nego odlučite o daljnjim koracima.