Pogrešni datumi emailova nakon migracije na Exchange Online

Klasični scenarij ponedjeljkom ujutro

Upravo ste završili IMAP migraciju na Exchange Online. Batch se završio bez greške u centru za administraciju Exchange (EAC), sandučići su sinkronizirani, korisnici se mogu prijaviti. Zatvarate računalo u petak navečer s osjećajem dobro obavljenog posla.

Ponedjeljak ujutro, stižu tiketi. "Svi moji emailovi imaju datum od petka." "Inbox mi je beskoristan." "Nedostaju stari emailovi." Zapravo ništa ne nedostaje: emailovi su tu, ali Outlook ih prikazuje s datumom migracije umjesto originalnog datuma slanja. Email iz 2019. pojavljuje se s datumom prošlog petka. Rezultat: cijeli sandučić izgleda kao da sadrži samo nedavne poruke.

To je jedan od najfrustrantijih problema IMAP migracija na Exchange Online, i Microsoft ga gotovo sustavno nedovoljno dokumentira.

Zašto migracija putem EAC-a kvari datume

Kada koristite centar za administraciju Exchange (EAC) za konfiguriranje IMAP migracije s lokalnog poslužitelja (Dovecot, Courier, Cyrus, UW-IMAP, neovisno o kojemu), Exchange Online se spaja na izvorni poslužitelj putem IMAP-a, dohvaća poruke i ubacuje ih u odredišne sandučiće kroz vlastiti interni transportni pipeline.

Tu nastaje problem.

Svaki email koji prolazi kroz transportni pipeline Exchangea automatski dobiva vremenski označen Received: zaglavlje. To je standardno ponašanje SMTP i IMAP poslužitelja već desetljećima: svaki poslužitelj koji dotakne poruku na nju stavlja vlasteni vremenski pečat. Problem je što Outlook (posebno Outlook za Windows u novijim verzijama) koristi najnovije Received: zaglavlje kao referentu za prikaz kada su ostali metapodaci dvosmisleni.

Originalno zaglavlje Date: (ono koje označava kada je email zaista poslan, u smislu RFC 2822) uvijek je prisutno u poruci. Nije izbrisano. Ali postaje "zasjenjen" ovim novim Received: zaglavljem koje Exchange dodaje pri ubacivanju.

Istovremeno, IMAP INTERNALDATE (metapodatak koji IMAP poslužitelji koriste za interno datiranje poruka i koji upravlja sortiranjem u većini klijenata) postavlja se na datum ubacivanja, a ne na originalni datum emaila. Exchange Online nema nativni način za očuvanje INTERNALDATE-a s izvornog poslužitelja tijekom batch migracije putem EAC-a.

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

Treba razlikovati dvije situacije. S alatima poput BitTitan MigrationWiz ili CloudM Migrate, problem postoji, ali ti alati ponekad imaju opcije konfiguracije (djelomično dokumentirane, često skrivene u naprednim postavkama) koje pokušavaju sačuvati određene metapodatke o datumu.

Nativna migracija putem EAC-a ne nudi nikakvu takvu opciju. Microsoft ne izlaže nijedan parametar za kontrolu očuvanja INTERNALDATE-a u pipeline-u batch migracije. To je crna kutija: konfigurirate batch, pokrenete ga, Exchange interno radi što želi. A što radi, sustavno, jest datiranje poruka prema datumu njihovog ubacivanja.

(Inače, ako ste ikad pokušali čitati sirova zaglavlja emaila migriranog putem EAC-a, znate da je Received: zaglavlje koje Exchange dodaje prepoznatljivo iz tisuću milja: sadrži reference na interne Microsoftove poslužitelje poput *.protection.outlook.com ili *.prod.exchangelabs.com, s vremenskim pečatom koji točno odgovara vremenskom prozoru migracije.)

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

Instinktivna reakcija mnogih IT administratora na ovaj problem je pomisliti: "Ako izbrišem migrirane sandučiće i pokrenем batch od početka, možda će ovaj put datumi biti ispravni."

Razumljivo. Ali ne funkcionira.

Problem nije u konfiguraciji batcha. Nije u nekoj postavci koju smo zaboravili označiti. On je u samoj arhitekturi transportnog pipelinea Exchangea, koji je identičan pri svakoj migraciji. Ponovno pokretanje batcha dat će točno isti rezultat: ista Received: zaglavlja s novim datumom migracije, i isti netočni INTERNALDATE-i. Izgubili biste vrijeme, a korisnici bi bili uznemireni drugi put bez razloga.

Neki administratori pokušavaju i mijenjati postavke sortiranja u Outlooku ("sortiraj po datumu slanja" umjesto "datum primitka"). Sortiranje po datumu slanja nije rješenje. To je flaster. Zaglavlje Date: i INTERNALDATE ostaju netočni za klijente koji ne dopuštaju tu postavku, za OWA, za Outlook Mobile i za sve aplikacije trećih strana koje pristupaju sandučiću putem IMAP-a ili EWS-a.

Što se zapravo dogada u zaglavljima

Evo pojednostavnjenog primjera sadržaja emaila nakon migracije putem EAC-a. Originalno zaglavlje:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@staradomenska.hr
Subject: Izvješće Q1 2019

