Pogrešni datumi emailova nakon Zoho migracije na Microsoft 365

Što se dogodilo s Vašim sandučićem

Upravo ste dovršili migraciju domene s Zoho Maila na Microsoft 365. Exchange Online infrastruktura je postavljena, sandučići su provisioniran, MX zapisi su ažurirani. I onda, u ponedjeljak ujutro, korisnik otvori Outlook i primijeti da svi njegovi emailovi iz 2021. prikazuju današnji datum. Drugi korisnik vidi da su mu poruke od prošle godine poredane na vrhu pristigle pošte, kao da su tek stigle. Tiketi počinju pristizati.

Nije to greška Outlooka. Nije ni problem specifičan za Zoho. To je očekivano, ali slabo dokumentirano ponašanje svake IMAP migracije prema Exchange Onlineu, i razumijevanje točno zašto se to događa prvi je korak prema ispravnom rješavanju.

Tehnički uzrok: INTERNALDATE i Received zaglavlja

Email pohranjen na IMAP poslužitelju sastoji se od dvije različite stvari: sirovog sadržaja poruke (RFC 2822 zaglavlja, tijelo, privitci) i metapodataka pohrane kojima upravlja IMAP poslužitelj, od kojih je najvažniji INTERNALDATE. Upravo taj metapodatak koriste klijenti za prikaz i sortiranje poruka.

Zaglavlje Date: definirano u sirovoj poruci (RFC 2822) predstavlja datum kada je poruka sastavljena ili poslana od strane pošiljatelja. INTERNALDATE je, pak, datum kada je IMAP poslužitelj primio ili pohranio poruku. Na zdravom poslužitelju te dvije vrijednosti su obično bliske. Nakon migracije, priča je sasvim drugačija.

Kako IMAP migracija kvari datume

Kada alat za migraciju (Zoho Migration Wizard, imapsync, BitTitan ili bilo koji drugi) prenosi poruku iz Zoho Maila u Exchange Online, to čini putem IMAP protokola. Alat se spoji na Zoho, preuzme poruku, a zatim je umetne u Exchange Online putem IMAP APPEND naredbe. I tu počinju problemi.

Exchange Online pri primitku svake poruke generira novo zaglavlje Received: koje dodaje na početak poruke. To zaglavlje nosi točan datum i vrijeme umetanja, to jest datum migracije. Neki alati za migraciju pokušavaju sačuvati originalni INTERNALDATE predajući ga kao parametar APPEND naredbi. Drugi to ne čine, ili to rade pogrešno, pa Exchange Online automatski dodjeljuje datum primitka kao INTERNALDATE.

Rezultat: bio email poslan 2019. ili 2022., njegov INTERNALDATE sada pokazuje na tjedan migracije. Outlook tu vrijednost čita s prioritetom. Sortiranje se raspada.

Specifično ponašanje Zoho Migration Wizarda

Zoho nudi vlastiti alat za migraciju pri napuštanju platforme: Zoho Migration Wizard. Taj alat je praktičan za jednostavne migracije, ali ima dokumentirano ponašanje na administratorskim forumima: ne prenosi uvijek ispravno originalni INTERNALDATE pri umetanju na odredišni poslužitelj.

Da budemo precizniji, problem najviše pogađa migracije prema poslužiteljima koji sustavno dodaju zaglavlje Received: svakoj dolaznoj poruci, što je upravo ponašanje Exchange Onlinea. Čak i ako Zoho Migration Wizard preda originalni datum putem APPEND parametra, zaglavlje Received: koje generira Exchange Online naći će se na prvom mjestu u lancu zaglavlja, a Outlook ga koristi za određivanje "kada je email stigao".

Administratori koji koriste generičke IMAP alate poput imapsynca za napuštanje Zohoa nailaze na potpuno isti problem, ponekad i gori, jer zadana konfiguracija imapsynca nije optimizirana za Exchange Online. (Inače, ako ste ikada prolazili kroz imapsync log red po red u potrazi za greškom sinkronizacije u 2 ujutro, znate da je to moćan alat koji nije posebno blag prema rubnim slučajevima.)

Zašto Outlook prikazuje krivi datum

Outlook ne koristi samo zaglavlje Date: za prikaz datuma emaila. U većini prikaza koristi se INTERNALDATE koji dostavlja IMAP/Exchange poslužitelj, osobito za sortiranje pristigle pošte. Originalno zaglavlje Date: i dalje je prisutno u poruci, netaknuto, ali se ignorira u korist INTERNALDATEa.

Zato opcija "Sortiraj po datumu slanja" u Outlooku zapravo ne rješava problem. Prikazuje drugačiji datum, to jest točno, ali ponašanje sortiranja ostaje nestabilno ovisno o verziji Outlooka i načinu prikaza (grupirani razgovori ili ne). Sortiranje po datumu slanja nije rješenje. To je flaster koji otpadne pri prvoj nadogradnji klijenta.

Stvarni opseg problema

