Klaidingos datos po Zoho migracijos į Microsoft 365

Kas nutiko jūsų pašto dėžutei

Ką tik baigėte domeno migraciją iš Zoho Mail į Microsoft 365. Exchange Online infrastruktūra sukonfigūruota, dėžutės sukurtos, MX įrašai atnaujinti. Tada pirmadienio rytą vienas iš vartotojų atidaro Outlook ir pastebi, kad visi jo 2021 metų laiškai rodo šiandienos datą. Kitas supranta, kad pernykščiai žinutės atsidūrė gautų laiškų viršuje, tarsi būtų ką tik atėjusios. Palaipsniui pradeda plūsti palaikymo užklausos.

Tai nėra Outlook klaida. Tai nėra ir Zoho specifinė problema. Tai lauktas, bet prastai dokumentuotas bet kokios IMAP migracijos į Exchange Online elgesys. Tiksliai suprasti, kodėl taip nutinka, yra pirmas žingsnis norint tai tinkamai ištaisyti.

Techninė priežastis: INTERNALDATE ir Received antraštės

El. laiškas, saugomas IMAP serveryje, susideda iš dviejų atskirų dalių: neapdoroto pranešimo turinio (RFC 2822 antraštės, turinys, priedai) ir saugojimo metaduomenų, kuriuos valdo IMAP serveris, įskaitant INTERNALDATE. Būtent šis metaduomuo domina pašto programas, kai jos rodo ir rikiuoja laiškus.

Antraštė Date:, apibrėžta neapdorotame pranešime pagal RFC 2822, nurodo datą, kada laiškas buvo parengtas ar išsiųstas siuntėjo. O INTERNALDATE yra data, kada IMAP serveris gavo arba išsaugojo pranešimą. Įprastai, sveikame serveryje, šios dvi reikšmės būna artimos. Po migracijos - visai kas kita.

Kaip IMAP migracija sugadina datas

Kai migracijos įrankis (Zoho Migration Wizard, imapsync, BitTitan ar bet kuris kitas) perkelia pranešimą iš Zoho Mail į Exchange Online, tai daroma naudojant IMAP protokolą. Įrankis prisijungia prie Zoho, pasiima laišką, tada jį įterpia į Exchange Online per komandą IMAP APPEND. Čia ir prasideda bėdos.

Exchange Online, gavęs kiekvieną pranešimą, sugeneruoja naują antraštę Received: ir prideda ją pranešimo pradžioje. Ši antraštė turi tikslią įterpimo datą ir laiką, tai yra migracijos datą. Kai kurie migracijos įrankiai bando išsaugoti originalų INTERNALDATE perduodami jį kaip parametrą APPEND komandai. Kiti to nedaro, arba daro neteisingai, tokiu atveju Exchange Online automatiškai priskiria gavimo datą kaip INTERNALDATE.

Rezultatas: nesvarbu, ar laiškas buvo išsiųstas 2019-aisiais ar 2022-aisiais, jo INTERNALDATE dabar rodo migracijos savaitę. Outlook šią reikšmę nuskaito pirma. Rikiavimas sugriūva.

Zoho Migration Wizard specifinis elgesys

Zoho siūlo savo migracijos įrankį išeinant iš platformos: Zoho Migration Wizard. Šis įrankis patogus paprastoms migracijoms, tačiau administratorių forumuose fiksuotas konkretus elgesys: jis ne visada teisingai perduoda originalų INTERNALDATE įterpiant į paskirties serverį.

Tiksliau sakant, problema daugiausia liečia migracijas į serverius, kurie sistemingai prideda antraštę Received: prie kiekvieno gaunamo pranešimo, o tai yra lygiai Exchange Online elgesys. Net jei Zoho Migration Wizard perduoda originalią datą per APPEND parametrą, Exchange Online sugeneruota antraštė Received: atsiduria pirmoje vietoje antraščių grandinėje, ir Outlook ją naudoja nustatant, "kada el. laiškas atėjo".

