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 nutinka, kai migracijos įrankis nepersiunčia kiekvieno el. laiško pradinės datos. 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 gali lemti neteisingas 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 išsaugo tą datą, kuri jam perduodama: kai įrankis su APPEND komanda perduoda kiekvieno pranešimo pradinį INTERNALDATE, kopija jį išlaiko. Kai kurie migracijos įrankiai tai daro. Kiti to nedaro, arba daro neteisingai, tokiu atveju Exchange Online priskiria įterpimo momentą, tai yra migracijos 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 pradinį INTERNALDATE įterpiant į paskirties serverį.

Tiksliau sakant: kai Zoho Migration Wizard perduoda pradinę datą, Exchange Online ją išsaugo ir Outlook rodo teisingą datą. Migracijos datą rodo tik tie el. laiškai, kurių data nebuvo perduota.

Administratoriai, naudojantys bendruosius IMAP įrankius kaip imapsync išeinant iš Zoho, gali susidurti su ta pačia problema: imapsync perkelia tokią datą, kokią kiekvienam pranešimui laiko šaltinio serveris, todėl neteisinga data šaltinyje tampa neteisinga data ir paskirties vietoje. (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ę. Pradinė 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ą neteisingą 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 neteisingą datą neribotą laiką.

Kodėl tai taisyti patiems rizikingiau, nei atrodo

Pagunda suprantama: kadangi pradinė 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ų pašto dėžutės, kai kiekvienas vartotojas prisijungia naudodamas savo Microsoft paskyrą; jei organizacija reikalauja administratoriaus patvirtinimo, Redate.io parengia nuorodą, kurią jam galite persiųsti. 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 pažangų taisymo variklį, kuris analizuoja kiekvieno pranešimo visą antraščių grandinę, nesvarbu, kuris įrankis atliko migraciją (Zoho Migration Wizard, imapsync ar bet kuris kitas) - variklis rekonstruoja datos metaduomenis per kelių etapų tikrinimo konvejerį. Kiekvienas pataisytas el. laiškas tikrinamas atskirai: turinio vientisumas, priedų išsaugojimas, RFC atitiktis. Pradiniai laiškai saugomi matomame atsarginės kopijos aplanke jūsų pašto dėžutėje, kol juos patys pašalinate.

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: kopija gauna tą datą, kurią perduoda įrankis, 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 iš kur tikrai atsiranda neteisingos datos.

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.