CloudM Migrate: kā labot nepareizus datumus

CloudM Migrate datumu problēma, par kuru neviens nebrīdina

CloudM Migrate pabeidza darbu. Vadības panelis rāda 100 % pabeigts, visi lietotāji migrēti, nulle kļūdu. Jūs aizverat projekta pieteikumu un pārejat pie nākamā klienta.

Tad nedēļu vēlāk piezvana IT direktors. "Kāpēc katrs e-pasts manā pastkastē rāda 2. aprīli?"

Ne daži e-pasti. Visi. Pieci gadi klientu sarakstes, juridiski dokumenti, HR ieraksti, pirkuma pasūtījumi no 2020. gada, viss rāda datumu, kad CloudM veica migrāciju. Ziņojumi ir tur, saturs ir neskartas, pielikumi kārtībā. Bet datumi ir nepareizi katrā vienā e-pastā.

Tā nav CloudM kļūda. CloudM paša atbalsta dokumentācija to atklāti atzīst. Problēma slēpjas krustpunktā starp to, kā migrācijas rīki pārsūta ziņojumus, un to, kā galamērķa pasta serveri apstrādā ienākošā e-pasta metadatus. Bet to zināt nepalīdz jūsu klientam, kura pastkaste tagad ir nekārtojama.

Kā CloudM patiesībā pārsūta e-pasta ziņojumus

CloudM Migrate pieslēdzas avota un galamērķa platformām caur to API. Google Workspace gadījumā tas nozīmē servisa kontu ar domēna līmeņa deleģēšanu (konfigurēts Google Admin Console sadaļā Drošība > API vadīklas). Microsoft 365 gadījumā izmanto Exchange Web Services vai Microsoft Graph API, atkarībā no migrācijas ceļa.

Kad CloudM nolasa ziņojumu no avota, tas iegūst pilnu RFC 2822 saturu, ieskaitot visas oriģinālās galvenes un ziņojuma pamattekstu. Oriģinālā Date: galvene (tā, ko sūtītāja pasta serveris uzlika, kad e-pasts tika pirmo reizi nosūtīts) nāk neskarta. Tāpat visas oriģinālās Received: galvenes, kas izseko ziņojuma piegādes ceļu.

Problēma rodas galamērķa pusē. Kad CloudM ieraksta šo ziņojumu mērķa pastkastē, galamērķa serveris to uzskata par jaunu piegādi. Tas uzliek svaigu Received: galveni ar pašreizējo datumu un laiku un iestata INTERNALDATE (laika zīmogu, ko IMAP izmanto kārtošanai) uz ievietošanas brīdi.

Lūk, kā izskatās galveņu ķēde pēc CloudM migrācijas uz 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. gada galvene ir tur. Oriģinālā Date: galvene joprojām saka 2019. gada 23. septembris. Bet Outlook lasa jaunāko Received: galveni, lai noteiktu attēlošanas secību, un tā tagad saka 2026. gada 2. aprīlis.

CloudM iestatījums "Strip Received Headers"

CloudM piedāvā iestatījumu šīs problēmas risināšanai. Galamērķa platformas papildu iestatījumos, ziņojumu opcijās, ir slēdzis "Strip Received Headers". Kad aktivizēts, CloudM noņem received galvenes pirms ziņojuma ievietošanas un aizstāj tās ar vienu galveni, kas atbilst e-pasta Date: galvenei.

Izklausās, it kā tas atrisinātu visu, vai ne? Ne gluži.

Pirmkārt, par šo iestatījumu jums jāzina pirms migrācijas palaišanas. Vairums administratoru datumu problēmu atklāj pēc migrācijas pabeigšanas. Tajā brīdī ziņojumi jau atrodas galamērķī ar nepareiziem datumiem. CloudM atkārtota palaišana ar aktivizētu iestatījumu tikai rada dublikātus, nelabo to, kas jau tur ir.

Otrkārt, šim iestatījumam ir nopietns ierobežojums, kad galamērķis ir Google Workspace. Google paša dokumentācija to apstiprina: Gmail vienmēr pārraksta Received: galvenes ziņojumos, kas ievietoti caur API, apzīmogojot tos ar ievietošanas laika zīmogu. Tas ir platformas līmeņa ierobežojums, ko CloudM nevar apiet. Pat ar aktivizētu "Strip Received Headers" Google Workspace pievieno savu Received: galveni ar migrācijas datumu.