Administratoriai, naudojantys bendruosius IMAP įrankius kaip imapsync išeinant iš Zoho, susiduria lygiai su ta pačia problema, kartais dar aštriau, nes numatytoji imapsync konfigūracija nėra optimizuota Exchange Online. (Beje, jei esate kada nors peržiūrėję imapsync žurnalą eilutė po eilutės ieškodami sinchronizavimo klaidos naktį 2 valandą, žinote, kad tai galingas įrankis, bet tikrai ne atleistinas kraštutiniais atvejais.)

Kodėl Outlook rodo neteisingą datą

Outlook nenaudoja vien antraštės Date: el. laiško datai rodyti. Daugeliu atvejų naudojamas INTERNALDATE, kurį pateikia IMAP/Exchange serveris, ypač rikiuojant gautų laiškų dėžutę. Originalus Date: antraštė pranešime yra, nepakitusi, bet ji ignoruojama INTERNALDATE naudai.

Štai kodėl parinktis "Rikiuoti pagal siuntimo datą" Outlook programoje tikrai neišsprendžia problemos. Ji rodo kitą datą, taip, bet rikiavimo elgesys išlieka nestabilus priklausomai nuo Outlook versijos ir rodinio režimo (sugrupuotos pokalbiai ar ne). Rikiavimas pagal siuntimo datą nėra sprendimas. Tai pleistras, kuris nukris pirmojo kliento atnaujinimo metu.

Tikrasis problemos mastas

Vidutinės apimties Zoho į Microsoft 365 migracijoje lengvai kalbame apie 50 000 iki 500 000 paveiktų pranešimų, priklausomai nuo dėžučių senumo ir organizacijos dydžio. Kiekvienas per migracijos langą perkeltas el. laiškas turi tą pačią sugadintą datą, todėl problema iš karto matoma vartotojams pirmą kartą atidarant Outlook.

Siųstų laiškų aplankai dažnai būna problemiškiausi. Pardavimų vadybininkas, ieškantis pasiūlymo, išsiųsto 2022 metų kovo mėnesį, turi rusiuotis per šimtus el. laiškų, kuriuose visi rodo migracijos datą. Operacinis poveikis yra realus, ne vien kosmetinis.

Ir priešingai nei galima manyti, problema nelaikui bėgant neišnyksta. INTERNALDATE nustatoma įterpimo metu. Ji pati savaime nepasitaiso. Be aktyvaus įsikišimo el. laiškai išlaikys sugadintą datą neribotą laiką.

Kodėl tai taisyti patiems rizikingiau, nei atrodo

Pagunda suprantama: kadangi originalus Date: antraštė pranešime vis dar yra, pakanka... pataisyti metaduomenis. Teoriškai logiška. Praktiškai, 80 000 el. laiškų darbinėje dėžutėje, tai operacija, kuri gali baigtis katastrofiškai.

Štai keletas kraštutinių atvejų, kurių namų darbo skriptas greičiausiai netinkamai apdoros:

• S/MIME pasirašyti el. laiškai, kurių parašas apima visas antraštes. Bet koks pranešimo struktūros keitimas anuliuoja kriptografinį parašą.
• PGP užšifruoti pranešimai, kur turinys yra nepermatomas ir bet koks MIME vokų manipuliavimas gali sugadinti pranešimą.
• RFC 2047 koduotos ne ASCII antraštės (siuntėjų vardai su specialiais simboliais), kurios subyra, jei skriptas neteisingai tvarko kodavimą.
• Base64 koduoti priedai su neteisingai baigiamomis eilutėmis, nestandartinėmis MIME ribomis arba įdėtomis multipart struktūromis.
• El. laiškai be galiojančios Date: antraštės (tai pasitaiko, ypač senose Zoho eksportuose), kai skriptas turi nuspręsti, ką daryti.

