Novi Outlook: pogrešni datumi posle migracije, pravi uzroci

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 primetili nešto čudno: korisnici na klasičnom Outlooku ponekad vide tačan datum u oknu za čitanje, dok oni na novom Outlooku za Windows sistematično vide datum migracije. Ista kutija. Isti emailovi. Različiti rezultati.

Ovo nije bag u pravom smislu reči. To je arhitekturalna odluka koja ima direktne posledice na način na koji se datumi prikazuju posle IMAP migracije. Da bismo razumeli šta se dešava, moramo ući u detalje email zaglavlja i IMAP protokola, što nije baš lagano štivo, ali objašnjava zašto nikakva manipulacija na strani klijenta nije dovoljna da reši problem.

IMAP INTERNALDATE: pravi krivac

Kada se email čuva na IMAP serveru, ima dve vrste datuma koji koegzistiraju i ne mešaju se.

Prva je zaglavlje Date:, definisano RFC 2822 standardom. To je datum upisan u samu poruku, onaj koji je pošiljalac postavio u trenutku slanja. Deo je tela poruke i nikada se ne menja, bez obzira koji put email posle toga pređe.

Druga je INTERNALDATE, metapodatak kojim upravlja IMAP server, spolja u odnosu na poruku. To je datum kada je server upisao poruku. Tokom normalne migracije, ozbiljni alati čuvaju originalni INTERNALDATE. Ali tokom loše konfigurisane migracije, ili s nekim alatima koji ne upravljaju ispravno tim metapodatkom, INTERNALDATE se resetuje na datum dana migracije. Rezultat: svi migrirani emailovi nose isti datum prijema u očima servera.

(Inače, ako ste ikada čitali logove imapsync-a ili MigrationWiz-a, znate da postoje specifične opcije za pokušaj čuvanja INTERNALDATE-a. Te opcije ne funkcionišu uvek, i neki odredišni serveri odbijaju da ih poštuju.)

Klasični Outlook: kako čita datume

Klasični Outlook, to jest COM verzije instalirane lokalno (Outlook 2016, 2019, 2021 i desktop klijent Microsoft 365 Apps), koristi nešto složeniji mehanizam za određivanje kog datuma da prikaže u listi poruka.

Za emailove u folderu Poslato oslanja se na zaglavlje Date:. Za primljene emailove, prioritetno koristi INTERNALDATE sa servera, ali u određenim kontekstima (naročito kada je uključen OST keš ili prilikom prvog prikaza u oknu za čitanje) može čitati i lanac zaglavlja Received: kako bi rekonstruisao približni originalni datum.

Upravo zato se javlja to nekonzistentno ponašanje: klasični Outlook ponekad može prikazati tačan datum u oknu za čitanje, jer čita originalno zaglavlje Date: za detaljni pregled, čak i ako sama lista emailova koristi pogrešan INTERNALDATE. Ali oprez, ovo nije pouzdano i ništa ne ispravlja. Sortiranje ostaje pokvareno, pretrage po datumu ostaju iskrivljene.

Novi Outlook: radikalno drugačija arhitektura

Novi Outlook za Windows, koji se postepeno uvodi od kraja 2023. godine, više nije COM aplikacija. To je u suštini Progressive Web App (PWA) bazirana na istoj kodni bazi kao Outlook na webu (OWA). Ova promena ima duboke implikacije.

Novi Outlook potpuno prepušta prikaz datuma Microsoft 365 API-ju. Ne čita zaglavlja Received:, ne kopà po lancu zaglavlja tražeći originalni datum i ne pokušava nikakvu rekonstrukciju na strani klijenta. Jednostavno prikazuje ono što mu server vrati: INTERNALDATE.

Rezultat: ako je INTERNALDATE pogrešan tokom migracije, novi Outlook nema nikakve nedoumice. Prikazuje datum migracije za svaki pogođeni email, bez izuzetka, bez nijanse. To je konzistentnije i predvidljivije ponašanje od klasičnog Outlooka, ali čini problem migracije odmah vidljivim i nemogućim za ignorisanje.

Admin koji migrira 300 sandučića u petak uveče otkriva u ponedeljak ujutro da svi korisnici na novom Outlooku vide celokupne arhive datirane prošlog vikenda. Tiketi stižu brzo.

Zašto nijedan klijentski zaobilazni put ne funkcioniše

Mnogi admini isprobaju rešenja na strani klijenta pre nego što shvate da je problem u serverskim podacima. Evo klasičnih pokušaja i razloga zašto ne uspevaju.

Sortiranje po "Datumu slanja" umesto "Datumu prijema"

Sortiranje po datumu slanja u Outlooku oslanja se na zaglavlje Date: poruke, koje je netaknuto. Dakle, da, ovo sortiranje može da funkcioniše. Ali to je flaster, ne rešenje. Pretrage po datumu ostaju pokvarene. Pravila zasnovana na datumu ostaju neupotrebljiva. A pre svega, korisnik mora ručno da rekonfiguriše svaki folder, svaki sandučić. Na 300 sandučića, to je nerealno. Sortiranje po datumu slanja nije rešenje, i krajnji korisnici ne razumeju zašto ih tražite da menjaju navike.

