Pogrešni datumi emailova posle migracije na Exchange Online

Klasičan scenario ponedeljkom ujutru

Upravo ste završili IMAP migraciju na Exchange Online. Batch se završio bez grešaka u Exchange admin centru, sandučići su sinhronizovani, korisnici se mogu prijaviti. Zatvarate laptop u petak uveče sa osećajem dobro obavljenog posla.

U ponedeljak ujutru, tiketi počinju da pristižu. "Svi moji emailovi su datovani petkom." "Moja prijemna kutija je neupotrebljiva." "Nedostaju stari emailovi." Zapravo ništa ne nedostaje: emailovi su tu, ali Outlook ih sve prikazuje sa datumom migracije umesto originalnog datuma slanja. Email iz 2019. pojavljuje se kao da je stigao prošlog petka. Rezultat: cela kutija izgleda kao da sadrži samo nedavne poruke.

Ovo je jedan od najfrustrirajućih problema IMAP migracija na Exchange Online, i gotovo sistematski je nedovoljno dokumentovan od strane Microsoft-a.

Zašto migracija preko EAC-a kvari datume

Kada koristite Exchange admin centar (EAC) za podešavanje IMAP migracije sa lokalnog servera (Dovecot, Courier, Cyrus, UW-IMAP, svejedno), Exchange Online se konektuje na vaš izvorni server putem IMAP-a, preuzima poruke i ubacuje ih u odredišne sandučiće kroz sopstveni interni transportni pipeline.

Tu nastaje problem.

Svaki email koji prolazi kroz Exchange transportni pipeline automatski dobija vremenski označen Received: zaglavlje. To je standardno ponašanje SMTP i IMAP servera već decenijama: svaki server koji dotakne poruku dodaje svoj vremenski pečat. Problem je što Outlook (naročito Outlook za Windows u novijim verzijama) koristi najnovije Received: zaglavlje kao referentnu vrednost za prikaz kada su ostali metapodaci dvosmisleni.

Originalno Date: zaglavlje (ono koje govori kada je email zaista poslat, u smislu RFC 2822) i dalje je prisutno u poruci. Nije obrisano. Ali biva "zasenčeno" ovim novim Received: zaglavljem koje Exchange dodaje prilikom ubacivanja.

Paralelno s tim, IMAP INTERNALDATE (metapodatak koji IMAP serveri koriste za interno datiranje poruka i koji upravlja sortiranjem u većini klijenata) postavlja se na datum ubacivanja, ne na originalni datum emaila. Exchange Online nema nikakav nativan način da sačuva INTERNALDATE izvornog servera tokom batch migracije preko EAC-a.

EAC vs. alati trećih strana: važna razlika

Treba razlikovati dve situacije. Sa alatima kao što su BitTitan MigrationWiz ili CloudM Migrate, problem takođe postoji, ali ovi alati ponekad imaju opcije konfiguracije (delimično dokumentovane, često skrivene u naprednim podešavanjima) koje pokušavaju da sačuvaju određene metapodatke datuma.

Nativna migracija putem EAC-a, pak, ne nudi nikakvu takvu opciju. Microsoft ne izlaže nikakav parametar za kontrolu čuvanja INTERNALDATE-a u batch migration pipelineu. To je crna kutija: podesite batch, pokrenete ga, Exchange interno radi šta hoće. A ono što radi, sistematski, jeste datiranje poruka prema trenutku ubacivanja.

(Inače, ako ste ikada pokušali da čitate sirova zaglavlja emaila migriranog putem EAC-a, znate da je Received: zaglavlje koje Exchange dodaje prepoznatljivo na prvi pogled: sadrži reference na Microsoft interne servere poput *.protection.outlook.com ili *.prod.exchangelabs.com, sa vremenskom oznakom koja tačno odgovara prozoru migracije.)

Zašto ponovno kreiranje batcha ne rešava ništa

Instinktivna reakcija mnogih IT administratora suočenih sa ovim problemom je da pomisle: "Ako obrišem migrirane sandučiće i ponovo pokrenem batch od nule, možda će ovaj put datumi biti ispravni."

Razumljivo. Ali ne funkcioniše.

Problem nije u konfiguraciji batcha. Nije u parametru koji ste zaboravili da čekirate. On leži u samoj arhitekturi Exchange transportnog pipelinea, koji je identičan pri svakoj migraciji. Ponovno pokretanje batcha daće tačno isti rezultat: ista Received: zaglavlja sa novim datumom migracije, i isti pogrešni INTERNALDATE. Izgubili biste vreme, a korisnici bi bili uznemireni po drugi put - bez ikakvog razloga.

Neki administratori pokušavaju i da promene parametre sortiranja u Outlooku ("sortiraj po datumu slanja" umesto "datuma prijema"). Sortiranje po datumu slanja nije rešenje. To je flaster. Date: zaglavlje i INTERNALDATE ostaju pogrešni za klijente koji ne dozvoljavaju ovo podešavanje, za OWA, za Outlook Mobile, i za svaku aplikaciju treće strane koja pristupa sandučiću putem IMAP-a ili EWS-a.

Šta se zapravo dešava u zaglavljima

Evo pojednostavljenog primera sadržaja emaila posle migracije putem EAC-a. Originalno zaglavlje:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@stariidomen.rs
Subject: Izvestaj Q1 2019

