CloudM Migrate: kako popraviti napačne datume

Težava z datumi pri CloudM Migrate, na katero vas nihče ne opozori

CloudM Migrate je končal delo. Nadzorna plošča prikazuje 100 % dokončano, vsi uporabniki migrirani, nič napak. Zaprete projektni zahtevek in se lotite naslednje stranke.

Teden dni pozneje pokliče direktor IT. "Zakaj vsako e-poštno sporočilo v mojem nabiralniku prikazuje 2. april?"

Ne nekatera sporočila. Vsa. Pet let korespondence s strankami, pravni dokumenti, kadrovske evidence, naročilnice iz leta 2020, vse prikazuje datum, ko je CloudM izvedel migracijo. Sporočila so tam, vsebina je nedotaknjena, priloge so v redu. Toda datumi so napačni na vsakem posameznem sporočilu.

To ni napaka CloudM. CloudM-ova lastna dokumentacija za podporo to odkrito priznava. Težava leži na stičišču med tem, kako migracijska orodja prenašajo sporočila, in tem, kako ciljni poštni strežniki obravnavajo metapodatke dohodne e-pošte. Toda to znanje ne pomaga vaši stranki, katere nabiralnik je pravkar postal nerazvrstljiv.

Kako CloudM dejansko prenaša e-poštna sporočila

CloudM Migrate se poveže z izvorno in ciljno platformo prek njunih API-jev. Za Google Workspace to pomeni storitveni račun s pooblastilom na ravni domene (konfigurirano v Google Admin Console pod Varnost > Nadzor API-jev). Za Microsoft 365 uporablja Exchange Web Services ali Microsoft Graph API, odvisno od migracijske poti.

Ko CloudM prebere sporočilo z vira, dobi celotno vsebino RFC 2822, vključno z vsemi izvornimi glavami in telesom sporočila. Prvotna glava Date: (tista, ki jo je poštni strežnik pošiljatelja odtisnil ob prvotnem pošiljanju e-pošte) je ohranjena. Enako velja za vse prvotne glave Received:, ki sledijo dostavni poti sporočila.

Težava nastane ob zapisu kopije. Cilj ohrani datum, ki mu je posredovan: Microsoft 365 in Gmail ohranita prvotni datum, kadar ga kopija nosi. Kadar ga ne nosi, kopija dobi kot datum trenutek vstavitve. In v Google Workspace vsako sporočilo, zapisano prek Gmail API, dobi tudi novo glavo Received:, datirano s trenutkom vstavitve.

Tukaj je, kar glave enega izmed teh sporočil še vedno nosijo po CloudM migraciji v 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

Prvotna glava Date: iz leta 2019 je še tam, prav tako izvorna veriga Received:. Toda v Microsoft 365 je datum, ki ga Outlook prikaže kot datum prejema, lastni zapis nabiralnika o tem, kdaj je vsako sporočilo prispelo: če CloudM ni posredoval prvotnega datuma, ta zapis pravi 2. april 2026.

Nastavitev CloudM "Strip Received Headers"

CloudM sicer ponuja nastavitev za obravnavo te težave. V naprednih nastavitvah ciljne platforme, pod možnostmi sporočil, je stikalo "Strip Received Headers". Ko je vklopljeno, CloudM pred vstavitvijo sporočila odstrani glave Received in jih nadomesti z eno samo glavo, ki se ujema z glavo Date: e-poštnega sporočila.

Sliši se, kot da reši vse, kajne? Ne povsem.

Prvič, o tem morate vedeti, še preden zaženete migracijo. Večina skrbnikov odkrije težavo z datumi šele po končani migraciji. Takrat sporočila že ležijo na cilju z napačnimi datumi. Ponoven zagon CloudM z vklopljeno nastavitvijo samo ustvari podvojena sporočila, ne popravi tistega, kar je že tam.

Drugič, ta nastavitev ima trdno omejitev, kadar je cilj Google Workspace. Googlova lastna dokumentacija to potrjuje: Gmail vedno prepiše glave Received: na sporočilih, vstavljenih prek API-ja, in jih odtisne s časovnim žigom vstavitve. To je omejitev na ravni platforme, ki je CloudM ne more preseči. Tudi z vklopljeno nastavitvijo "Strip Received Headers" Google Workspace doda svojo glavo Received: z datumom migracije.

