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 originalias antraštes ir pranešimo turinį. Originali 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 originalios Received: antraštės, kurios seka pranešimo pristatymo kelią.

Problema kyla paskirties pusėje. Kai CloudM įrašo tą pranešimą į tikslinę pašto dėžutę, paskirties serveris jį traktuoja kaip naują pristatymą. Uždeda šviežią Received: antraštę su dabartine data ir laiku bei nustato INTERNALDATE (laiko žymą, kurią IMAP naudoja rūšiavimui) į įterpimo momentą.

Štai kaip atrodo antraščių grandinė po CloudM perkėlimo į Microsoft 365:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

2019 metų antraštė yra ten. Originali Date: antraštė vis dar sako 2019 m. rugsėjo 23 d. Bet Outlook skaito naujausią Received: antraštę rodymo tvarkai nustatyti, o ta dabar 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 nustatymas teoriškai veikia geriau, bet M365 transporto konvejeris turi savo elgseną. Exchange Online vis tiek gali nustatyti INTERNALDATE pagal savo pristatymo apdorojimą, priklausomai nuo to, kaip pranešimas patenka į sistemą.

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. M365 transporto sluoksnis prideda naujas Received antraštes.
• 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 - paskirties Google nuomininkas visada uždeda perkėlimo datą ant gaunamų pranešimų.
• Vietinis Exchange į Microsoft 365: Paprastai sugenda per IMAP kelią. Jei CloudM naudoja EWS abiejose pusėse, datų išsaugojimas yra patikimesnis, bet negarantuotas.
• Bendras IMAP šaltinis į bet kokią paskirtį: Datos sugenda. Kai CloudM jungiasi prie bendro IMAP serverio kaip šaltinio, paskirties vieta vis tiek prideda savo pristatymo antraštes.

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ų problema kyla paskirties serveryje, ne CloudM apdorojimo mazguose. Nesvarbu, ar jūsų perkėlimo ūkis veikia CloudM debesyje, ar jūsų pačių Azure VM, paskirties pašto serveris vis tiek uždeda perkėlimo datą ant kiekvieno pranešimo, kurį gauna.

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 originalią datos nuorodą. 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 paskirties serverio Received antraštės perrašymo š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 originali 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, turinčius CloudM perkėlimo datos požymį. 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į, kuris identifikuoja CloudM būdingus perkėlimo modelius Received antraščių grandinėje. 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 originalą, prieš procesui judant toliau.

Originalūs el. laiškai saugomi matomame Redate.io - Originals atsarginių kopijų aplanke 30 dienų. Jei ką nors reikia grąžinti, originalai 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.