Microsoft 365 galamērķiem iestatījums teorētiski darbojas labāk, bet M365 transporta cauruļvads rīkojas savādāk. Exchange Online joprojām var iestatīt INTERNALDATE, pamatojoties uz savu piegādes apstrādi, atkarībā no tā, kā ziņojums ienāk sistēmā.

Kuras CloudM migrācijas sabojā datumus (un kuras ne)

Ne katra CloudM migrācija rada nepareizus datumus. Rezultāts ir atkarīgs no avota-galamērķa kombinācijas un konkrētā API ceļa, ko CloudM izmanto:

• Google Workspace uz Microsoft 365: Datumi sabojājas. CloudM lasa caur Gmail API un raksta Exchange. M365 transporta slānis pievieno jaunas Received galvenes.
• Microsoft 365 uz Google Workspace: Datumi sabojājas. Pat ar Strip Received Headers Google API pārraksta Received galveni ar ievietošanas datumu. CloudM atbalsta dokumentācija to sauc par "stingru platformas ierobežojumu".
• Google Workspace uz Google Workspace: Datumi sabojājas. Domēnu maiņas, nomnieku konsolidācijas, iegādes apvienošanās - galamērķa Google nomniekam vienmēr uzliek migrācijas datumu uz ienākošajiem ziņojumiem.
• Lokālais Exchange uz Microsoft 365: Parasti sabojājas caur IMAP ceļu. Ja CloudM izmanto EWS abās pusēs, datumu saglabāšana ir uzticamāka, bet nav garantēta.
• Vispārīgs IMAP avots uz jebkuru galamērķi: Datumi sabojājas. Kad CloudM pieslēdzas vispārīgam IMAP serverim kā avotam, galamērķis joprojām pievieno savas piegādes galvenes.

Sarežģītā daļa? CloudM migrācijas vadības panelis neko no tā neatzīmē. Progresa josla piepildās, statusa kolonna saka "Pabeigts", vienību skaiti sakrīt. No CloudM perspektīvas migrācija izdevās. Un tehniski tā arī izdevās. Ziņojumi tika pārsūtīti. Tikai datumi ceļojumu nepārcieta.

CloudM pārvaldīts un pašapkalpošanās: tā pati datumu problēma

CloudM piedāvā divus izvietošanas modeļus. SaaS versija (mitinātais CloudM Migrate) darbojas pilnībā CloudM infrastruktūrā. Pašmitināšanas versija ļauj izvietot primāros un sekundāros migrācijas serverus savā tīklā, Google Cloud, Azure vai AWS.

Daži MSP pieņem, ka pašmitināšanas iespēja dod lielāku kontroli pār datumu apstrādi, jo jūs tieši pārvaldāt migrācijas serverus. Nedod. Datumu problēma rodas galamērķa serverī, nevis CloudM apstrādes mezglos. Neatkarīgi no tā, vai jūsu migrācijas ferma darbojas CloudM mākonī vai jūsu pašu Azure VM, galamērķa pasta serveris joprojām uzliek migrācijas datumu uz katru ziņojumu, ko saņem.

CloudM piedāvā arī pilnībā pārvaldītu "Serviced Migration", kur viņu komanda vada projektu no sākuma līdz beigām. Tāds pats rezultāts datumiem. Inženierija ir identiska, tikai rokas uz tastatūras ir citas.

Nederīgas Date galvenes komplikācija

Ir vēl viena CloudM specifiska uzvedība, kas situāciju pasliktina. Kad CloudM sastopas ar avota e-pastu, kura Date: galvene neatbilst RFC 822 (nepareizs laika zonas formāts, trūkstošā nedēļas diena, nestandarta formāts), tas modificē galveni, lai nodrošinātu ziņojuma migrāciju.

Tas nozīmē, ka daži e-pasti zaudē pat savu oriģinālo datuma atsauci. Modificētā Date: galvene var nemaz neatbilst reālajam nosūtīšanas datumam. CloudM atbalsta dokumentācija to piemin kā zināmu uzvedību sadaļā "Iespējamās izmaiņas migrētajos elementos", bet nenorāda, kāds kļūst modificētais datums.

Pastkastei ar 12 000 ziņojumiem, kas uzkrāti astoņu gadu laikā, var būt simtiem e-pastu ar nedaudz nestandarta Date galvenēm (īpaši ziņojumi no vecākiem pasta serveriem, automatizētām sistēmām vai starptautiskiem sūtītājiem ar laika zonas formatēšanas atšķirībām). Pēc CloudM modifikācijas un galamērķa servera Received galvenes pārrakstīšanas šie ziņojumi beidzas ar datumiem, kam nav nekāda sakara ar realitāti.

