CloudM Migrate: kuidas parandada valesid kuupäevi

CloudM Migrate kuupäevaprobleem, millest keegi ei hoiata

CloudM Migrate lõpetas töö. Juhtpaneel näitab 100% valmis, kõik kasutajad migreeritud, null viga. Sulgete projektipileti ja liigute järgmise kliendi juurde.

Siis nädal hiljem helistab IT-direktor. "Miks iga e-kiri minu postkastis näitab 2. aprilli?"

Mitte mõned e-kirjad. Kõik. Viis aastat kliendikirjavahetust, õigusdokumendid, personaliandmed, 2020. aasta ostutellimused, kõik näitavad kuupäeva, mil CloudM migratsiooni käivitas. Sõnumid on olemas, sisu on puutumatu, manused on korras. Aga kuupäevad on valed absoluutselt igal ühel.

See ei ole CloudM-i viga. CloudM-i oma tugidokumentatsioon tunnistab seda avalikult. Probleem peitub migratsioonitööriistade sõnumite edastamise viisi ja sihtmeiliserverite sissetuleva e-posti metaandmete käsitlemise ristumiskohas. Aga selle teadmine ei aita teie klienti, kelle postkast on nüüd sorteerimatu.

Kuidas CloudM tegelikult e-kirju edastab

CloudM Migrate ühendub lähte- ja sihtplatvormidega nende API kaudu. Google Workspace'i puhul tähendab see teenusekontot domeeniülese delegeerimisega (konfigureeritud Google Admin Console'is jaotises Turvalisus > API juhtelemendid). Microsoft 365 puhul kasutab see Exchange Web Servicesit või Microsoft Graph API-t, sõltuvalt migratsiooniteest.

Kui CloudM loeb sõnumi allikast, saab ta täieliku RFC 2822 sisu, sealhulgas kõik originaalpäised ja sõnumi sisu. Originaalne Date: päis (see, mille saatja meiliserver pani, kui e-kiri esimest korda saadeti) tuleb kaasa puutumatuna. Samuti tulevad kaasa kõik originaalsed Received: päised, mis jälgivad sõnumi edastusteed.

Probleem tekib koopia kirjutamise hetkel. Sihtkoht säilitab kuupäeva, mis talle antakse: Microsoft 365 ja Gmail säilitavad algse kuupäeva, kui koopia selle kaasa kannab. Kui ei, saab koopia kuupäevaks sisestamise hetke. Ja Google Workspace'is saab iga Gmail API kaudu kirjutatud sõnum ka värske Received: päise, mis on dateeritud sisestamise hetkega.

Siin on, mida ühe sellise e-kirja päised endiselt kannavad pärast CloudM migratsiooni Microsoft 365-sse:

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

Originaalne Date: päis aastast 2019 on endiselt olemas, samuti originaalne Received: ahel. Aga Microsoft 365-s on kuupäev, mida Outlook näitab vastuvõetuna, postkasti oma kirje selle kohta, millal iga e-kiri saabus: kui CloudM ei edastanud algset kuupäeva, näitab see kirje 2. aprilli 2026.

CloudM-i seade "Strip Received Headers"

CloudM pakub siiski seadet selle lahendamiseks. Sihtplatvormi täpsemates seadetes, jaotises Sõnumivalikud, on lüliti "Strip Received Headers". Kui see on sisse lülitatud, eemaldab CloudM Received-päised enne sõnumi sisestamist ja asendab need ühe päisega, mis vastab e-kirja Date: päisele.

Kõlab, nagu lahendaks see kõik, eks? Mitte täpselt.

Esiteks peate sellest teadma enne migratsiooni käivitamist. Enamik administraatoreid avastab kuupäevaprobleemi pärast migratsiooni lõppu. Selleks hetkeks on sõnumid juba sihtkohas valede kuupäevadega. CloudM-i uuesti käivitamine sisse lülitatud seadega loob ainult duplikaate, see ei paranda seda, mis on juba seal.

Teiseks on sellel seadel tõsine piirang, kui sihtkoht on Google Workspace. Google'i oma dokumentatsioon kinnitab seda: Gmail kirjutab API kaudu sisestatud sõnumite Received: päised alati ümber, tembeldades need sisestamise ajatempliga. See on platvormitaseme piirang, mida CloudM ei saa ümber käia. Isegi kui "Strip Received Headers" on sisse lülitatud, lisab Google Workspace oma Received: päise migratsiooni kuupäevaga.

Microsoft 365 sihtkohtade puhul on seade vähem tähtis: Microsoft 365 säilitab kuupäeva, mis talle antakse, seega otsustab kuvatava kuupäeva üle see, kas CloudM edastab iga e-kirja algse kuupäeva.

