CloudM Migrate: kaip pataisyti neteisingus datus

CloudM Migrate datų problema, apie kurią niekas neįspėja

CloudM Migrate baigė darbą. Valdymo skydas rodo 100 % atlikta, visi naudotojai perkelti, nulis klaidų. Uždarote projekto užduotį ir pereinate prie kito kliento.

Tada po savaitės paskambina IT direktorius. "Kodėl kiekvienas el. laiškas mano pašto dėžutėje rodo balandžio 2-ąją?"

Ne kai kurie el. laiškai. Visi. Penkeri metai klientų korespondencijos, teisiniai dokumentai, HR įrašai, pirkimo užsakymai nuo 2020 metų, viskas rodo datą, kada CloudM atliko perkėlimą. Žinutės yra ten, turinys nepalietas, priedai tvarkingi. Bet datos neteisingos kiekviename paskutiniame laiške.

Tai ne CloudM klaida. Paties CloudM palaikymo dokumentacija tai atvirai pripažįsta. Problema slypi ten, kur susikerta perkėlimo įrankių pranešimų perdavimo būdas ir paskirties pašto serverių gaunamų el. laiškų metaduomenų apdorojimo būdas. Bet žinojimas to nepadeda jūsų klientui, kurio pašto dėžutė dabar tapo nerūšiuojama.

Kaip CloudM iš tikrųjų perkelia el. pašto pranešimus

CloudM Migrate jungiasi prie šaltinio ir paskirties platformų per jų API. Google Workspace atveju tai reiškia paslaugų paskyrą su domeno lygio delegavimu (konfigūruojama Google Admin Console skiltyje Saugumas > API valdikliai). Microsoft 365 atveju naudoja Exchange Web Services arba Microsoft Graph API, priklausomai nuo perkėlimo kelio.

Kai CloudM nuskaito pranešimą iš šaltinio, gauna visą RFC 2822 turinį, įskaitant visas pradines antraštes ir pranešimo turinį. Pradinė Date: antraštė (ta, kurią siuntėjo pašto serveris uždėjo, kai el. laiškas buvo pirmą kartą išsiųstas) ateina nepaliesta. Taip pat visos pradinės Received: antraštės, kurios seka pranešimo pristatymo kelią.

Problema kyla tada, kai kopija įrašoma. Paskirtis išsaugo tą datą, kurią jai perduoda: Microsoft 365 ir Gmail išsaugo pradinę datą, kai kopija ją perduoda. Kai ne, kopija gauna įterpimo momentą kaip savo datą. O Google Workspace aplinkoje kiekvienas per Gmail API įrašytas pranešimas taip pat gauna šviežią Received: antraštę, datuotą įterpimo momentu.

Štai kokias antraštes vienas iš tų el. laiškų vis dar turi po CloudM perkėlimo į Microsoft 365:

Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

Pradinė Date: antraštė iš 2019 m. vis dar yra, kaip ir pradinė Received: grandinė. Bet Microsoft 365 aplinkoje Outlook rodoma gavimo data yra pačios pašto dėžutės įrašas apie tai, kada el. laiškas atkeliavo: jei CloudM neperdavė pradinės datos, tas įrašas sako 2026 m. balandžio 2 d.

CloudM nustatymas "Strip Received Headers"

CloudM siūlo nustatymą šiai problemai spręsti. Paskirties platformos išplėstiniuose nustatymuose, pranešimų parinktyse, yra jungiklis "Strip Received Headers". Kai aktyvuotas, CloudM pašalina received antraštes prieš įterpiant pranešimą ir pakeičia jas viena antrašte, atitinkančia el. laiško Date: antraštę.

Skamba taip, lyg tai išspręstų viską, tiesa? Ne visai.

Pirma, apie šį nustatymą turite žinoti prieš paleisdami perkėlimą. Dauguma administratorių datos problemą atranda po perkėlimo pabaigos. Tuo metu pranešimai jau sėdi paskirtyje su neteisingais datumais. Pakartotinis CloudM paleidimas su aktyvuotu nustatymu tik sukuria dublikatus, netaiso to, kas jau ten yra.

Antra, šis nustatymas turi rimtą apribojimą, kai paskirties vieta yra Google Workspace. Paties Google dokumentacija tai patvirtina: Gmail visada perrašo Received: antraštes pranešimuose, įterptuose per API, žymėdamas jas įterpimo laiko žyma. Tai platformos lygio apribojimas, kurio CloudM negali apeiti. Net su aktyvuotu "Strip Received Headers", Google Workspace prideda savo Received: antraštę su perkėlimo data.

