CloudM Migrate: cum corectați data e-mailurilor

Problema datei CloudM Migrate despre care nimeni nu vă avertizează

CloudM Migrate a terminat treaba. Tabloul de bord arată 100% finalizat, toți utilizatorii migrați, zero erori. Închideți tichetul proiectului și treceți la următorul client.

Apoi, o săptămână mai târziu, sună directorul IT. "De ce fiecare e-mail din cutia mea poștală arată 2 aprilie?"

Nu unele e-mailuri. Toate. Cinci ani de corespondență cu clienții, documente juridice, dosare HR, comenzi de achiziție din 2020, toate arătând data la care CloudM a rulat migrarea. Mesajele sunt acolo, conținutul este intact, atașamentele sunt în ordine. Dar data este greșită pe fiecare, fără excepție.

Aceasta nu este o eroare CloudM. Documentația proprie de suport a CloudM o recunoaște deschis. Problema se află la intersecția dintre modul în care instrumentele de migrare transferă mesajele și modul în care serverele de e-mail destinație gestionează metadatele e-mailurilor primite. Dar a cunoaște acest lucru nu ajută clientul dumneavoastră a cărui cutie poștală a devenit imposibil de sortat.

Cum transferă CloudM mesajele de e-mail

CloudM Migrate se conectează la platformele sursă și destinație prin API-urile lor. Pentru Google Workspace, aceasta înseamnă un cont de serviciu cu delegare la nivel de domeniu (configurat în Google Admin Console, la Security > API Controls). Pentru Microsoft 365, folosește Exchange Web Services sau Microsoft Graph API, în funcție de traseul migrării.

Când CloudM citește un mesaj din sursă, obține conținutul RFC 2822 complet, inclusiv toate antetele originale și corpul mesajului. Antetul original Date: (cel pe care serverul de e-mail al expeditorului l-a aplicat când e-mailul a fost trimis prima dată) rămâne intact. La fel și toate antetele originale Received: care urmăresc traseul de livrare al mesajului.

Problema apare la scrierea copiei. Destinația păstrează data pe care o primește: Microsoft 365 și Gmail păstrează data originală atunci când copia o transmite. Când nu o transmite, copia primește momentul inserării ca dată. Iar pe Google Workspace, fiecare mesaj scris prin API-ul Gmail primește și un antet Received: nou, datat la momentul inserării.

Iată ce mai poartă antetele unuia dintre aceste e-mailuri după o migrare CloudM către 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

Antetul original Date: din 2019 este încă acolo, la fel și lanțul original de Received:. Dar în Microsoft 365, data pe care Outlook o arată drept dată de primire este propria evidență a cutiei poștale despre momentul în care a ajuns fiecare e-mail: dacă CloudM nu a transmis data originală, evidența respectivă spune 2 aprilie 2026.

Setarea "Strip Received Headers" a CloudM

CloudM oferă totuși o setare pentru a rezolva acest lucru. În Advanced Settings ale platformei destinație, sub Message Options, există un comutator "Strip Received Headers". Când este activat, CloudM elimină antetele Received înainte de a insera mesajul și le înlocuiește cu un singur antet care corespunde antetului Date: al e-mailului.

Pare că rezolvă totul, nu? Nu chiar.

În primul rând, trebuie să știți despre ea înainte de a rula migrarea. Majoritatea administratorilor descoperă problema datei după finalizarea migrării. Până atunci, mesajele stau deja în destinație cu date greșite. Rularea din nou a CloudM cu setarea activată creează doar duplicate, nu corectează ce este deja acolo.

În al doilea rând, această setare are o limitare strictă atunci când destinația este Google Workspace. Documentația proprie a Google o confirmă: Gmail rescrie întotdeauna antetele Received: ale mesajelor inserate prin API, aplicându-le marca temporală a inserării. Este o restricție la nivel de platformă pe care CloudM nu o poate depăși. Chiar și cu "Strip Received Headers" activat, Google Workspace adaugă propriul antet Received: cu data migrării.

