CloudM Migrate: kako ispraviti pogrešne datume

Problem sa datumima u CloudM Migrate na koji vas niko ne upozorava

CloudM Migrate je završio posao. Kontrolna tabla prikazuje 100% završeno, svi korisnici migrirani, nula grešaka. Zatvorite projektni tiket i pređete na sledećeg klijenta.

A onda, nedelju dana kasnije, IT direktor pozove. "Zašto svaki mejl u mom sandučetu prikazuje 2. april?"

Ne neki mejlovi. Svi. Pet godina klijentske prepiske, pravni dokumenti, HR evidencije, porudžbenice iz 2020, sve prikazuje datum kada je CloudM pokrenuo migraciju. Poruke su tu, sadržaj je netaknut, prilozi su u redu. Ali datumi su pogrešni na svakom pojedinačnom mejlu.

Ovo nije greška u CloudM-u. CloudM-ova sopstvena dokumentacija za podršku to otvoreno priznaje. Problem leži na preseku načina na koji alati za migraciju prenose poruke i načina na koji odredišni mejl serveri obrađuju metapodatke dolazne e-pošte. Ali znati to ne pomaže vašem klijentu čije sanduče je sada nesortivo.

Kako CloudM zapravo prenosi poruke e-pošte

CloudM Migrate se povezuje sa izvornom i odredišnom platformom preko njihovih API-ja. Za Google Workspace, to znači servisni nalog sa delegacijom na nivou domena (konfigurisano u Google Admin konzoli pod Bezbednost > API kontrole). Za Microsoft 365 koristi Exchange Web Services ili Microsoft Graph API, u zavisnosti od putanje migracije.

Kada CloudM pročita poruku sa izvora, dobija kompletan RFC 2822 sadržaj, uključujući sva originalna zaglavlja i telo poruke. Originalno Date: zaglavlje (ono koje je mejl server pošiljaoca pečatirao kada je e-pošta prvi put poslata) dolazi netaknuto. Takođe dolaze i sva originalna Received: zaglavlja koja prate putanju isporuke poruke.

Problem nastaje kada se kopija upisuje. Odredište čuva datum koji mu je dat: Microsoft 365 i Gmail čuvaju originalni datum kada ga kopija nosi. Kada ga ne nosi, kopija dobija momenat umetanja kao svoj datum. A na Google Workspace, svaka poruka upisana preko Gmail API-ja takođe dobija sveže Received: zaglavlje datirano momentom umetanja.

Ovako izgledaju zaglavlja jednog od tih mejlova koja i dalje postoje nakon CloudM migracije ka 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

Originalno Date: zaglavlje iz 2019. je i dalje tu, kao i originalni Received: lanac. Ali u Microsoft 365, datum koji Outlook prikazuje kao datum prijema je sopstveni zapis sandučeta o tome kada je svaki mejl stigao: ako CloudM nije prosledio originalni datum, taj zapis kaže 2. april 2026.

CloudM-ovo podešavanje "Strip Received Headers"

CloudM nudi podešavanje koje adresira ovaj problem. U naprednim podešavanjima odredišne platforme, pod opcijama poruka, postoji prekidač "Strip Received Headers". Kada je aktiviran, CloudM uklanja received zaglavlja pre umetanja poruke i zamenjuje ih jednim zaglavljem koje se poklapa sa Date: zaglavljem e-pošte.

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

Prvo, morate znati za ovo podešavanje pre pokretanja migracije. Većina administratora otkrije problem sa datumima nakon završetka migracije. Do tada, poruke već stoje na odredištu sa pogrešnim datumima. Ponovno pokretanje CloudM-a sa aktiviranim podešavanjem samo stvara duplikate, ne ispravlja ono što je već tamo.

Drugo, ovo podešavanje ima ozbiljno ograničenje kada je Google Workspace odredište. Google-ova sopstvena dokumentacija to potvrđuje: Gmail uvek prepisuje Received: zaglavlja na porukama umetnutim preko API-ja, pečatirajući ih vremenskim pečatom umetanja. Ovo je ograničenje na nivou platforme koje CloudM ne može da zaobiđe. Čak i sa aktiviranim "Strip Received Headers", Google Workspace dodaje sopstveno Received: zaglavlje sa datumom migracije.