Posle migracije, poruka na vrhu lanca zaglavlja dobija nešto poput:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook vidi ovo Received: zaglavlje prvo (dodato je na vrh bloka zaglavlja), interpretira ga kao najnoviji datum obrade poruke, i prikazuje ga kao datum prijema. Originalno Date: zaglavlje iz 2019. i dalje je tu, netaknuto, nekoliko redova niže. Ali Outlook ga ne koristi za prikaz u listi poruka.

Da budemo precizni: ponašanje se neznatno razlikuje u zavisnosti od verzije Outlooka. Verzije posle 2021. (a naročito novi Outlook za Windows koji se uvodi od kraja 2023.) posebno su osetljive na ovaj problem jer se više oslanjaju na Exchange Graph metapodatke nego na sirovo Date: zaglavlje. Što znači da migracije koje nisu izazivale vidljiv problem sa Outlook 2016. sada mogu biti problematične sa novim Outlookom.

Ko je zaista pogođen

Najčešći IMAP izvorni serveri u ovakvim migracijama su Dovecot (veoma rasprostranjen u Linux/cPanel okruženju) i Courier. Oba izlažu INTERNALDATE vrednosti putem IMAP-a koje EAC ne čuva. Ako migrujete sa lokalnog Exchange servera na Exchange Online (hibridna ili cutover migracija), ponašanje je drugačije jer Microsoft koristi interni transportni protokol (MAPI/EWS) koji bolje čuva metapodatke. Generička IMAP migracija putem EAC-a je ta koja pravi problem.

Najteže pogođeni su korisnici sa sandučićima koji imaju dugačku istoriju (5 godina i više) i veliki obim poruka. Korisnik sa 300 emailova brzo će se snaći. Komercijalni direktor sa 12.000 emailova sortiranih po datumu, na koje se svakodnevno oslanja pri pronalaženju prepiske sa klijentima, njemu je rad paralizovan.

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

Neki IT administratori koji razumeju tehnički problem pokušani su da napišu PowerShell ili Python skript za ručno ispravljanje zaglavlja. Osnovna ideja može izgledati jednostavno nakon što se identifikuje mehanizam. Ali realnost ispravke u produkciji je sasvim druga priča.

Najpre, granični slučajevi. S/MIME potpisani emailovi i PGP šifrovane poruke imaju strukturu koja ne toleriše izmenu zaglavlja bez poništavanja potpisa. Poruke tipa multipart/alternative sa loše formiranim MIME granicama (česte na starim Courier serverima) mogu biti oštećene skriptom koji menja poruku bez ispravnog rekonstruisanja strukture. Non-ASCII zaglavlja enkodovana prema RFC 2047 (imena pošiljalaca sa akcentovanim znakovima ili japanskim karakterima, na primer) klasičan su izvor grešaka.

Zatim, volumen. Skript koji radi na 50 testnih emailova u razvojnom okruženju ne upravlja ograničenjima brzine Exchange Online API-ja u produkciji. Greška 429 Too Many Requests u 2 ujutru tokom batcha od 8.000 poruka, bez mehanizma za nastavak, znači belu noć i potencijalno duplirane ili izgubljene poruke.

I, pre svega: kako verifikovati da je svaki ispravljen email neoštećen? Da nijedan prilog nije skraćen, da nijedan niz poruka nije polomljen, da su labele i folderi sačuvani? Bez mehanizma individualne validacije, samo se nadate da je sve prošlo kako treba.

Ispravka datuma posle migracije je problem koji liči na skript od 50 linija, ali zahteva hiljade linija da bi bio pouzdan u produkciji.

Šta Redate.io radi drugačije

Redate.io se konektuje na Exchange Online putem Microsoft 365 API-ja (Azure Active Directory, delegirane dozvole na nivou tenanta) i skenira pogođene sandučiće da bi identifikovao emailove čiji su metapodaci datuma oštećeni migracijom. Ovaj korak skeniranja je besplatan i daje tačnu sliku obima problema: broj pogođenih poruka, pogođeni sandučići, opseg pokvarenih datuma.

Redate.io-ov vlasnički engine za ispravku potom obrađuje svaki email pojedinačno putem višestepenog pipelinea analize koji uključuje podudaranje obrazaca na osnovu poznatih potpisa alata za migraciju (uključujući Exchange Online transportni pipeline), validaciju RFC usklađenosti, i proveru strukturnog integriteta poruke pre i posle ispravke. S/MIME potpisani emailovi, složene MIME strukture, nestandardna enkodiranja: svi se obrađuju posebnim putanjama obrade.

Svaka ispravljena poruka se verifikuje pojedinačno. Originali se čuvaju u vidljivom backup folderu 30 dana. Ako nešto ne valja sa određenom porukom, ona se ne menja: Redate.io prijavljuje anomaliju umesto da rizikuje oštećenje.

Cena je zasnovana na volumenu, kao jednokratna uplata po sandučiću. Bez pretplate, bez ponavljajućih troškova. Ispravite problem jednom, gotovo.

Za Exchange Online migracije konkretno, Redate.io podržava konekciju putem Azure AD application dozvola (bez potrebe za kreiranjem pojedinačnih kredencijala po sandučiću), što čini obradu velikih flota sandučića mnogo jednostavnijom za IT administratore i MSP-ove.

Ako upravljate više klijenata koji su prošli ovakvu migraciju, pogledajte i kompletan vodič za ispravku datuma posle migracije na Microsoft 365 za pregled svih pokrivenih scenarija.

Emailovi su tu, originalni datumi takođe. Pokrenite besplatno skeniranje na Redate.io da vidite tačno koliko je poruka pogođeno u Vašim Exchange Online sandučićima, pre nego što odlučite šta da radite.