Millised CloudM migratsioonid rikuvad kuupäevi (ja millised mitte)

Mitte iga CloudM migratsioon ei tekita valesid kuupäevi. Tulemus sõltub allika-sihtkoha kombinatsioonist ja konkreetsest API teest, mida CloudM kasutab:

• Google Workspace Microsoft 365-sse: Kuupäevad rikutakse. CloudM loeb Gmail API kaudu ja kirjutab Exchange'i, mistõttu iga e-kiri saab koopia kuupäeva.
• Microsoft 365 Google Workspace'i: Kuupäevad rikutakse. Isegi kui Strip Received Headers on sisse lülitatud, kirjutab Google'i API Received-päise ümber sisestamise kuupäevaga. CloudM-i tugidokumentatsioon nimetab seda "range platvormi piiranguks".
• Google Workspace Google Workspace'i: Kuupäevad rikutakse. Domeenivahetused, rentnike konsolideerimised, ülevõtmiste liitmised: iga Gmail API kaudu kirjutatud sõnum saab Received: päise, mis on dateeritud migratsiooni kuupäevaga.
• Kohapealne Exchange Microsoft 365-sse: Kõik sõltub kuupäevast, mille CloudM edastab, olenemata sellest, kas koopia läbib IMAP-i või EWS-i.
• Üldine IMAP allikas mis tahes sihtkohta: Sama reegel: kui CloudM ühendub allikana üldise IMAP-serveriga, näitab koopia migratsiooni kuupäeva alati, kui algset kuupäeva sihtkohale ei edastata.

Keeruline osa? CloudM-i migratsiooni juhtpaneel ei märgi sellest midagi. Edenemisriba täitub, olekuveerg näitab "Lõpetatud", üksuste arvud klapivad. CloudM-i vaatenurgast migratsioon õnnestus. Ja tehniliselt see õnnestuski. Sõnumid edastati. Kuupäevad lihtsalt ei jäänud reisi üle elama.

CloudM hallatud versus iseteenindus: sama kuupäevaprobleem

CloudM pakub kahte juurutusmudelit. SaaS-versioon (majutatud CloudM Migrate) töötab täielikult CloudM-i infrastruktuuris. Iseseisvalt majutatud versioon lubab teil juurutada esmased ja teisesed migratsiooniserverid oma võrgus, Google Cloudis, Azure'is või AWS-is.

Mõned MSP-d eeldavad, et iseseisvalt majutatud valik annab rohkem kontrolli kuupäevade käsitlemise üle, kuna te haldate migratsiooniservereid otse. Ei anna. Kuupäeva otsustab see, mida migratsioonimootor iga sõnumiga kaasa edastab, ja see mootor on sama, kus ta ka töötab. Olenemata sellest, kas teie migratsioonifarm töötab CloudM-i pilves või teie enda Azure VM-is, on tulemus kuupäevade osas sama.

CloudM pakub ka täielikult hallatud "Serviced Migration" teenust, kus nende meeskond juhib projekti algusest lõpuni. Kuupäevade osas on tulemus sama. Tehniline lahendus on identne, ainult käed klaviatuuril on erinevad. Olete kunagi maksnud preemiumteenuse eest ja saanud siiski sama piirangu, mis tasuta pakett? Just selline tunne see on.

Kehtetu Date-päise komplikatsioon

Olemas on veel üks CloudM-ile omane käitumine, mis muudab olukorra halvemaks. Kui CloudM kohtab allika e-kirja, mille Date: päis ei vasta RFC 822-le (vigane ajavöönd, puuduv nädalapäev, mittestandardne vorming), muudab ta päist, et tagada sõnumi migreerimine.

See tähendab, et mõned e-kirjad kaotavad isegi oma algse kuupäevaviite. Muudetud Date: päis ei pruugi üldse vastata tegelikule saatmiskuupäevale. CloudM-i tugidokumentatsioon mainib seda teadaoleva käitumisena jaotises "Võimalikud muudatused migreeritud üksustes", kuid ei täpsusta, milliseks muudetud kuupäev muutub.

Postkasti puhul, kus on kaheksa aasta jooksul kogunenud 12 000 sõnumit, võib teil olla sadu e-kirju kergelt mittestandardsete Date-päistega (eriti sõnumid vanematest meiliserveritest, automatiseeritud süsteemidest või rahvusvahelistelt saatjatelt, kellel on ajavööndi vormistuse iseärasusi). Pärast CloudM-i tehtud muudatust, koos koopiaga, mis algset kuupäeva kaasa ei kanna, lõpetavad need sõnumid kuupäevadega, mis ei sarnane tegelikkusele üldse.

