CloudM Migrate: kako ispraviti datume e-poruka

Problem s datumima CloudM Migrate na koji Vas nitko ne upozorava

CloudM Migrate je završio posao. Nadzorna ploča pokazuje 100% dovršenost, svi korisnici migrirani, nula pogrešaka. Zatvarate projektni tiket i prelazite na sljedećeg klijenta.

Tjedan dana kasnije zove IT direktor. "Zašto svaki e-mail u mom sandučiću pokazuje 2. travnja?"

Ne neki e-mailovi. Svi. Pet godina prepiske s klijentima, pravni dokumenti, HR evidencija, narudžbe iz 2020., sve pokazuje datum kada je CloudM pokrenuo migraciju. Poruke su tu, sadržaj netaknut, privitci u redu. Ali datumi su krivi na svakom jednom.

Ovo nije CloudM bug. CloudM-ova dokumentacija za podršku otvoreno to priznaje. Problem leži na sjecištu načina na koji migracijski alati prenose poruke i načina na koji odredišni mail serveri obrađuju metapodatke dolazne pošte. Ali to znanje ne pomaže Vašem klijentu čiji je sandučić postao nesortirajući.

Kako CloudM zapravo prenosi e-mail poruke

CloudM Migrate se povezuje s izvornom i odredišnom platformom putem njihovih API-ja. Za Google Workspace to znači servisni račun s delegacijom na razini domene (konfiguriran u Google Admin Console pod Security > API Controls). Za Microsoft 365 koristi Exchange Web Services ili Microsoft Graph API, ovisno o putu migracije.

Kada CloudM pročita poruku iz izvora, dobiva potpuni RFC 2822 sadržaj, uključujući sva izvorna zaglavlja i tijelo poruke. Izvorno Date: zaglavlje (ono koje je pošiljateljev mail server stavio kada je e-mail prvi put poslan) dolazi netaknuto. Također i sva izvorna Received: zaglavlja koja prate put isporuke poruke.

Problem nastaje u trenutku kada se kopija zapisuje. Odredište čuva datum koji dobije: Microsoft 365 i Gmail čuvaju izvorni datum kada ga kopija nosi. Kada ga ne nosi, kopija dobiva trenutak umetanja kao svoj datum. A na Google Workspaceu svaka poruka zapisana putem Gmail API-ja dobiva i svježe Received: zaglavlje datirano trenutkom umetanja.

Ovako izgledaju zaglavlja jedne od tih e-poruka nakon CloudM migracije u 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

Izvorno Date: zaglavlje iz 2019. i dalje je tu, kao i izvorni lanac Received: zaglavlja. Ali u Microsoft 365, datum koji Outlook prikazuje kao datum primitka je vlastiti zapis sandučića o trenutku kada je e-poruka stigla: ako CloudM nije prenio izvorni datum, taj zapis kaže 2. travnja 2026.

CloudM-ova postavka "Strip Received Headers"

CloudM nudi postavku za rješavanje ovog problema. U Advanced Settings odredišne platforme, pod Message Options, postoji prekidač "Strip Received Headers". Kada je uključen, CloudM uklanja received zaglavlja prije umetanja poruke i zamjenjuje ih jednim zaglavljem koje odgovara Date: zaglavlju e-maila.

Zvuči kao da rješava sve, zar ne? Ne baš.

Prvo, morate znati za nju prije pokretanja migracije. Većina administratora otkriva problem s datumima nakon završetka migracije. U tom trenutku poruke već sjede u odredištu s krivim datumima. Ponovno pokretanje CloudM-a s uključenom postavkom samo stvara duplikate, ne ispravlja postojeće.

Drugo, ova postavka ima ozbiljno ograničenje kada je odredište Google Workspace. Googleova dokumentacija to potvrđuje: Gmail uvijek prepisuje Received: zaglavlja na porukama umetnutim putem API-ja, označavajući ih vremenskom oznakom umetanja. To je ograničenje na razini platforme koje CloudM ne može zaobići. Čak i s uključenim "Strip Received Headers" Google Workspace dodaje vlastito Received: zaglavlje s datumom migracije.