Pentru destinațiile Microsoft 365, setarea contează mai puțin: Microsoft 365 păstrează data pe care o primește, așa că ceea ce decide data afișată este dacă CloudM transmite data originală a fiecărui e-mail.

Care migrări CloudM strică data (și care nu)

Nu fiecare migrare CloudM produce o dată greșită. Rezultatul depinde de combinația sursă-destinație și de traseul API specific folosit de CloudM:

• Google Workspace către Microsoft 365: Data se strică. CloudM citește prin API-ul Gmail și scrie în Exchange, iar fiecare e-mail primește data copiei.
• Microsoft 365 către Google Workspace: Data se strică. Chiar și cu Strip Received Headers, API-ul Google rescrie antetul Received cu data inserării. Documentația de suport a CloudM numește acest lucru o "limitare strictă de platformă".
• Google Workspace către Google Workspace: Data se strică. Schimbări de domeniu, consolidări de tenanți, fuziuni prin achiziții: fiecare mesaj scris prin API-ul Gmail primește un antet Received: datat la migrare.
• Exchange on-premises către Microsoft 365: Totul depinde de data transmisă de CloudM, indiferent dacă copia trece prin IMAP sau EWS.
• Sursă IMAP generică către orice destinație: Aceeași regulă: când CloudM se conectează la un server IMAP generic ca sursă, copia arată data migrării de fiecare dată când data originală nu este transmisă destinației.

Partea complicată? Tabloul de bord al migrării CloudM nu semnalează nimic din toate acestea. Bara de progres se umple, coloana de stare spune "Completed", numărul de elemente se potrivește. Din perspectiva CloudM, migrarea a reușit. Și tehnic, așa a fost. Mesajele au fost transferate. Doar data nu a supraviețuit călătoriei.

CloudM Managed vs. Self-Service: aceeași problemă a datei

CloudM oferă două modele de implementare. Versiunea SaaS (CloudM Migrate găzduit) rulează integral în infrastructura CloudM. Versiunea self-hosted permite implementarea serverelor de migrare primare și secundare în propria rețea, în Google Cloud, Azure sau AWS.

Unii MSP presupun că opțiunea self-hosted oferă mai mult control asupra gestionării datei, pentru că administrează direct serverele de migrare. Nu este așa. Ceea ce decide data este ceea ce motorul de migrare transmite împreună cu fiecare mesaj, iar acel motor este același oriunde ar rula. Fie că ferma dumneavoastră de migrare rulează în cloudul CloudM sau pe propriul VM Azure, rezultatul pentru date este identic.

CloudM oferă și un serviciu complet administrat, "Serviced Migration", în care echipa lor gestionează proiectul de la un cap la altul. Același rezultat pentru date. Ingineria este identică, doar mâinile de pe tastatură sunt altele. Ați plătit vreodată pentru un serviciu premium și ați primit totuși aceeași limitare ca la varianta gratuită? Așa se simte.

Complicația antetului Date invalid

Există încă un comportament specific CloudM care agravează lucrurile. Când CloudM întâlnește un e-mail sursă cu un antet Date: care nu respectă RFC 822 (fus orar greșit format, ziua săptămânii lipsă, format nestandard), modifică antetul pentru a se asigura că mesajul poate fi migrat.

Aceasta înseamnă că unele e-mailuri își pierd chiar și referința inițială a datei. Antetul Date: modificat poate să nu corespundă deloc cu data reală de trimitere. Documentația de suport a CloudM menționează acest lucru ca un comportament cunoscut, sub "Possible Changes to Migrated Items", dar nu precizează ce devine data modificată.

Pentru o cutie poștală cu 12.000 de mesaje acumulate în opt ani, pot exista sute de e-mailuri cu antete Date puțin nestandard (mai ales mesaje de la servere de e-mail mai vechi, sisteme automate sau expeditori internaționali cu particularități de format al fusului orar). După modificarea făcută de CloudM, plus o copie care nu transmite data originală, aceste mesaje ajung cu o dată care nu mai are nicio legătură cu realitatea.

De ce corecțiile manuale nu funcționează la scară după CloudM