Za Microsoft 365 odredišta, podešavanje je manje bitno: Microsoft 365 čuva datum koji mu je dat, tako da prikazani datum zavisi od toga da li CloudM prosleđuje originalni datum svakog mejla.

Koje CloudM migracije kvare datume (a koje ne)

Ne proizvodi svaka CloudM migracija pogrešne datume. Ishod zavisi od kombinacije izvor-odredište i specifične API putanje koju CloudM koristi:

• Google Workspace ka Microsoft 365: Datumi se kvare. CloudM čita preko Gmail API-ja i piše u Exchange, i svaki mejl dobija datum kopije.
• Microsoft 365 ka Google Workspace: Datumi se kvare. Čak i sa Strip Received Headers, Google-ov API prepisuje Received zaglavlje datumom umetanja. CloudM-ova dokumentacija za podršku to naziva "strogim ograničenjem platforme".
• Google Workspace ka Google Workspace: Datumi se kvare. Promene domena, konsolidacije tenanta, akvizicione fuzije: svaka poruka upisana preko Gmail API-ja dobija Received: zaglavlje datirano migracijom.
• Lokalni Exchange ka Microsoft 365: Sve zavisi od datuma koji CloudM prosledi, bilo da kopija ide preko IMAP-a ili EWS-a.
• Generički IMAP izvor ka bilo kom odredištu: Isto pravilo: kada se CloudM poveže na generički IMAP server kao izvor, kopija pokazuje datum migracije svaki put kada originalni datum nije prosleđen odredištu.

Komplikovani deo? CloudM-ova kontrolna tabla za migraciju ne označava ništa od ovoga. Traka napretka se puni, kolona statusa kaže "Završeno", brojevi stavki se poklapaju. Iz CloudM-ove perspektive, migracija je uspela. I tehnički, jeste. Poruke su prenete. Samo datumi nisu preživeli putovanje.

CloudM upravljani i self-servis: isti problem sa datumima

CloudM nudi dva modela implementacije. SaaS verzija (hostovani CloudM Migrate) radi u potpunosti u CloudM-ovoj infrastrukturi. Verzija koju sami hostujete omogućava vam da postavite primarne i sekundarne servere za migraciju na sopstvenoj mreži, Google Cloud-u, Azure-u ili AWS-u.

Neki MSP-ovi pretpostavljaju da opcija sa sopstvenim hostingom daje veću kontrolu nad obradom datuma jer direktno upravljate serverima za migraciju. Ne daje. Ono što određuje datum je to šta motor za migraciju prosleđuje uz svaku poruku, a taj motor je isti gde god radi. Bilo da vaša farma za migraciju radi u CloudM-ovom oblaku ili na vašoj sopstvenoj Azure VM, rezultat po pitanju datuma je isti.

CloudM takođe nudi potpuno upravljanu "Serviced Migration" gde njihov tim vodi projekat od početka do kraja. Isti ishod za datume. Inženjering je identičan, samo su ruke na tastaturi drugačije.

Komplikacija sa nevalidnim Date zaglavljem

Postoji još jedno ponašanje specifično za CloudM koje pogoršava stvari. Kada CloudM naiđe na izvorni mejl sa Date: zaglavljem koje nije u skladu sa RFC 822 (neispravna vremenska zona, nedostaje dan u nedelji, nestandardni format), modifikuje zaglavlje da bi obezbedio da poruka može biti migrirana.

To znači da neki mejlovi gube čak i svoju originalnu referencu datuma. Modifikovano Date: zaglavlje možda uopšte ne odgovara stvarnom datumu slanja. CloudM-ova dokumentacija za podršku pominje ovo kao poznato ponašanje pod "Moguće promene migriranih stavki", ali ne precizira šta modifikovani datum postaje.

Za poštansko sanduče sa 12.000 poruka sakupljenih tokom osam godina, možda imate stotine mejlova sa blago nestandardnim Date zaglavljima (posebno poruke sa starijih mejl servera, automatizovanih sistema ili međunarodnih pošiljalaca sa razlikama u formatiranju vremenskih zona). Nakon CloudM-ove modifikacije, plus kopije koja ne nosi originalni datum, ove poruke završavaju sa datumima koji nemaju nikakve veze sa stvarnošću.