Kāpēc manuāli labojumi pēc CloudM nedarbojas lielā apjomā

Vai jūs to varētu salabot paši? Tehniski oriģinālā Date: galvene joprojām ir iestrādāta vairumā ziņojumu (izņemot tos, ko CloudM modificēja RFC atbilstībai). Daži administratori ir mēģinājuši rakstīt skriptus datumu labošanai pēc CloudM migrācijas.

Šīs pieejas realitāte ir šāda. Jums jāpieslēdzas potenciāli tūkstošiem pastkasšu, katrā tūkstošiem ziņojumu. Katram e-pastam jāanalizē pilna galveņu ķēde, jāidentificē, kuras Received: galvenes pievienoja CloudM vai galamērķa serveris, jāapstrādā robežgadījumi (S/MIME parakstīti ziņojumi, kur galvenes modifikācija sabojā parakstu, PGP šifrēts saturs, daudzkomponentu MIME struktūras ar ligzdotām robežām, RFC 2047 kodētas ne-ASCII galvenes no japāņu vai korejiešu sūtītājiem), un tas viss nezaudējot nevienu pielikumu vai nesabojājot e-pasta pavedienu.

Skripts, kas darbojas ar 50 testa e-pastiem no tīras pastkastes, neizturēs kontaktu ar ražošanas vidi ar 40 000 ziņojumiem, kas aptver desmitgadi. Kas notiek, kad uzejat uz 47 MB e-pastu ar sešiem ligzdotiem pielikumiem? Kā ar API ātruma ierobežojumiem (Google 250 kvotu vienības uz lietotāju sekundē, Microsoft ierobežošana ap 10 000 pieprasījumiem 10 minūtēs)? Kāds ir jūsu atgriešanās plāns, kad kaut kas noiet greizi pie ziņojuma numur 8 347?

Un īstais jautājums, ko vairums administratoru neuzdod, kamēr nav par vēlu: kā jūs pārbaudāt, ka katrs labotais ziņojums patiešām ir neskartas?

CloudM migrācijas datumu labošana ar Redate.io

Redate.io tieši pieslēdzas ietekmētajām pastkastēm (Google Workspace, Microsoft 365 vai IMAP) un skenē e-pastus, kas nes CloudM migrācijas datuma parakstu. Skenēšana ir bezmaksas un aizņem pāris minūtes uz pastkasti, parādot precīzu ietekmēto ziņojumu skaitu pirms jebkādas saistības.

Korekcija izmanto patentētu galveņu ķēdes analīzes dzinēju, kas identificē CloudM specifiskos migrācijas modeļus Received galveņu ķēdē. Redate.io veic mērķtiecīgu metadatu korekciju, nemainot ziņojuma saturu, saglabājot pielikumus, pavedienus, etiķetes, mapes un digitālos parakstus. Katrs labotais ziņojums iziet individuālu verifikāciju, pārbaudot ziņojuma integritāti pret oriģinālu, pirms process turpinās.

Oriģinālie e-pasti tiek glabāti redzamā Redate.io - Originals rezerves mapē 30 dienas. Ja kaut kas jāatgriež, oriģināli ir tur pat pastkastē, nevis aprakti kādā ārējā arhīvā.

MSP, kas izmantoja CloudM klientu vidēs, Redate.io apstrādā vairāku pastkasšu korekcijas vienlaicīgi, ar tādu pašu verifikāciju katram ziņojumam neatkarīgi no tā, vai labojat 1 pastkasti vai 500. Datumu problēmai, ko CloudM atstāja, nav jākļūst par jūsu klienta pasta vides pastāvīgu īpašību.

Platformai specifiski ceļveži CloudM migrācijām

Korekcijas process pielāgojas galamērķa platformai. Redate.io automātiski apstrādā katras platformas specifiku, bet detaļām par jūsu iestatījumu:

• Labojiet CloudM migrācijas datumus Gmail
• Labojiet CloudM migrācijas datumus Outlook
• Labojiet CloudM migrācijas datumus Google Workspace
• Labojiet CloudM migrācijas datumus Microsoft 365

Padziļinātam skaidrojumam, kāpēc tas notiek visos migrācijas rīkos, ne tikai CloudM, skatiet kāpēc e-pasti pēc migrācijas rāda nepareizus datumus.

Migrējāt ar CloudM un palikāt ar nepareiziem datumiem katrā e-pastā? Sāciet bezmaksas skenēšanu, lai redzētu precīzi, cik ziņojumi ir ietekmēti un cik maksā to labošana.