Skriptas, veikiantis su 50 bandomųjų el. laiškų, neveiks su darbine Zoho dėžute, kurioje yra metų senumo istorija. O kaip kiekvieno pranešimo lygmeniu patikrinti, kad kiekviena pataisa yra nepažeista ir priedai nenukirpti? Patikrinimas yra bent jau toks pat sudėtingas kaip ir pati pataisa.

Yra ir kvotų klausimas. Exchange Online API per Microsoft Graph taiko griežtus normos apribojimus (garsiosios 429 Too Many Requests klaidos). Neribojamas 100 000 pranešimų paketas gali sukelti laikinus blokavimus ar tylias klaidas, kurias sunku diagnozuoti po fakto. Be gedimų atkūrimo mechanizmo, pradedama iš naujo nuo pat pradžių.

Kaip Redate.io taiso datas po Zoho migracijos

Redate.io prisijungia prie jūsų Microsoft 365 nuomotojo naudodamas standartinius Azure AD leidimus, be visuotinio administratoriaus prieigos. Pradinis nuskaitymas yra nemokamas: Redate.io identifikuoja paveiktas dėžutes ir įvertina el. laiškų su neteisingomis datomis kiekį, lygindamas INTERNALDATE su pranešimo antraščių grandinėje esančiomis reikšmėmis.

Pataisa naudoja patentuotą variklį, kuris analizuoja kiekvieno pranešimo visą antraščių grandinę, identifikuoja Zoho migracijos įrankių specifinius parašus (ar tai būtų Zoho Migration Wizard, ar imapsync, sukonfigūruotas išėjimui iš Zoho), ir rekonstruoja datos metaduomenis per kelių etapų tikrinimo konvejerį. Kiekvienas pataisytas el. laiškas tikrinamas atskirai: turinio vientisumas, priedų išsaugojimas, RFC atitiktis. Originalai saugomi atsarginės kopijos aplanke, prieinamame 30 dienų.

Jokios pakartotinės migracijos. Jokio prastovos laiko. Vartotojai toliau naudoja Outlook, kol pataisa vykdoma fone.

Kainodara pagrįsta vienkartine išmoka, priklausomai nuo apimties, be prenumeratos. Detalės prieinamos tiesiogiai svetainėje.

Susiję atvejai, kuriuos verta žinoti

Jei valdote kelias migracijas vienu metu, arba esate MSP ir administruojate klientus, išeinančius iš Zoho, atkreipkite dėmesį, kad ta pati problema kyla ir migruojant iš kitų platformų į Exchange Online. Mechanizmas identiškas: Exchange sugeneruota antraštė Received: perrašo INTERNALDATE nepriklausomai nuo šaltinio.

Migracijoms iš Google Workspace, vietinio Exchange, arba naudojant tokius įrankius kaip BitTitan MigrationWiz ar CloudM, Redate.io tinklaraščio specialūs straipsniai detaliai aprašo kiekvieno įrankio specifinius elgesinius ypatumus. Straipsnis apie neteisingas datas po migracijos į Exchange Online apžvelgia visus scenarijus, susijusius su šiuo nuomotoju.

Jei jūsų migracija apima bendrai naudojamas dėžutes ar Exchange išteklius (konferencijų salės, įranga), problema ta pati, ir tie patys taisymo įrankiai taikomi. IMAP į Exchange taisymo vadovai Redate.io svetainėje detaliai aprašo prisijungimo prie nuomotojo žingsnius.

Komandoms, naudojančioms imapsync išėjimui iš Zoho, straipsnis apie imapsync: datos neišsaugotos dokumentuoja imapsync konfigūravimo galimybes ir kodėl jų nepakanka problemai išvengti Exchange Online aplinkoje.

Jūsų Zoho migracijos datos vis dar rodomos Outlook? Nuskaitykite savo dėžutes nemokamai Redate.io ir išmatuokite tikslų problemos mastą prieš nusprendžiant, kaip veikti.