Ați putea repara acest lucru singuri? Tehnic, antetul original Date: este încă păstrat în majoritatea mesajelor (cu excepția celor pe care CloudM le-a modificat pentru conformitate RFC). Unii administratori au încercat să scrie scripturi care să corecteze data după o migrare CloudM.

Iată realitatea acestei abordări. Trebuie să vă conectați la potențial mii de cutii poștale, fiecare cu mii de mesaje. Pentru fiecare e-mail, trebuie să analizați lanțul complet de antete, să identificați ce antete Received: au fost adăugate de CloudM sau de serverul destinație, să gestionați cazurile limită (mesaje semnate S/MIME, unde modificarea antetului sparge semnătura, conținut criptat PGP, structuri MIME multipart cu limite imbricate, antete non-ASCII codate RFC 2047 de la expeditori japonezi sau coreeni) și să faceți toate acestea fără să pierdeți vreun atașament sau fără să stricați firele de discuție.

Un script care funcționează pe 50 de e-mailuri de test dintr-o cutie poștală curată nu va supraviețui contactului cu un mediu de producție de 40.000 de mesaje întinse pe un deceniu. Ce se întâmplă când întâlniți un e-mail de 47 MB cu șase atașamente imbricate? Ce faceți cu limitele API (250 de unități de cotă Google per utilizator pe secundă, limitarea Microsoft la aproximativ 10.000 de cereri la 10 minute)? Care este planul dumneavoastră de revenire când ceva merge prost la mesajul numărul 8.347?

Și întrebarea reală pe care majoritatea administratorilor nu o pun decât prea târziu: cum verificați că fiecare mesaj corectat este într-adevăr intact?

Corectarea datei de migrare CloudM cu Redate.io

Redate.io se conectează direct la cutiile poștale afectate (Google Workspace, Microsoft 365 sau IMAP) și scanează e-mailurile a căror dată afișată nu corespunde cu data originală. Scanarea este gratuită și durează câteva minute per cutie poștală, arătând numărul exact de mesaje afectate înainte de orice angajament.

Corectarea folosește un motor propriu de analiză a lanțului de antete și nu are nevoie să știe cu ce instrument s-a făcut migrarea. Redate.io efectuează o corectare țintită a metadatelor fără să modifice conținutul mesajelor, păstrând atașamentele, firele de discuție, etichetele, folderele și semnăturile digitale. Fiecare mesaj corectat trece printr-o verificare individuală, care confirmă integritatea mesajului față de original înainte ca procesul să continue.

E-mailurile originale sunt păstrate într-un folder de backup vizibil, Redate.io - Originals, până când îl ștergeți dumneavoastră. Dacă e nevoie de o revenire la starea inițială, originalele sunt chiar acolo, în cutia poștală, nu ascunse într-o arhivă externă.

Pentru MSP-urile care au folosit CloudM în mediile clienților, Redate.io gestionează corecții pe mai multe cutii poștale la scară, cu aceeași verificare per mesaj, indiferent dacă corectați 1 cutie poștală sau 500. Problema datei lăsată de CloudM nu trebuie să devină o caracteristică permanentă a mediului de e-mail al clientului dumneavoastră.

Ghiduri specifice platformei pentru migrările CloudM

Procesul de corectare se adaptează la platforma destinație. Redate.io gestionează automat particularitățile fiecărei platforme, dar pentru detalii despre configurația dumneavoastră:

• Corectarea datei de migrare CloudM în Gmail
• Corectarea datei de migrare CloudM în Outlook
• Corectarea datei de migrare CloudM în Google Workspace
• Corectarea datei de migrare CloudM în Microsoft 365

Pentru o explicație mai aprofundată a motivului pentru care se întâmplă acest lucru la toate instrumentele de migrare, nu doar la CloudM, consultați de ce e-mailurile arată o dată greșită după migrare.

Ați migrat cu CloudM și ați rămas cu o dată greșită la fiecare e-mail? Rulați o scanare gratuită pentru a vedea exact câte mesaje sunt afectate și cât costă corectarea lor.