Brisanje Outlook keša ili rekreiranje profila

Ovo ne dodiruje INTERNALDATE na strani servera. Posle rekreiranja profila, Outlook ponovo sinhronizuje emailove sa servera i preuzima tačno iste pogrešne metapodatke. Keš nije problem.

Korišćenje OWA umesto toga

OWA i novi Outlook dele istu bazu podataka. Ako je INTERNALDATE pogrešan na Exchange Online serveru, OWA prikazuje tačno isti pogrešan datum. Menjanje klijenta ne menja podatke.

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

Zamka zaglavlja Received: zašto sve komplikuju

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

Ova zaglavlja se akumuliraju obrnutim redosledom puta kojim je email prošao. Najnovije je na vrhu. Neki email klijenti čitaju prvo Received: zaglavlje kako bi procenili datum prijema, što daje datum migracije umesto originalnog datuma.

Napomena: ovo ponašanje nije karakteristično za jedan jedini alat. BitTitan MigrationWiz, CloudM, imapsync, GSMMO, pa čak i ručno IMAP kopiranje između dva Thunderbird klijenta svi daju ovaj rezultat. Originalno zaglavlje Date: ostaje netaknuto u poruci. Upravo to čini ispravku tehnički mogućom. Ali INTERNALDATE je poseban metapodatak kojim upravlja server i ne može se ispraviti prostom manipulacijom zaglavlja poruke na strani klijenta.

Za više detalja o ovom mehanizmu, pogledajte članak o IMAP INTERNALDATE-u i zašto se datumi kvare.

Koji alati za migraciju uzrokuju ovaj problem na Microsoft 365

Pitanje se često ponavlja: da li svi alati za migraciju izazivaju ovaj problem?

Kratak odgovor je da to zavisi od konfiguracije i odredišne platforme. Na Exchange Online / Microsoft 365, server je posebno strog u upravljanju INTERNALDATE-om. Čak i alati koji pokušavaju da ga sačuvaju ponekad ne uspeju, jer Graph API i EWS (Exchange Web Services) imaju različita ponašanja u zavisnosti od korišćenog puta umetanja.

BitTitan MigrationWiz je jedan od najraširenijih alata za migracije ka Microsoft 365, i ujedno jedan od onih čiji su problemi s datumima najdokumentovaniji. Stranica popravka datuma migracije BitTitan u Microsoft 365 pokriva specifične konfiguracije koje treba pratiti. CloudM i imapsync imaju svoje posebnosti, dokumentovane na popravka datuma migracije CloudM u Microsoft 365 i ispravka datuma migracije imapsync u Microsoft 365.

Ono što je zajedničko svim tim alatima: originalno zaglavlje Date: preživljava migraciju. To je osnova na kojoj je ispravka moguća.

Zašto je domaći skript loša ideja ovde

Razumevanje problema ponekad stvara iluziju da je rešenje jednostavno. Nije, ne u produkcijskom okruženju.

Menjanje metapodataka emailova sačuvanih na Exchange Online-u nije trivijalno. Microsoft Graph API nameće stroga ograničenja brzine (greška 429 Too Many Requests tokom noćnog batch-a dolazi brzo). Upravljanje S/MIME potpisanim ili PGP šifrovanim emailovima zahteva posebnu pažnju kako se ne bi poništili potpisi. Multipart strukture s velikim prilozima dodaju ograničenja na mrežne tajmaute. I pre svega: kako verifikovati, email po email, da je ispravka uspela bez menjanja sadržaja ili priloga?

Skript koji dobro radi na 50 test emailova neće se ponašati isto na sandučiću od 40.000 poruka s 8 godina istorije. Verovatnoća da granični slučaj nešto pokvari raste sa svakih hiljadu dodatnih poruka. A bez mehanizma za povratak, greška na pola puta ostavlja sandučić u nekonzistentnom stanju.

Pogledajte takođe: ispravka datuma emailova posle migracije na Microsoft 365 za potpun pregled dostupnih opcija.

Šta Redate.io konkretno radi

Redate.io se povezuje na Microsoft 365 tako što se korisnik prijavljuje sopstvenim Microsoft nalogom, bez portala i bez registracije aplikacije, besplatno skenira emailove s netačnim datumima, zatim primenjuje vlasnički motor za ispravku na identifikovane poruke. Pipeline višestepene analize vrši podudaranje na stotinama potpisa poznatih alata za migraciju, validaciju RFC usklađenosti i analizu lanca zaglavlja radi rekonstrukcije tačnih metapodataka datuma.

Svaki ispravljeni email se verifikuje pojedinačno. Originalne poruke se čuvaju u vidljivoj fascikli u vašem poštanskom sandučiću, dok ih sami ne obrišete. Model naplate je jednokratno plaćanje po poštanskom sandučiću, bez pretplate.

Novi Outlook tada prikazuje tačne datume, jer su serverski podaci ispravljeni, a ne maskirani.

Imate pogođene sandučiće na novom Outlooku? Pokrenite besplatno skeniranje na Redate.io kako biste tačno utvrdili koliko je emailova pogođeno pre nego što odlučite o daljem koraku.