Microsoft 365 paskirčių atveju šis nustatymas turi mažiau reikšmės: Microsoft 365 išsaugo tą datą, kuri jai perduodama, todėl rodomą datą lemia tai, ar CloudM perduoda kiekvieno el. laiško pradinę datą.

Kurie CloudM perkėlimai sugadina datas (o kurie ne)

Ne kiekvienas CloudM perkėlimas sukelia neteisingus datus. Rezultatas priklauso nuo šaltinio-paskirties kombinacijos ir konkrečios API kelio, kurį CloudM naudoja:

• Google Workspace į Microsoft 365: Datos sugenda. CloudM skaito per Gmail API ir rašo į Exchange, ir kiekvienas el. laiškas gauna kopijos datą.
• Microsoft 365 į Google Workspace: Datos sugenda. Net su Strip Received Headers Google API perrašo Received antraštę įterpimo data. CloudM palaikymo dokumentacija tai vadina "griežtu platformos apribojimu".
• Google Workspace į Google Workspace: Datos sugenda. Domenų pakeitimai, nuomininkų konsolidacijos, įsigijimų susijungimai - kiekvienas per Gmail API įrašytas pranešimas gauna Received: antraštę, datuotą perkėlimo momentu.
• Vietinis Exchange į Microsoft 365: Viskas priklauso nuo datos, kurią perduoda CloudM, nesvarbu, ar kopija eina per IMAP, ar per EWS.
• Bendras IMAP šaltinis į bet kokią paskirtį: Ta pati taisyklė: kai CloudM jungiasi prie bendro IMAP serverio kaip šaltinio, kopija rodo perkėlimo datą, jei pradinė data nėra perduota paskirties vietai.

Sudėtinga dalis? CloudM perkėlimo valdymo skydas nieko iš to nežymi. Progreso juosta prisipildo, būsenos stulpelis sako "Baigta", elementų skaičiai sutampa. Iš CloudM perspektyvos perkėlimas pavyko. Ir techniškai pavyko. Pranešimai buvo perkelti. Tik datos neišgyveno kelionės.

CloudM valdomas ir savitarnos: ta pati datų problema

CloudM siūlo du diegimo modelius. SaaS versija (talpinamas CloudM Migrate) veikia visiškai CloudM infrastruktūroje. Savitalpinimo versija leidžia diegti pirminius ir antrinius perkėlimo serverius savo tinkle, Google Cloud, Azure ar AWS.

Kai kurie MSP mano, kad savitalpinimo variantas suteikia daugiau kontrolės datų apdorojimui, nes tiesiogiai valdote perkėlimo serverius. Nesuteikia. Datą lemia tai, ką perkėlimo variklis perduoda su kiekvienu pranešimu, o tas variklis yra tas pats, kur jis veiktų. Nesvarbu, ar jūsų perkėlimo ūkis veikia CloudM debesyje, ar jūsų pačių Azure VM, rezultatas datoms yra tas pats.

CloudM taip pat siūlo pilnai valdomą "Serviced Migration", kur jų komanda veda projektą nuo pradžios iki galo. Tas pats rezultatas datoms. Inžinerija identiška, tik rankos ant klaviatūros kitos.

Negaliojančios Date antraštės komplikacija

Yra dar viena CloudM būdinga elgsena, kuri pablogina situaciją. Kai CloudM aptinka šaltinio el. laišką su Date: antrašte, neatitinkančia RFC 822 (neteisingas laiko zonos formatas, trūksta savaitės dienos, nestandartinis formatas), modifikuoja antraštę, kad užtikrintų pranešimo perkėlimą.

Tai reiškia, kad kai kurie el. laiškai praranda net savo nuorodą į pradinę datą. Modifikuota Date: antraštė gali visai neatitikti tikrosios siuntimo datos. CloudM palaikymo dokumentacija tai mini kaip žinomą elgseną skiltyje "Galimi migruotų elementų pakeitimai", bet nenurodo, kokia tampa modifikuota data.

Pašto dėžutėje su 12 000 pranešimų, sukauktų per aštuonerius metus, galite turėti šimtus el. laiškų su šiek tiek nestandartinėmis Date antraštėmis (ypač pranešimai iš senesnių pašto serverių, automatizuotų sistemų ar tarptautinių siuntėjų su laiko zonos formatavimo skirtumais). Po CloudM modifikacijos ir kopijos, kuri neperduoda pradinės datos, šie pranešimai baigiasi su datomis, neturinčiomis jokio ryšio su tikrove.

Kodėl rankiniai taisymai po CloudM neveikia dideliu mastu