Miks käsitsi tehtud parandused ei skaleeru pärast CloudM-i

Kas saaksite selle ise parandada? Tehniliselt on algne Date: päis endiselt kinnistatud enamikesse sõnumitesse (välja arvatud need, mida CloudM muutis RFC-le vastavuse tagamiseks). Mõned administraatorid on proovinud kirjutada skripte kuupäevade parandamiseks pärast CloudM-i migratsiooni.

Siin on see, milline see lähenemine tegelikult on. Teil tuleb ühenduda potentsiaalselt tuhandete postkastidega, igaühes tuhandete sõnumitega. Iga e-kirja jaoks tuleb analüüsida täielik päiste ahel, tuvastada, millised Received: päised lisas CloudM või sihtserver, käsitleda erijuhtumeid (S/MIME allkirjastatud sõnumid, kus päise muutmine rikub allkirja, PGP-krüpteeritud sisu, mitmeosalised MIME struktuurid pesastatud piiridega, RFC 2047 kodeeritud mitte-ASCII päised jaapani või korea saatjatelt) ja teha kõik see, kaotamata ühtki manust või rikkumata e-kirjade lõimimist.

Skript, mis töötab 50 testkirjaga puhtast postkastist, ei jää ellu kokkupuutel tootmiskeskkonnaga, kus on 40 000 sõnumit kümne aasta pealt. Mis juhtub, kui satute 47 MB e-kirja peale kuue pesastatud manusega? Mis saab API kiirusepiirangutest (Google'i 250 kvoodiühikut kasutaja kohta sekundis, Microsofti piirang umbes 10 000 päringut 10 minuti kohta)? Milline on teie tagasipööramisplaan, kui sõnumi number 8 347 juures läheb midagi valesti?

Ja tegelik küsimus, mida enamik administraatoreid ei küsi enne, kui on liiga hilja: kuidas te kontrollite, et iga parandatud sõnum on tegelikult puutumatu?

CloudM migratsiooni kuupäevade parandamine Redate.io-ga

Redate.io ühendub otse mõjutatud postkastidega (Google Workspace, Microsoft 365 või IMAP) ja skannib e-kirju, mille kuvatav kuupäev ei vasta nende algsele kuupäevale. Skannimine on tasuta ja võtab postkasti kohta paar minutit, näidates mõjutatud sõnumite täpset arvu enne igasugust kohustust.

Parandus kasutab Redate'i välja töötatud päiste ahela analüüsimootorit ja see ei pea teadma, milline tööriist migratsiooni tegi. Redate.io teostab sihitud metaandmete parandust sõnumi sisu muutmata, säilitades manused, lõimed, sildid, kaustad ja digitaalallkirjad. Iga parandatud sõnum läbib individuaalse kontrolli, kus sõnumi terviklikkust võrreldakse originaaliga enne protsessi jätkamist.

Originaalsed e-kirjad hoitakse nähtavas Redate.io - Originals varukoopiate kaustas, kuni te selle enda kustutate. Kui midagi on vaja tagasi pöörata, on originaalid otse postkastis, mitte maetud kuhugi välisesse arhiivi.

MSP-dele, kes kasutasid CloudM-i kliendikeskkondades, käsitleb Redate.io mitme postkasti parandusi suures mahus, sama sõnumipõhise kontrolliga, olenemata sellest, kas parandate 1 postkasti või 500. Kuupäevaprobleem, mille CloudM maha jättis, ei pea saama teie kliendi meilikeskkonna püsivaks osaks.

Platvormispetsiifilised juhendid CloudM migratsioonidele

Parandusprotsess kohandub sihtplatvormiga. Redate.io käsitleb iga platvormi eripärasid automaatselt, kuid teie seadistuse üksikasjade jaoks:

• Parandage CloudM migratsiooni kuupäevad Gmailis
• Parandage CloudM migratsiooni kuupäevad Outlookis
• Parandage CloudM migratsiooni kuupäevad Google Workspace'is
• Parandage CloudM migratsiooni kuupäevad Microsoft 365-s

Põhjalikuma seletuse jaoks selle kohta, miks see juhtub kõigi migratsioonitööriistadega, mitte ainult CloudM-iga, vaadake miks e-kirjad näitavad pärast migratsiooni valesid kuupäevi.

Migreerisite CloudM-iga ja jäite igal e-kirjal valede kuupäevadega? Käivitage tasuta skannimine, et näha täpselt, kui palju sõnumeid on mõjutatud ja mida nende parandamine maksab.