Pogrešni datumi emailova posle migracije Zoho na Microsoft 365

Šta se desilo sa Vašim sandučićem

Upravo ste završili migraciju domena sa Zoho Mail na Microsoft 365. Exchange Online infrastruktura je postavljena, sandučići su provizovani, MX zapisi su ažurirani. I onda, u ponedeljak ujutro, korisnik otvori Outlook i primeti da svi njegovi emailovi iz 2021. prikazuju današnji datum. Drugi korisnik vidi da su mu poruke od prošle godine poredane na vrhu inbox-a, kao da su upravo stigle. Tiketi počinju da pristižu.

Ovo nije bag Outlooka. Nije ni problem specifičan za Zoho. Ovo je ponašanje koje se može očekivati, ali je loše dokumentovano, kod svake IMAP migracije prema Exchange Online. Razumeti tačno zašto se to dešava je prvi korak ka ispravnom rešavanju problema.

Tehnički uzrok: INTERNALDATE i Received zaglavlja

Email koji se čuva na IMAP serveru sastoji se od dve odvojene stvari: sirovog sadržaja poruke (RFC 2822 zaglavlja, telo, prilozi) i metapodataka o skladištenju kojim upravlja IMAP server, a u koje spada i INTERNALDATE. Upravo taj metapodatak email klijenti koriste za prikaz i sortiranje poruka.

Zaglavlje Date: definisano u sirovoj poruci (RFC 2822) predstavlja datum kada je poruka sastavljena ili poslata od strane pošiljaoca. INTERNALDATE, s druge strane, je datum kada je IMAP server primio ili uskladištio poruku. Normalno, na zdravom serveru, ove dve vrednosti su bliske. Posle migracije, to je sasvim druga priča.

Kako IMAP migracija kvari datume

Kada alat za migraciju (Zoho Migration Wizard, imapsync, BitTitan ili bilo koji drugi) prenosi poruku sa Zoho Mail na Exchange Online, to radi putem IMAP protokola. Alat se poveže na Zoho, preuzme poruku, a zatim je ubaci u Exchange Online putem IMAP APPEND komande. I tu nastaje problem.

Exchange Online, pri prijemu svake poruke, generiše novo zaglavlje Received: koje dodaje na početak poruke. To zaglavlje nosi tačan datum i vreme ubacivanja, to jest datum migracije. Neki alati za migraciju pokušavaju da sačuvaju originalni INTERNALDATE prosleđujući ga kao parametar APPEND komandi. Drugi to ne rade, ili rade netačno, u kom slučaju Exchange Online automatski dodeljuje datum prijema kao INTERNALDATE.

Rezultat: bez obzira na to da li je email poslat 2019. ili 2022. godine, njegov INTERNALDATE sada pokazuje na nedelju migracije. Outlook čita tu vrednost kao prioritetnu. Sortiranje se urušava.

Specifično ponašanje Zoho Migration Wizarda

Zoho nudi sopstveni alat za migraciju pri napuštanju platforme: Zoho Migration Wizard. Taj alat je praktičan za jednostavne migracije, ali ima dokumentovano ponašanje na administratorskim forumima: ne prenosi uvek ispravno originalni INTERNALDATE pri ubacivanju na odredišni server.

Da budemo precizni, problem pre svega pogađa migracije prema serverima koji sistematski dodaju zaglavlje Received: svakoj dolaznoj poruci, što je upravo ponašanje Exchange Online. Čak i ako Zoho Migration Wizard prosledi originalni datum kao APPEND parametar, zaglavlje Received: koje generiše Exchange Online završava na prvom mestu u lancu zaglavlja, i Outlook ga koristi da odredi "kada je email stigao".

Admini koji koriste generičke IMAP alate poput imapsync za napuštanje Zoho platforme nailaze na tačno isti problem, ponekad i u goroj formi, jer podrazumevana konfiguracija imapsync nije optimizovana za Exchange Online. (Uzgred, ako ste ikad prelistavali imapsync log red po red u potrazi za greškom sinhronizacije u 2 ujutro, znate da je to moćan alat, ali nije baš naklonjen graničnim slučajevima.)

Zašto Outlook prikazuje pogrešan datum

Outlook ne koristi isključivo zaglavlje Date: za prikaz datuma emaila. U većini prikaza koristi se INTERNALDATE koji obezbeđuje IMAP/Exchange server, posebno za sortiranje inbox-a. Originalno zaglavlje Date: je i dalje prisutno u poruci, netaknuto, ali se ignoriše u korist INTERNALDATE vrednosti.

Zato opcija "Sortiraj po datumu slanja" u Outlooku zapravo ne rešava problem. Prikazuje drugačiji datum, tačno, ali ponašanje sortiranja ostaje nestabilno u zavisnosti od verzije Outlooka i načina prikaza (grupisani razgovori ili ne). Sortiranje po datumu slanja nije rešenje. To je flaster koji otpadne pri prvom ažuriranju klijenta.

Stvarni obim problema

Na Zoho migraciji ka Microsoft 365 srednje veličine, lako se može govoriti o 50.000 do 500.000 pogođenih poruka, u zavisnosti od starosti sandučića i veličine organizacije. Svaki email prenet tokom migracionog prozora nosi isti pokvareni datum, što korisnicima odmah postaje vidljivo čim prvi put otvore Outlook.

