CloudM Migrate: kako popraviti datume e-mailova

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 na odredišnoj strani. Kada CloudM zapiše tu poruku u odredišni sandučić, odredišni server je tretira kao novu isporuku. Dodaje svježe Received: zaglavlje s trenutnim datumom i vremenom te postavlja INTERNALDATE (vremensku oznaku koju IMAP koristi za sortiranje) na trenutak umetanja.

Ovako izgleda lanac zaglavlja nakon CloudM migracije u 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 točno tu. Izvorno Date: zaglavlje i dalje kaže 23. rujna 2019. Ali Outlook čita najnovije Received: zaglavlje za redoslijed prikaza, a ono 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 popravlja 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 postavka teoretski bolje funkcionira, ali M365 transportni cjevovod ima vlastito ponašanje. Exchange Online može postaviti INTERNALDATE na temelju vlastite obrade isporuke, ovisno o načinu ulaska poruke u sustav.

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. Transportni sloj M365 dodaje nova Received zaglavlja.
• 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, odredišni Google stanar uvijek označava dolazne poruke datumom migracije.
• Lokalni Exchange u Microsoft 365: Obično se kvari putem IMAP puta. Ako CloudM koristi EWS na obje strane, očuvanje datuma je pouzdanije ali nije zajamčeno.
• Općeniti IMAP izvor u bilo koje odredište: Datumi se kvare. Kada se CloudM poveže na općeniti IMAP server kao izvor, odredište svejedno dodaje vlastita zaglavlja isporuke.

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. Problem s datumima nastaje na odredišnom serveru, ne na CloudM-ovim čvorovima za obradu. Bez obzira radi li Vaša migracijska farma u CloudM-ovom oblaku ili na vlastitom Azure VM-u, odredišni mail server označava datumom migracije svaku poruku koju primi.

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 prepisivanja Received zaglavlja od strane odredišnog servera, te poruke završavaju s datumima koji nemaju nikakve veze sa stvarnošću.

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

Možete li to popraviti 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-mailove koji nose potpis datuma CloudM migracije. 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 koji identificira CloudM-specifične migracijske obrasce u lancu Received zaglavlja. 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 30 dana. 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.