Nakon migracije, poruka na vrhu lanca zagljavlja dobiva 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 (dodano je na vrh bloka zaglavlja), interpretira ga kao najnoviji datum obrade poruke i prikazuje ga kao datum primitka. Originalno zaglavlje Date: iz 2019. i dalje je tu, netaknuto, nekoliko redaka niže. Ali Outlook ga ne koristi za prikaz u popisu poruka.

Da budemo precizni: ponašanje se neznatno razlikuje ovisno o verziji Outlooka. Verzije nakon 2021. (a posebno novi Outlook za Windows koji se uvodi od kraja 2023.) posebno su osjetljive na ovaj problem jer se više oslanjaju na Exchange Graph metapodatke nego na sirovo zaglavlje Date:. Što znači da migracije koje nisu uzrokovale vidljive probleme s Outlookom 2016 sada mogu biti problematične s novim Outlookom.

Tko je zapravo pogoden

Najčešći izvorni IMAP poslužitelji u ovoj vrsti migracije su Dovecot (jako rasprostranjen u Linux/cPanel okruženjima) i Courier. Oba izlažu INTERNALDATE putem IMAP-a koji EAC ne čuva. Ako migrirate s lokalnog Exchange poslužitelja 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 uzrokuje probleme.

Najteže pogodeni korisnici su oni s sandučićima koji imaju dugu povijest (5 godina i više) i visok volumen poruka. Korisnik s 300 emailova brzo će se oporaviti. Komercijalni direktor s 12.000 emailova sortiranih po datumu, o kojima svakodnevno ovisi za pronalaženje korespondencije s klijentima, on je paraliziran.

Zašto su vlastiti skripti loša ideja ovdje

Neki IT administratori koji razumiju tehnički problem u iskušenju su napisati PowerShell ili Python skriptu za ručno ispravljanje zaglavlja. Osnovna koncepcija može izgledati jednostavno kad se jednom identificira mehanizam. Ali stvarnost ispravka u produkciji je sasvim druga priča.

Prvo, rubni slučajevi. S/MIME potpisani emailovi i PGP šifrirane poruke imaju strukturu koja ne tolerira izmjenu zaglavlja bez poništavanja potpisa. Poruke s multipart/alternative strukturom i loše formiranim MIME granicama (česte na starim Courier poslužiteljima) mogu biti oštećene skriptom koja mijenja poruku bez pravilne rekonstrukcije strukture. Ne-ASCII zaglavlja kodirana prema RFC 2047 (imena pošiljatelja s naglašenim znakovima ili japanskim znakovima, na primjer) klasičan su izvor grešaka.

Zatim, volumen. Skripta koja 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 sata ujutro tijekom batcha od 8.000 poruka, bez mehanizma za nastavak, znači bijelu noć i potencijalno dvostruke ili izgubljene poruke.

I prije svega: kako provjeriti da je svaki ispravljeni email neoštećen? Da nijedan prilog nije odrezan, da nijedan nit razgovora nije slomljen, da su oznake i mape sačuvane? Bez mehanizma individualne provjere, samo se nadamo da je sve prošlo dobro.

Ispravak datuma nakon migracije problem je koji izgleda kao skripta od 50 linija, ali zahtijeva tisuće linija da bi bio pouzdan u produkciji.

Što Redate.io radi drugačije

Redate.io se spaja na Exchange Online putem Microsoft 365 API-ja (Azure Active Directory, delegirane dozvole na razini tenanta) i skenira zahvaćene sandučiće kako bi identificirao emailove čiji su metapodaci datuma pokvareni migracijom. Taj korak skeniranja je besplatan i daje točan pregled opsega problema: broj zahvaćenih poruka, zahvaćeni sandučići, raspon pokvarenih datuma.

Vlasnički motor za ispravak Redate.io-a zatim obrađuje svaki email individualno putem višestupanjskog pipeline-a analize koji uključuje prepoznavanje uzoraka na potpisima poznatih alata za migraciju (uključujući Exchange Online transportni pipeline), validaciju RFC sukladnosti i provjeru strukturnog integriteta poruke prije i nakon ispravka. S/MIME potpisani emailovi, složene MIME strukture, nestandardna kodiranja: svi se obrađuju specifičnim putevima obrade.

Svaka ispravljena poruka verificira se individualno. Originali se čuvaju u vidljivoj sigurnosnoj kopiji mape 30 dana. Ako nešto nije u redu s određenom porukom, ona se ne mijenja: Redate.io prijavljuje anomaliju umjesto da riskira oštećenje.

Tarifikacija je bazirana na volumenu, jednokratnom plaćanjem po sandučiću. Bez pretplate, bez ponavljajućih troškova. Ispravite problem jednom, gotovo je.

Konkretno za Exchange Online migracije, Redate.io podržava spajanje putem Azure AD aplikacijskih dozvola (bez potrebe za kreiranjem individualnih vjerodajnica po sandučiću), što čini obradu velikih flota sandučića mnogo jednostavnijim za orchestraciju za IT administratora ili MSP-a.

Ako upravljate s više klijenata koji su prošli ovu vrstu migracije, pogledajte i cjeloviti vodič za ispravak datuma nakon Microsoft 365 migracije za pregled različitih obuhvaćenih scenarija.

Emailovi su tu, originalni datumi također. Pokrenite besplatno skeniranje na Redate.io kako biste vidjeli točno koliko je poruka zahvaćeno u vašim Exchange Online sandučićima, prije nego odlučite što učiniti.