Na migraciji Zoho prema Microsoft 365 srednje veličine, lako je zahvaćeno između 50.000 i 500.000 poruka, ovisno o starosti sandučića i veličini organizacije. Svaki email prenesen tijekom migracijskog prozora nosi isti oštećeni datum, što problem čini odmah vidljivim korisnicima pri prvom otvaranju Outlooka.

Mape Poslano često su najproblematičnije. Prodajni djelatnik koji traži ponudu poslanu u ožujku 2022. mora pretraživati stotine emailova koji svi prikazuju datum migracije. Operativni utjecaj je stvaran, nije samo estetski.

Za razliku od onoga što bi se moglo pomisliti, problem ne nestaje s vremenom. INTERNALDATE se postavlja u trenutku umetanja. Ne ispravlja se sam od sebe. Bez aktivne intervencije, emailovi će zauvijek zadržati oštećeni datum.

Zašto je ručna korekcija riskantnija nego što izgleda

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

Evo nekoliko rubnih slučajeva s kojima se kućni skript vjerojatno neće dobro nositi:

• S/MIME potpisani emailovi, čiji potpis pokriva sva zaglavlja. Svaka izmjena u strukturi poruke poništava kriptografski potpis.
• PGP šifrirane poruke, gdje je sadržaj neproziran i svaka manipulacija MIME omotima može oštetiti poruku.
• Non-ASCII zaglavlja kodirana prema RFC 2047 (nazivi pošiljatelja s posebnim znakovima), koja se pokvare ako skript ne rukuje ispravno kodiranjem.
• Privitci kodirani u base64 s loše završenim recima, nestandardnim MIME granicama ili ugniježđenim multipart strukturama.
• Emailovi bez valjanog zaglavlja Date: (to postoji, osobito u starim Zoho izvozima), gdje skript mora odlučiti što učiniti.

Skript koji radi na 50 testnih emailova neće raditi na produkcijskom Zoho sandučiću s godinama arhive. I kako provjeriti, poruku po poruku, da je svaka korekcija netaknuta i da privitci nisu skraćeni? Verifikacija je barem jednako složena kao i sama korekcija.

Tu je i pitanje kvota. Exchange Online API, putem Microsoft Grapha, nameće stroga ograničenja brzine (poznate 429 Too Many Requests greške). Batch bez throttlinga na 100.000 poruka može izazvati privremene blokade ili tihe greške koje je teško dijagnosticirati naknadno. Bez mehanizma za nastavak nakon prekida, počinjete ispočetka.

Kako Redate.io ispravlja datume nakon Zoho migracije

Redate.io spaja se na Vaš Microsoft 365 tenant putem standardnih Azure AD dozvola, bez globalnog admin pristupa. Početno skeniranje je besplatno: Redate.io identificira zahvaćene sandučiće i procjenjuje volumen emailova s netočnim datumima, uspoređujući INTERNALDATE s vrijednostima u lancu zaglavlja poruke.

Korekcija koristi vlasnički motor koji analizira kompletan lanac zaglavlja svake poruke, identificira specifične potpise Zoho migracijskih alata (bilo da se radi o Zoho Migration Wizardu ili imapsyncu konfiguriranom za odlazak iz Zohoa), te rekonstruira metapodatke datuma putem višefaznog validacijskog pipelina. Svaki ispravljeni email se individualno verificira: integritet sadržaja, očuvanje privitaka, RFC sukladnost. Originali se čuvaju u sigurnosnoj kopiji dostupnoj 30 dana.

Nema ponovne migracije. Nema zastoja. Korisnici nastavljaju koristiti Outlook dok se korekcija izvodi u pozadini.

Cijena je jednokratna uplata ovisno o volumenu, bez pretplate. Detalji su dostupni izravno na web-stranici.

Srodne situacije koje treba poznavati

Ako upravljate više migracija paralelno, ili ste MSP koji administrira klijente koji napuštaju Zoho, imajte na umu da se isti problem pojavljuje pri migracijama s drugih platformi prema Exchange Onlineu. Mehanika je identična: zaglavlje Received: koje generira Exchange zamjenjuje INTERNALDATE bez obzira na izvor.

Za migracije s Google Workspacea, s on-premises Exchangea ili putem alata poput BitTitan MigrationWiza ili CloudMa, detaljni članci na blogu Redatea opisuju ponašanja specifična za svaki alat. Članak Pogrešni datumi emailova nakon migracije na Exchange Online daje pregled svih scenarija koji završavaju na tom tenanu.

Ako Vaša migracija uključuje dijeljene sandučiće ili Exchange resurse (sobe, opremu), problem je isti, a isti alati za korekciju se primjenjuju. Članak o datumima dijeljenih poštanskih pretinaca detaljno opisuje specifičnosti tih scenarija.

Za timove koji koriste imapsync specifično za napuštanje Zohoa, članak imapsync: datumi nisu sačuvani dokumentira opcije konfiguracije imapsynca i zašto one nisu dovoljne za izbjegavanje problema na Exchange Onlineu.

Datumi Zoho migracije i dalje se prikazuju u Outlooku? Skenirajte Vaše sandučiće besplatno na Redate.io kako biste izmjerili točan opseg problema prije nego što odlučite kako djelovati.