Folder Poslato je često najproblematičniji. Prodavac koji traži ponudu poslatu u martu 2022. mora da pretražuje stotine emailova koji svi prikazuju datum migracije. Operativni uticaj je realan, nije samo estetski.

I za razliku od onoga što bismo možda mislili, problem ne nestaje sam od sebe vremenom. INTERNALDATE se fiksira u trenutku ubacivanja. Ne ispravlja se sam. Bez aktivne intervencije, emailovi će zauvek zadržati pokvareni datum.

Zašto je ručno ispravljanje rizičnije nego što izgleda

Iskušenje je razumljivo: pošto je originalno zaglavlje Date: i dalje u poruci, dovoljno je... ispraviti metapodatke. Na papiru, logično. U praksi, na produkcijskom sandučiću sa 80.000 emailova, to je operacija koja može da krene katastrofalno naopako.

Evo nekoliko graničnih slučajeva koje kućni skript verovatno neće dobro obraditi:

• S/MIME potpisani emailovi, čiji potpis pokriva sva zaglavlja. Menjanje bilo čega u strukturi poruke poništava kriptografski potpis.
• PGP šifrovane poruke, gde je sadržaj neproziran i svaka manipulacija MIME omotača može da pokvari poruku.
• Zaglavlja koja nisu ASCII, enkodirana po RFC 2047 (imena pošiljalaca sa specijalnim znakovima), koja se lome ako skript ne obrađuje enkodiranje ispravno.
• Prilozi enkodovani u base64 sa loše završenim linijama, nestandardnim MIME granicama ili ugnežđenim multipart strukturama.
• Emailovi bez validnog zaglavlja Date: (takvi postoje, posebno u starim Zoho izvozima), gde skript mora da odluči šta da uradi.

Skript koji radi na 50 test emailova neće raditi na produkcijskom sandučiću sa Zoho istorijom od više godina. A kako proveriti, poruku po poruku, da je svaka ispravka netaknuta i da prilozi nisu odrezani? Verifikacija je barem jednako složena kao i sama ispravka.

Tu je i pitanje kvota. Exchange Online API, putem Microsoft Graph-a, nameće stroge limite zahteva (čuvene greške 429 Too Many Requests). Batch bez regulacije brzine na 100.000 poruka može da izazove privremena blokiranja ili tihe greške koje je teško dijagnostikovati naknadno. Bez mehanizma za nastavak od tačke prekida, krećete ispočetka.

Kako Redate.io ispravlja datume posle Zoho migracije

Redate.io se konektuje na Vaš Microsoft 365 tenant putem standardnih Azure AD dozvola, bez globalnog admin pristupa. Inicijalni sken je besplatan: Redate.io identifikuje pogođene sandučiće i procenjuje obim emailova sa neispravnim datumima, upoređujući INTERNALDATE sa vrednostima koje nosi lanac zaglavlja poruke.

Ispravka koristi vlasničke mehanizme koji analiziraju kompletan lanac zaglavlja svake poruke, identifikuju specifične potpise Zoho alata za migraciju (bilo da je u pitanju Zoho Migration Wizard ili imapsync konfigurisan za polazak sa Zoho platforme), i rekonstruišu metapodatke datuma kroz višestepeni pipeline validacije. Svaki ispravljeni email se proverava pojedinačno: integritet sadržaja, očuvanje priloga, RFC usklađenost. Originali se čuvaju u backup folderu dostupnom 30 dana.

Nema ponovne migracije. Nema zastoja. Korisnici nastavljaju da koriste Outlook dok se ispravka izvodi u pozadini.

Cena je jednokratno plaćanje na osnovu volumena, bez pretplate. Detalji su dostupni direktno na sajtu.

Srodne situacije koje treba imati na umu

Ako upravljate nekoliko migracija paralelno, ili ste MSP koji administrira klijente koji napuštaju Zoho, imajte na umu da se isti problem javlja i pri migracijama sa drugih platformi ka Exchange Online. Mehanizam je identičan: zaglavlje Received: koje generiše Exchange pregazuje INTERNALDATE bez obzira na izvorišnu platformu.

Za migracije sa Google Workspace-a, sa Exchange on-premises servera, ili putem alata kao što su BitTitan MigrationWiz ili CloudM, posvećeni članci na Redate.io blogu detaljno opisuju specifična ponašanja svakog alata. Više o svim scenarijima koji pogađaju ovaj tenant možete pronaći u člancima o pogrešnim datumima emailova posle migracije na Exchange Online.

Ako Vaša migracija uključuje deljene sandučiće ili Exchange resurse (sale, opremu), problem je isti i isti alati za ispravku se primenjuju. Vodič na ispravci datuma Exchange IMAP migracije na sajtu Redate.io detaljno opisuje korake za konektovanje na Vaš tenant.

Za timove koji koriste imapsync specifično za napuštanje Zoho platforme, članak imapsync: datumi nisu sačuvani dokumentuje opcije konfiguracije imapsync i zašto nisu dovoljne da se problem na Exchange Online izbegne.

Datumi Zoho migracije se i dalje prikazuju u Outlooku? Skenirajte Vaše sandučiće besplatno na Redate.io da izmerite tačan obim problema pre nego što odlučite kako da reagujete.