Napačni datumi e-pošte po selitvi Zoho v Microsoft 365

Kaj se je zgodilo z vašo e-poštno shranjevalniko

Pravkar ste dokončali selitev domene iz Zoho Mail v Microsoft 365. Infrastruktura Exchange Online je postavljena, nabiralniki so pripravljeni, MX zapisi posodobljeni. In nato, v ponedeljek zjutraj, uporabnik odpre Outlook in opazi, da vsi njegovi e-maili iz leta 2021 prikazujejo današnji datum. Drugi ugotovi, da so sporočila iz lanskega leta razvrščena na vrhu nabiralnika, kot da so ravnokar prispela. Zahtevki za podporo začnejo prihajati.

To ni napaka Outlooka. Ni niti specifičen problem Zoha. Gre za pričakovano, a slabo dokumentirano obnašanje vsake selitve prek IMAP v Exchange Online. Razumeti točno, zakaj se to zgodi, je prvi korak k pravilni odpravi.

Tehnični vzrok: INTERNALDATE in glave Received

E-poštno sporočilo, shranjeno na strežniku IMAP, je sestavljeno iz dveh ločenih delov: surove vsebine sporočila (glave RFC 2822, telo, priloge) in metapodatkov, ki jih upravlja strežnik IMAP, med katerimi je najpomembnejši INTERNALDATE. Prav ta metapodatek e-poštni odjemalci uporabljajo za prikaz in razvrščanje sporočil.

Glava Date: v surovem sporočilu (RFC 2822) predstavlja datum, ko je pošiljatelj sporočilo sestavil ali poslal. INTERNALDATE pa je datum, ko je strežnik IMAP sporočilo prejel ali shranil. Na zdravem strežniku sta ti dve vrednosti blizu ena drugi. Po selitvi je to druga zgodba.

Kako selitev prek IMAP pokvari datume

Ko orodje za selitev (Zoho Migration Wizard, imapsync, BitTitan ali katero koli drugo) prenese sporočilo iz Zoho Mail v Exchange Online, to stori prek protokola IMAP. Orodje se poveže z Zohom, prenese sporočilo in ga vstavi v Exchange Online z ukazom IMAP APPEND. Tu nastane težava.

Exchange Online ob prejemu vsakega sporočila ustvari novo glavo Received:, ki jo doda na začetek sporočila. Ta glava nosi točen datum in čas vstavljanja, torej datum selitve. Nekatera orodja poskušajo ohraniti prvotni INTERNALDATE tako, da ga posredujejo kot parameter ukazu APPEND. Druga tega ne storijo, ali pa to naredijo napačno, nakar Exchange Online samodejno dodeli datum prejema kot INTERNALDATE.

Rezultat: ne glede na to, ali je bilo sporočilo poslano leta 2019 ali 2022, njegov INTERNALDATE sedaj kaže na teden selitve. Outlook bere to vrednost prednostno. Razvrstitev se poruši.

Specifično obnašanje Zoho Migration Wizarda

Zoho ponuja lastno orodje za selitev s platforme: Zoho Migration Wizard. Orodje je praktično za preproste selitve, ima pa dokumentirano obnašanje na forumih administratorjev: prvotnega INTERNALDATE pri vstavljanju v ciljni strežnik ne posreduje vedno pravilno.

Natančneje, težava prizadene predvsem selitve na strežnike, ki sistematično dodajajo glavo Received: vsakemu dohajajočemu sporočilu, kar je točno obnašanje Exchange Onlinea. Tudi če Zoho Migration Wizard posreduje prvotni datum prek parametra APPEND, se glava Received:, ki jo ustvari Exchange Online, znajde na prvem mestu v verigi glav, Outlook pa jo uporabi za določanje, "kdaj je e-mail prispel".

Administratorji, ki za odhod iz Zoha uporabljajo splošna orodja IMAP, kot je imapsync, naletijo na popolnoma enak problem, včasih celo hujši, ker privzeta konfiguracija imap sync ni optimizirana za Exchange Online. (Mimogrede, če ste kdaj pregledovali dnevnik imapsync vrstico za vrstico ob dveh ponoči v iskanju napake sinhronizacije, veste, da je to zmogljivo, a ne ravno prizanesljivo orodje za robne primere.)

Zakaj Outlook prikazuje napačen datum

Outlook za prikaz datuma e-maila ne uporablja samo glave Date:. V večini prikazov se za razvrščanje nabiralnika uporablja INTERNALDATE, ki ga posreduje strežnik IMAP/Exchange. Prvotna glava Date: je sicer prisotna v sporočilu, nedotaknjena, a se ignorira v korist INTERNALDATE.

Zato možnost "Razvrsti po datumu pošiljanja" v Outlooku težave dejansko ne reši. Prikaže sicer drugačen datum, a obnašanje razvrščanja ostane nestabilno glede na različico Outlooka in način prikaza (združeni pogovori ali ne). Razvrščanje po datumu pošiljanja ni rešitev. Je obliž, ki odpade ob prvi posodobitvi odjemalca.

Dejanski obseg težave

Pri selitvi Zoho v Microsoft 365 srednje velikosti govorimo zlahka o 50.000 do 500.000 prizadetih sporočilih, odvisno od starosti nabiralnikov in velikosti organizacije. Vsak e-mail, prenesen med oknom selitve, nosi enako pokvaren datum, kar naredi težavo takoj vidno uporabnikom ob prvem odpiranju Outlooka.