Za odredišta Microsoft 365 ta postavka manje utječe: Microsoft 365 čuva datum koji dobije, tako da o prikazanom datumu odlučuje samo to prenosi li CloudM izvorni datum svake e-poruke.

Koje CloudM migracije kvare datume (a koje ne)

Ne stvara svaka CloudM migracija krive datume. Rezultat ovisi o kombinaciji izvor-odredište i specifičnom API putu koji CloudM koristi:

• Google Workspace u Microsoft 365: Datumi se kvare. CloudM čita putem Gmail API-ja i piše u Exchange, a svaka e-poruka dobiva datum kopije.
• Microsoft 365 u Google Workspace: Datumi se kvare. Čak i sa Strip Received Headers, Googleov API prepisuje Received zaglavlje datumom umetanja. CloudM-ova dokumentacija za podršku to naziva "strogim ograničenjem platforme".
• Google Workspace u Google Workspace: Datumi se kvare. Promjene domena, konsolidacije stanara, spajanja nakon preuzimanja: svaka poruka zapisana putem Gmail API-ja dobiva Received: zaglavlje datirano migracijom.
• Lokalni Exchange u Microsoft 365: Sve ovisi o datumu koji CloudM prenosi, bilo da kopija ide putem IMAP-a ili EWS-a.
• Općeniti IMAP izvor u bilo koje odredište: Isto pravilo: kada se CloudM poveže na općeniti IMAP server kao izvor, kopija pokazuje datum migracije kad se izvorni datum ne prenese odredištu.

Teški dio? CloudM-ova nadzorna ploča migracije ne označava ništa od toga. Traka napretka se puni, stupac statusa kaže "Completed", brojevi stavki se podudaraju. Iz perspektive CloudM-a migracija je uspjela. Tehnički jest. Poruke su prenesene. Datumi jednostavno nisu preživjeli put.

CloudM Managed i Self-Service: isti problem s datumima

CloudM nudi dva modela implementacije. SaaS verzija (hostana CloudM Migrate) radi u potpunosti u CloudM-ovoj infrastrukturi. Self-hosted verzija omogućuje postavljanje primarnog i sekundarnog migracijskog servera u vlastitoj mreži, Google Cloud-u, Azure-u ili AWS-u.

Neki MSP-ovi pretpostavljaju da self-hosted opcija daje veću kontrolu nad rukovanjem datumima jer izravno upravljate migracijskim serverima. Ne daje. O datumu odlučuje ono što migracijski mehanizam prenosi uz svaku poruku, a taj mehanizam je isti bez obzira gdje se izvodi. Bez obzira radi li Vaša migracijska farma u CloudM-ovom oblaku ili na vlastitom Azure VM-u, rezultat za datume je isti.

CloudM također nudi potpuno upravljanu "Serviced Migration" gdje njihov tim vodi projekt od početka do kraja. Isti rezultat za datume. Inženjering je identičan, samo su ruke na tipkovnici druge.

Komplikacija s nevaljanim Date zaglavljem

Postoji još jedno ponašanje specifično za CloudM koje pogoršava stvar. Kada CloudM naiđe na izvorni e-mail s Date: zaglavljem koje ne zadovoljava RFC 822 (neispravan format vremenske zone, nedostaje dan u tjednu, nestandardni format), modificira zaglavlje kako bi osigurao mogućnost migriranja poruke.

To znači da neki e-mailovi gube čak i izvornu referencu datuma. Modificirano Date: zaglavlje možda uopće ne odgovara stvarnom datumu slanja.