Zašto ručne ispravke ne skaliraju nakon CloudM-a

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

Realnost tog pristupa je sledeća. Potrebno je da se povežete sa potencijalno hiljadama poštanskih sandučića, svako sa hiljadama poruka. Za svaki mejl morate da raščlanite kompletan lanac zaglavlja, identifikujete koja Received: zaglavlja su CloudM ili odredišni server dodali, obradite granične slučajeve (S/MIME potpisane poruke gde modifikacija zaglavlja kvari potpis, PGP enkriptovani sadržaj, višedelne MIME strukture sa ugnežđenim granicama, RFC 2047 kodirani ne-ASCII headeri od japanskih ili korejskih pošiljalaca), i sve to bez gubitka jednog priloga ili kvarenja niti e-pošte.

Skripta koja radi na 50 testnih mejlova iz čistog sandučeta neće preživeti kontakt sa produkcijskim okruženjem od 40.000 poruka koje pokrivaju deceniju. Šta se dešava kad naiđete na mejl od 47 MB sa šest ugnežđenih priloga? Šta sa API ograničenjima brzine (Google-ovih 250 kvotnih jedinica po korisniku u sekundi, Microsoft-ovo ograničavanje na oko 10.000 zahteva na 10 minuta)? Kakav je vaš plan za povratak kada nešto krene naopako na poruci broj 8.347?

I pravo pitanje koje većina administratora ne postavlja dok nije prekasno: kako verifikujete da je svaka ispravljena poruka zaista netaknuta?

Ispravljanje CloudM datuma migracije sa Redate.io

Redate.io se direktno povezuje sa pogođenim poštanskim sandučićima (Google Workspace, Microsoft 365 ili IMAP) i skenira mejlove čiji prikazani datum ne odgovara njihovom originalnom datumu. Skeniranje je besplatno i traje par minuta po sandučetu, prikazujući tačan broj pogođenih poruka pre bilo kakvog angažmana.

Korekcija koristi vlasnički motor za analizu lanca zaglavlja, kome nije potrebno da zna koji alat je izvršio migraciju. Redate.io vrši ciljanu korekciju metapodataka bez menjanja sadržaja poruke, čuvajući priloge, niti, oznake, fascikle i digitalne potpise. Svaka ispravljena poruka prolazi individualnu verifikaciju, proveravajući integritet poruke u odnosu na original pre nego što proces nastavi dalje.

Originalni mejlovi se čuvaju u vidljivoj Redate.io - Originals rezervnoj fascikli. Originali se ne brišu, ostaju u sandučetu dok ih sami ne obrišete. Ako nešto treba da se vrati, originali su tu u sandučetu, nisu zakopani u nekom eksternom arhivu.

Za MSP-ove koji su koristili CloudM u klijentskim okruženjima, Redate.io obrađuje korekcije više sandučića istovremeno, sa istom verifikacijom po poruci bilo da ispravljate 1 sanduče ili 500. Problem sa datumima koji je CloudM ostavio iza sebe ne mora da postane trajna karakteristika poštanskog okruženja vašeg klijenta.

Vodiči za specifične platforme za CloudM migracije

Proces korekcije se prilagođava odredišnoj platformi. Redate.io automatski obrađuje specifičnosti svake platforme, ali za detalje o vašoj konfiguraciji:

• Ispravite CloudM datume migracije u Gmail-u
• Ispravite CloudM datume migracije u Outlook-u
• Ispravite CloudM datume migracije u Google Workspace-u
• Ispravite CloudM datume migracije u Microsoft 365

Za detaljnije objašnjenje zašto se ovo dešava kod svih alata za migraciju, ne samo CloudM-a, pogledajte zašto mejlovi prikazuju pogrešne datume nakon migracije.

Migrirali ste sa CloudM-om i ostali sa pogrešnim datumima na svakom mejlu? Pokrenite besplatno skeniranje da vidite tačno koliko poruka je pogođeno i koliko košta ispravka.