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 projektno zahtevko in se lotite naslednje stranke.

Teden dni pozneje pokliče IT direktor. "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, HR 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 v CloudM-u. CloudM-ova lastna dokumentacija za podporo to odkrito priznava. Težava leži na stičišču načina, kako migracijska orodja prenašajo sporočila, in načina, kako ciljni poštni strežniki obdelujejo metapodatke dohodne e-pošte. Toda vedeti to ne pomaga vaši stranki, katere nabiralnik je zdaj nerazvrsten.

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 iz vira, dobi celotno vsebino RFC 2822, vključno z vsemi izvornimi glavami in telesom sporočila. Izvorna glava Date: (tista, ki jo je poštni strežnik pošiljatelja odtisnil ob prvem pošiljanju e-pošte) pride nedotaknjena. Prav tako vse izvorne glave Received:, ki sledijo dostavni poti sporočila.

Težava nastane na ciljni strani. Ko CloudM zapiše to sporočilo v ciljni nabiralnik, ga ciljni strežnik obravnava kot novo dostavo. Odtisne svežo glavo Received: s trenutnim datumom in časom ter nastavi INTERNALDATE (časovni žig, ki ga IMAP uporablja za razvrščanje) na trenutek vstavljanja.

Takole izgleda veriga glav po CloudM migraciji v 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

Glava iz leta 2019 je tam. Izvorna glava Date: še vedno pravi 23. september 2019. Toda Outlook bere najnovejšo glavo Received: za določitev vrstnega reda prikaza, ta pa zdaj pravi 2. april 2026.

Nastavitev "Strip Received Headers" v CloudM

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

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

Prvič, o tej nastavitvi morate vedeti pred zagonom migracije. Večina skrbnikov odkrije težavo z datumi po končani migraciji. Takrat sporočila že ležijo na cilju z napačnimi datumi. Ponoven zagon CloudM z aktivirano nastavitvijo samo ustvari dvojnike, ne popravi tistega, kar je že tam.

Drugič, ta nastavitev ima resno omejitev, ko 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 vstavljanja. To je omejitev na ravni platforme, ki je CloudM ne more zaobiti. Tudi z aktiviranim "Strip Received Headers" Google Workspace doda lastno glavo Received: z datumom migracije.

Za cilje Microsoft 365 nastavitev v teoriji deluje bolje, toda transportni cevovod M365 ima lastno obnašanje. Exchange Online lahko še vedno nastavi INTERNALDATE na podlagi lastne obdelave dostave, odvisno od tega, kako sporočilo vstopi v sistem.

Katere CloudM migracije pokvarijo datume (in katere ne)

Vsaka CloudM migracija ne povzroči napačnih datumov. Izid je odvisen od kombinacije vir-cilj in specifične API poti, ki jo CloudM uporablja:

• Google Workspace v Microsoft 365: Datumi se pokvarijo. CloudM bere prek Gmail API in piše v Exchange. Transportna plast M365 doda nove glave Received.
• Microsoft 365 v Google Workspace: Datumi se pokvarijo. Tudi s Strip Received Headers Googlov API prepiše glavo Received z datumom vstavljanja. 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 - ciljni Google najemnik vedno odtisne datum migracije na dohodna sporočila.
• Lokalni Exchange v Microsoft 365: Ponavadi se pokvari prek IMAP poti. Če CloudM uporablja EWS na obeh straneh, je ohranjanje datumov zanesljivejše, toda ni zagotovljeno.
• Generični IMAP vir v kateri koli cilj: Datumi se pokvarijo. Ko se CloudM poveže na generični IMAP strežnik kot vir, cilj še vedno doda lastne dostavne glave.

Zapleteni del? CloudM-ova nadzorna plošča za migracijo ničesar od tega ne označi. Vrstica napredka se napolni, stolpec stanja pravi "Končano", števila elementov se ujemajo. Z vidika CloudM je migracija uspela. In tehnično res je. Sporočila so bila prenesena. Samo datumi niso preživeli poti.

CloudM upravljani in samopostrežni: enaka težava z datumi

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

Nekateri MSP-ji predpostavljajo, da samogostovana možnost daje večji nadzor nad obdelavo datumov, ker neposredno upravljate migracijske strežnike. Ne daje. Težava z datumi nastane na ciljnem strežniku, ne na CloudM-ovih vozliščih za obdelavo. Naj vaša migracijska farma teče v CloudM-ovem oblaku ali na vašem lastnem Azure VM, ciljni poštni strežnik še vedno odtisne datum migracije na vsako sporočilo, ki ga prejme.

CloudM ponuja tudi popolnoma upravljano "Serviced Migration", kjer njihova ekipa vodi projekt od začetka do konca. Enak izid za datume. Inženiring je enak, le roke na tipkovnici so druge.

Zaplet z neveljavno glavo Date

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

To pomeni, da nekatera sporočila izgubijo celo svojo izvorno 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 navaja pa, kakšen postane spremenjeni datum.

Za nabiralnik z 12.000 sporočili, nabranimi v osmih letih, imate morda na stotine e-pošt z rahlo nestandardnimi glavami Date (zlasti sporočila s starejših poštnih strežnikov, avtomatiziranih sistemov ali mednarodnih pošiljateljev z razlikami v oblikovanju časovnih pasov). Po CloudM-ovi spremembi in prepisu glave Received s strani ciljnega strežnika ta sporočila končajo z datumi, ki nimajo nobene zveze z resničnostjo.

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

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

Realnost tega pristopa je naslednja. Povezati se morate s potencialno tisočimi nabiralniki, vsak s tisočimi sporočili. Za vsako e-pošto morate razčleniti celotno verigo glav, prepoznati, katere glave Received: je dodal CloudM ali ciljni strežnik, obravnavati robne primere (S/MIME podpisana sporočila, kjer sprememba glav pokvari podpis, PGP šifrirana vsebina, večdelne MIME strukture z ugnezdenimi mejami, RFC 2047 kodirane ne-ASCII glave od japonskih ali korejskih pošiljateljev) in vse to brez izgube ene same priloge ali kvarjenja niti e-pošte.

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 pokrivajo desetletje. Kaj se zgodi, ko naletite na 47 MB e-pošto s šestimi ugnezdenimi prilogami? Kaj z API omejitvami hitrosti (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 resnično nedotaknjeno?

Popravljanje datumov CloudM migracije z Redate.io

Redate.io se neposredno poveže s prizadetimi nabiralniki (Google Workspace, Microsoft 365 ali IMAP) in pregleda e-pošto, ki nosi CloudM-ov podpis datuma migracije. Pregled je brezplačen in traja par minut na nabiralnik ter prikaže natančno število prizadetih sporočil pred kakršno koli obveznostjo.

Popravek uporablja lastniški motor za analizo verige glav, ki prepoznava CloudM-specifične migracijske vzorce v verigi glav Received. Redate.io izvaja ciljano popravilo metapodatkov brez spreminjanja vsebine sporočila, pri čemer ohranja priloge, niti, oznake, mape in digitalne podpise. Vsako popravljeno sporočilo gre skozi posamezno preverjanje, kjer se preverja celovitost sporočila v primerjavi z izvirnikom, preden postopek nadaljuje.

Izvorna sporočila se hranijo v vidni rezervni mapi Redate.io - Originals 30 dni. Če je treba kaj vrniti, so izvirniki tam v nabiralniku, ne zakopani v nekem zunanjem arhivu.

Za MSP-je, ki so uporabili CloudM v 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, ni nujno 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 vsaki e-pošti? Zaženite brezplačen pregled, da vidite natančno, koliko sporočil je prizadetih in koliko stane popravilo.