Za cilje Microsoft 365 je nastavitev manj pomembna: Microsoft 365 ohrani datum, ki mu je posredovan, zato o prikazanem datumu odloča le to, ali CloudM za vsako e-pošto posreduje njen prvotni datum.

Katere CloudM migracije pokvarijo datume (in katere ne)

Ne vsaka CloudM migracija povzroči napačne datume. Izid je odvisen od kombinacije vir-cilj in specifične poti API-ja, ki jo CloudM uporabi:

• Google Workspace v Microsoft 365: Datumi se pokvarijo. CloudM bere prek Gmail API in piše v Exchange, vsako sporočilo pa dobi datum kopije.
• Microsoft 365 v Google Workspace: Datumi se pokvarijo. Tudi z vklopljenim Strip Received Headers Googlov API prepiše glavo Received z datumom vstavitve. CloudM-ova dokumentacija za podporo to imenuje "stroga omejitev platforme".
• Google Workspace v Google Workspace: Datumi se pokvarijo. Menjave domen, konsolidacije najemnikov, prevzemne združitve: vsako sporočilo, zapisano prek Gmail API-ja, dobi glavo Received:, datirano z migracijo.
• Lokalni Exchange v Microsoft 365: Vse je odvisno od datuma, ki ga CloudM posreduje, ne glede na to, ali kopija poteka prek IMAP ali EWS.
• Generični vir IMAP v kateri koli cilj: Enako pravilo: ko se CloudM poveže na generični strežnik IMAP kot vir, kopija prikaže datum migracije vsakič, ko prvotni datum ni posredovan cilju.

Kaj je zapleteno? CloudM-ova nadzorna plošča za migracijo tega ne označi. Vrstica napredka se napolni, stolpec stanja pravi "Končano", števila elementov se ujemajo. S CloudM-ovega vidika je migracija uspela. In tehnično res je uspela. Sporočila so se prenesla. Datumi le niso preživeli poti.

CloudM upravljano ali samopostrežno: enaka težava z datumi

CloudM ponuja dva modela uvedbe. Različica SaaS (gostovani CloudM Migrate) teče v celoti v CloudM-ovi infrastrukturi. Samostojno gostovana različica omogoča postavitev primarnih in sekundarnih migracijskih strežnikov v lastnem omrežju, Google Cloud, Azure ali AWS.

Nekateri ponudniki upravljanih storitev domnevajo, da samostojno gostovana možnost omogoča večji nadzor nad obravnavo datumov, ker migracijske strežnike upravljate neposredno. Ni tako. O datumu odloča to, kaj migracijski mehanizem posreduje skupaj z vsakim sporočilom, ta mehanizem pa je enak, ne glede na to, kje teče. Ne glede na to, ali vaša migracijska farma teče v CloudM-ovem oblaku ali na vašem lastnem Azure VM, je izid za datume enak.

CloudM ponuja tudi popolnoma upravljano storitev "Serviced Migration", pri kateri njihova ekipa vodi projekt od začetka do konca. Enak izid za datume. Tehnika je enaka, le roke na tipkovnici so druge. Ste kdaj plačali za premijsko storitev in vseeno dobili enako omejitev kot pri brezplačni ravni? Prav to je ta občutek.

Zaplet z neveljavno glavo Date

Obstaja še eno obnašanje, značilno za CloudM, ki stvari poslabša. Ko CloudM naleti na izvorno e-pošto z glavo Date:, ki ni skladna z RFC 822 (napačen časovni pas, manjkajoč dan v tednu, nestandardna oblika), spremeni glavo, da zagotovi migracijo sporočila.

To pomeni, da nekatera sporočila izgubijo tudi svojo prvotno referenco datuma. Spremenjena glava Date: se morda sploh ne ujema z dejanskim datumom pošiljanja. CloudM-ova dokumentacija za podporo to omenja kot znano obnašanje pod "Možne spremembe migriranih elementov", ne navede pa, kakšen postane spremenjeni datum.

Pri nabiralniku z 12.000 sporočili, nabranimi v osmih letih, imate lahko na stotine e-poštnih sporočil z rahlo nestandardnimi glavami Date (zlasti sporočila s starejših poštnih strežnikov, avtomatiziranih sistemov ali mednarodnih pošiljateljev s posebnostmi v obliki časovnega pasu). Po CloudM-ovi spremembi, poleg kopije, ki ne nosi prvotnega datuma, ta sporočila končajo z datumi, ki nimajo nikakršne zveze z resničnostjo.