Ar galėtumėte tai ištaisyti patys? Techniškai pradinė Date: antraštė vis dar yra įterpta daugumoje pranešimų (išskyrus tuos, kuriuos CloudM modifikavo dėl RFC atitikties). Kai kurie administratoriai bandė rašyti scenarijus datoms taisyti po CloudM perkėlimo.

Šio požiūrio realybė tokia. Jums reikia prisijungti prie potencialiai tūkstančių pašto dėžučių, kiekvienoje tūkstančiai pranešimų. Kiekvienam el. laiškui turite išanalizuoti visą antraščių grandinę, nustatyti, kurias Received: antraštes pridėjo CloudM ar paskirties serveris, apdoroti kraštutinius atvejus (S/MIME pasirašytus pranešimus, kur antraštės modifikavimas sugadina parašą, PGP užšifruotą turinį, daugiadalykines MIME struktūras su įdėtinėmis ribomis, RFC 2047 koduotas ne-ASCII antraštes nuo japoniškų ar korėjietiškų siuntėjų), ir visa tai neprarandant nė vieno priedo ar nesugadinant el. pašto gijos.

Scenarijus, kuris veikia su 50 bandomųjų el. laiškų iš švarios pašto dėžutės, neišgyvens kontakto su gamybine aplinka, turinčia 40 000 pranešimų per dešimtmetį. Kas nutiks, kai susidursite su 47 MB el. laišku su šešiais įdėtiniais priedais? O API greičio apribojimai (Google 250 kvotos vienetų vienam naudotojui per sekundę, Microsoft ribojimas ties maždaug 10 000 užklausų per 10 minučių)? Koks jūsų atsarginių kopijų planas, kai kas nors nepavyks ties pranešimu numeris 8 347?

Ir tikrasis klausimas, kurio dauguma administratorių neužduoda, kol ne per vėlu: kaip patikrinsite, kad kiekvienas ištaisytas pranešimas iš tikrųjų yra nepažeistas?

CloudM perkėlimo datų taisymas su Redate.io

Redate.io tiesiogiai jungiasi prie paveiktų pašto dėžučių (Google Workspace, Microsoft 365 ar IMAP) ir nuskaito el. laiškus, kurių rodoma data neatitinka pradinės datos. Nuskaitymas yra nemokamas ir trunka porą minučių vienai dėžutei, parodydamas tikslų paveiktų pranešimų skaičių prieš bet kokį įsipareigojimą.

Korekcija naudoja nuosavą antraščių grandinės analizės variklį, ir jam nereikia žinoti, kokiu įrankiu buvo atliktas perkėlimas. Redate.io atlieka tikslinę metaduomenų korekciją nekeisdamas pranešimo turinio, išsaugodamas priedus, gijas, žymes, aplankus ir skaitmeninius parašus. Kiekvienas ištaisytas pranešimas praeina individualią patikrą, tikrinant pranešimo vientisumą pagal pradinę versiją, prieš procesui judant toliau.

Pradiniai el. laiškai saugomi matomame Redate.io - Originals atsarginių kopijų aplanke, kol juos patys pašalinsite. Jei ką nors reikia grąžinti, pradiniai laiškai yra ten pat pašto dėžutėje, nepalaidoti kokiame nors išoriniame archyve.

MSP, naudojusiems CloudM klientų aplinkose, Redate.io tvarko kelių pašto dėžučių korekcijas vienu metu, su ta pačia patikra kiekvienam pranešimui, nesvarbu, ar taisote 1 dėžutę, ar 500. Datų problema, kurią CloudM paliko, nebūtinai turi tapti nuolatine jūsų kliento pašto aplinkos savybe.

Konkrečių platformų vadovai CloudM perkėlimams

Korekcijos procesas prisitaiko prie paskirties platformos. Redate.io automatiškai tvarko kiekvienos platformos specifiką, bet dėl detalių apie jūsų konfigūraciją:

• Pataisykite CloudM perkėlimo datas Gmail
• Pataisykite CloudM perkėlimo datas Outlook
• Pataisykite CloudM perkėlimo datas Google Workspace
• Pataisykite CloudM perkėlimo datas Microsoft 365

Išsamesniam paaiškinimui, kodėl tai vyksta visuose perkėlimo įrankiuose, ne tik CloudM, žiūrėkite kodėl el. laiškai po perkėlimo rodo neteisingus datus.

Perkėlėte su CloudM ir likote su neteisingais datumais kiekviename el. laiške? Paleiskite nemokamą nuskaitymą, kad pamatytumėte tiksliai, kiek pranešimų paveikta ir kiek kainuoja juos ištaisyti.