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 na odredištu. Kada CloudM upiše tu poruku u ciljano sanduče, odredišni server je tretira kao novu isporuku. Stavlja sveže Received: zaglavlje sa trenutnim datumom i vremenom i postavlja INTERNALDATE (vremenski pečat koji IMAP koristi za sortiranje) na momenat umetanja.

Ovako izgleda lanac zaglavlja nakon CloudM migracije ka 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

Zaglavlje iz 2019. je tu. Originalno Date: zaglavlje i dalje kaže 23. septembar 2019. Ali Outlook čita najnovije Received: zaglavlje da odredi redosled prikaza, a to sada 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 u teoriji radi bolje, ali M365 transportni cevovod ima sopstveno ponašanje. Exchange Online može i dalje postaviti INTERNALDATE na osnovu sopstvene obrade isporuke, u zavisnosti od toga kako poruka ulazi u sistem.

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. M365 transportni sloj stavlja nova Received zaglavlja.
• 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 - odredišni Google tenant uvek pečatira datum migracije na dolazne poruke.
• Lokalni Exchange ka Microsoft 365: Obično se kvari preko IMAP putanje. Ako CloudM koristi EWS na obe strane, očuvanje datuma je pouzdanije, ali nije garantovano.
• Generički IMAP izvor ka bilo kom odredištu: Datumi se kvare. Kada se CloudM poveže na generički IMAP server kao izvor, odredište i dalje dodaje sopstvena zaglavlja isporuke.

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. Problem sa datumima nastaje na odredišnom serveru, ne na CloudM-ovim čvorovima za obradu. Bilo da vaša farma za migraciju radi u CloudM-ovom oblaku ili na vašoj sopstvenoj Azure VM, odredišni mejl server i dalje pečatira datum migracije na svaku poruku koju primi.

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 prepisivanja Received zaglavlja od strane odredišnog servera, 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 koji nose CloudM-ov potpis datuma migracije. 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 koji identifikuje CloudM-specifične obrasce migracije u lancu Received zaglavlja. 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 30 dana. 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.