Za sandučić s 12.000 poruka prikupljenih kroz osam godina, može postojati stotine e-mailova s blago nestandardnim Date zaglavljima. Nakon CloudM-ove modifikacije, plus kopije koja ne nosi izvorni datum, te poruke završavaju s datumima koji nemaju nikakve veze sa stvarnošću.

Zašto ručni ispravci ne skaliraju nakon CloudM-a

Možete li to ispraviti sami? Tehnički, izvorno Date: zaglavlje je i dalje ugrađeno u većinu poruka (osim onih koje je CloudM modificirao radi RFC usklađenosti). Neki administratori pokušali su pisati skripte za ispravljanje datuma nakon CloudM migracije.

Stvarnost tog pristupa: trebate se povezati s potencijalno tisućama sandučića, svaki s tisućama poruka. Za svaki e-mail trebate raščlaniti potpuni lanac zaglavlja, identificirati koja su Received: zaglavlja dodali CloudM ili odredišni server, obraditi rubne slučajeve (S/MIME potpisane poruke gdje modifikacija zaglavlja lomi potpis, PGP kriptirani sadržaj, višedijelne MIME strukture s ugniježđenim granicama, RFC 2047 kodirana ne-ASCII zaglavlja od japanskih ili korejskih pošiljatelja), i sve to bez gubitka jednog privitka ili prekida niti e-mailova.

Skripta koja radi na 50 testnih e-mailova neće preživjeti susret s produkcijskim okruženjem od 40.000 poruka kroz desetljeće. Što se dogodi kada naiđete na e-mail od 47 MB sa šest ugniježđenih privitaka? A API ograničenja (250 kvotnih jedinica Googlea po korisniku u sekundi, Microsoftovo prigušivanje na oko 10.000 zahtjeva na 10 minuta)? Koji je Vaš plan za povrat kada nešto pođe po krivu na poruci broj 8.347?

Ispravljanje datuma CloudM migracije pomoću Redate.io

Redate.io se izravno povezuje s pogođenim sandučićima (Google Workspace, Microsoft 365 ili IMAP) i skenira e-poruke čiji prikazani datum ne odgovara njihovom izvornom datumu. Skeniranje je besplatno i traje par minuta po sandučiću, prikazujući točan broj pogođenih poruka prije bilo kakve obveze.

Ispravak koristi vlasnički motor za analizu lanca zaglavlja i ne treba znati koji je alat izveo migraciju. Redate.io izvodi ciljanu korekciju metapodataka bez mijenjanja sadržaja poruka, čuvajući privitke, niti, oznake, mape i digitalne potpise. Svaka ispravljena poruka prolazi individualnu verifikaciju integriteta u usporedbi s izvornikom.

Izvorni e-mailovi čuvaju se u vidljivoj sigurnosnoj mapi Redate.io - Originals dok ih sami ne obrišete. Ako nešto treba vratiti, izvornici su točno tu u sandučiću.

Za MSP-ove koji su koristili CloudM u klijentskim okruženjima, Redate.io obrađuje ispravke više sandučića u mjerilu, s istom verifikacijom po poruci bilo da ispravljate 1 sandučić ili 500.

Vodiči po platformama za CloudM migracije

Proces ispravka prilagođava se odredišnoj platformi. Redate.io automatski upravlja specifičnostima svake platforme, ali za pojedinosti o Vašem postavljanju:

• Ispravak datuma CloudM migracije u Gmailu
• Ispravak datuma CloudM migracije u Outlooku
• Ispravak datuma CloudM migracije u Google Workspaceu
• Ispravak datuma CloudM migracije u Microsoft 365

Za dublje objašnjenje zašto se to događa sa svim migracijskim alatima (ne samo CloudM-om), pogledajte zašto e-mailovi pokazuju krive datume nakon migracije.

Migrirali ste s CloudM-om i ostali s krivim datumima na svakom e-mailu? Pokrenite besplatno skeniranje da vidite koliko je poruka pogođeno i koliko košta ispravak.