Zakaj ročni popravki po CloudM ne delujejo v velikem obsegu

Bi to lahko popravili sami? Tehnično je prvotna glava Date: še vedno vgrajena v večino sporočil (razen tistih, ki jih je CloudM spremenil zaradi skladnosti z RFC). Nekateri skrbniki so poskusili pisati skripte za popravljanje datumov po CloudM migraciji.

Tukaj je resničnost tega pristopa. Povezati se morate s potencialno tisoči nabiralnikov, vsak s tisoči sporočil. Za vsako e-pošto morate razčleniti celotno verigo glav, ugotoviti, katere glave Received: je dodal CloudM ali ciljni strežnik, obravnavati robne primere (sporočila, podpisana z S/MIME, kjer sprememba glav pokvari podpis, vsebina, šifrirana s PGP, večdelne strukture MIME z ugnezdenimi mejami, glave, kodirane po RFC 2047, od japonskih ali korejskih pošiljateljev z znaki zunaj ASCII) ne da bi pri tem izgubili eno samo prilogo ali pokvarili nit sporočil.

Skripta, ki deluje na 50 testnih sporočilih iz čistega nabiralnika, ne bo preživela stika s produkcijskim okoljem s 40.000 sporočili, ki pokriva desetletje. Kaj se zgodi, ko naletite na 47 MB veliko e-pošto s šestimi ugnezdenimi prilogami? Kaj z omejitvami hitrosti API-ja (Googlovih 250 kvotnih enot na uporabnika na sekundo, Microsoftovo omejevanje pri približno 10.000 zahtevkih na 10 minut)? Kakšen je vaš načrt za vrnitev, ko gre kaj narobe pri sporočilu številka 8.347?

In pravo vprašanje, ki ga večina skrbnikov ne postavi, dokler ni prepozno: kako preverite, da je vsako popravljeno sporočilo res nedotaknjeno?

Popravljanje datumov migracije CloudM z Redate.io

Redate.io se neposredno poveže s prizadetimi nabiralniki (Google Workspace, Microsoft 365 ali IMAP) in pregleda e-poštna sporočila, katerih prikazani datum ne ustreza njihovemu prvotnemu datumu. Pregled je brezplačen in traja nekaj minut na nabiralnik, prikaže pa natančno število prizadetih sporočil, še preden se odločite za kar koli.

Popravek uporablja lastniški mehanizem za analizo verige glav in ni pomembno, katero orodje je izvedlo migracijo. Redate.io izvede ciljan popravek metapodatkov brez spremembe vsebine sporočila, pri čemer ohrani priloge, niti, oznake, mape in digitalne podpise. Vsako popravljeno sporočilo gre skozi posamezno preverjanje, pri katerem se celovitost sporočila preveri glede na izvirnik, preden postopek nadaljuje.

Prvotna sporočila se hranijo v vidni rezervni mapi Redate.io - Originals, dokler jo ne izbrišete sami. Če je treba kaj vrniti, so izvirniki tam, v nabiralniku, ne zakopani v nekem zunanjem arhivu.

Za ponudnike upravljanih storitev, ki so uporabili CloudM na okoljih strank, Redate.io obravnava popravke več nabiralnikov hkrati, z enakim preverjanjem na sporočilo, ne glede na to, ali popravljate 1 nabiralnik ali 500. Težava z datumi, ki jo je CloudM pustil za seboj, ne rabi postati trajna lastnost poštnega okolja vaše stranke.

Vodniki za posamezne platforme za CloudM migracije

Postopek popravka se prilagodi ciljni platformi. Redate.io samodejno obravnava posebnosti vsake platforme, za podrobnosti o vaši nastavitvi pa:

• Popravite CloudM datume migracije v Gmailu
• Popravite CloudM datume migracije v Outlooku
• Popravite CloudM datume migracije v Google Workspace
• Popravite CloudM datume migracije v Microsoft 365

Za poglobljeno razlago, zakaj se to dogaja pri vseh migracijskih orodjih, ne le pri CloudM, glejte zakaj e-pošta po migraciji prikazuje napačne datume.

Ste migrirali s CloudM in ostali z napačnimi datumi na vsakem e-poštnem sporočilu? Zaženite brezplačen pregled, da vidite natančno, koliko sporočil je prizadetih in koliko stane njihov popravek.