Mape Poslano so pogosto najbolj problematične. Poslovni zastopnik, ki išče ponudbo, poslano marca 2022, bo preiskoval stotine e-mailov, ki vsi prikazujejo datum selitve. Operativni vpliv je realen, ne samo estetski.

In nasprotno od tega, kar bi kdo pričakoval, težava s časom ne izgine sama od sebe. INTERNALDATE je določen ob vstavljanju. Sam se ne popravi. Brez aktivnega posredovanja bodo e-maili ohranili pokvarjen datum nedoločen čas.

Zakaj je ročno popravljanje bolj tvegano, kot se zdi

Skušnjava je razumljiva: ker je prvotna glava Date: vedno v sporočilu, bi zadoščalo le... popraviti metapodatke. Na papirju je to logično. V praksi, na produkcijskem nabiralniku z 80.000 e-maili, je to operacija, ki gre lahko katastrofalno narobe.

Tu je nekaj robnih primerov, ki jih domači skript verjetno ne bo pravilno obravnaval:

• E-maili, podpisani s S/MIME, katerih podpis pokriva celotno strukturo glav. Vsaka sprememba v strukturi sporočila razveljavi kriptografski podpis.
• Sporočila, šifrirana s PGP, kjer je vsebina neprozorna in vsaka manipulacija z ovojnicami MIME lahko pokvari sporočilo.
• Glave, kodirane z non-ASCII po RFC 2047 (imena pošiljateljev s posebnimi znaki), ki se pokvarijo, če skript ne obravnava pravilno kodiranja.
• Priloge, kodirane v base64 z nepravilno zaključenimi vrsticami, nestandardnimi mejami MIME ali ugnezdenimi strukturami multipart.
• E-maili brez veljavne glave Date: (to obstaja, zlasti v starih izvozih iz Zoha), kjer mora skript sam odločiti, kaj storiti.

Skript, ki deluje na 50 testnih e-mailih, ne bo deloval na produkcijskem nabiralniku, izvoženem iz Zoha z leti zgodovine. In kako preveriti, sporočilo za sporočilom, da je vsak popravek celovit in da priloge niso bile okrnjene? Preverjanje je vsaj tako zahtevno kot samo popravljanje.

Obstaja še vprašanje kvot. API Exchange Online prek Microsoft Grafa uvaja stroge omejitve hitrosti (znane napake 429 Too Many Requests). Nepomirjen paket za 100.000 sporočil lahko sproži začasne blokade ali tihe napake, ki jih je po dejstvu težko diagnosticirati. Brez mehanizma za nadaljevanje po napaki začnete znova od začetka.

Kako Redate.io popravi datume po selitvi iz Zoha

Redate.io se poveže z vašim Microsoft 365 tenantom prek standardnih dovoljenj Azure AD, brez globalnega administratorskega dostopa. Začetno skeniranje je brezplačno: Redate.io identificira prizadete nabiralnike in oceni obseg e-mailov z napačnimi datumi, pri čemer primerja INTERNALDATE z vrednostmi v verigi glav sporočila.

Popravek uporablja lastniški popravni mehanizem, ki analizira celotno verigo glav vsakega sporočila, prepozna specifične podpise orodij za selitev iz Zoha (ne glede na to, ali gre za Zoho Migration Wizard ali imapsync, konfiguriran za odhod iz Zoha), in rekonstruira metapodatke o datumu prek večstopenjskega cevovoda za preverjanje. Vsak popravljen e-mail je preverjen posamezno: celovitost vsebine, ohranitev prilog, skladnost z RFC. Izvirniki so shranjeni v varnostni kopiji, dostopni 30 dni.

Brez ponovne selitve. Brez izpadov. Uporabniki nadaljujejo z Outlookom, medtem ko popravek poteka v ozadju.

Cena je enkratno plačilo, odvisno od obsega, brez naročnine. Podrobnosti so na voljo neposredno na spletnem mestu.

Sorodne situacije, ki jih je dobro poznati

Če upravljate več selitev hkrati, ali ste MSP in upravljate stranke, ki odhajajo iz Zoha, vedite, da se ista težava pojavi pri selitvah iz drugih platform v Exchange Online. Mehanika je identična: glava Received:, ki jo ustvari Exchange, prepiše INTERNALDATE ne glede na izvor.

Za selitve iz Google Workspacea, Exchange on-premises ali prek orodij, kot sta BitTitan MigrationWiz ali CloudM, so na blogu Redate.io na voljo namenska besedila z opisi obnašanja vsakega orodja. Za pregled vseh scenarijev, ki se końcajo v tem tenantcu, si oglejte Napačni datumi e-pošte po selitvi v Exchange Online.

Če selitev zajema skupne nabiralnike ali vire Exchange (sobe, oprema), je težava enaka, enaka orodja za popravek pa se prav tako uporabljajo. Vodniki na Popravek datumov selitve Exchange IMAP v Outlooku opisujejo korake za povezavo z vašim tenantom.

Za ekipe, ki za odhod iz Zoha specifično uporabljajo imapsync, stran imapsync ni ohranil datumov? Kako jih popraviti dokumentira konfiguracijske možnosti imapsync in zakaj na Exchange Onlineu ne zadoščajo.

Vaši datumi selitve iz Zoha so še vedno prikazani napačno v Outlooku? Brezplačno skenirajte svoje nabiralnike na Redate.io in preverite točen obseg težave, preden se odločite, kako ukrepati.