Găzduire partajată spre Microsoft 365: datele stricate

Problema pe care nimeni nu v-a semnalat-o

Tocmai ați finalizat migrarea căsuțelor de email de la OVH, Infomaniak, Ionos sau o2switch spre Microsoft 365. Asistentul de migrare din EAC (Exchange Admin Center) a rulat toată noaptea, totul e verde, căsuțele sunt pline. Luni dimineața, primul tichet: "Toate emailurile mele vechi au data de azi." Apoi al doilea. Apoi zece.

Nu e un bug al Microsoft 365. Nu e nici o coincidență. E rezultatul mecanic al unei migrări IMAP, iar în cazul unui furnizor de găzduire partajată, problema este adesea de două ori mai gravă decât într-o migrare clasică. Iată de ce.

Cum gestionează IMAP datele (și unde se strică totul)

Fiecare email stocat pe un server IMAP are două tipuri distincte de datare. Pe de o parte, antetul Date: (definit de RFC 2822), prezent în corpul mesajului însuși, care indică momentul în care mesajul a fost trimis sau primit. Pe de altă parte, INTERNALDATE, o metadată la nivelul serverului care arată la ce dată a fost depus mesajul în căsuță. Această valoare este cea pe care clienții de email precum Outlook o folosesc implicit pentru sortare și afișare.

(Apropo, dacă ați încercat vreodată să citiți antetele brute ale unui email în EAC, știți că nu e exact lectură de plajă. Sunt ușor douăzeci până la treizeci de linii de anteturi înainte să ajungeți la conținut.)

Când un instrument de migrare IMAP transferă un mesaj dintr-o căsuță în alta, trebuie să recreeze acest INTERNALDATE pe destinație. Unele instrumente fac asta corect. Multe nu o fac, sau o fac cu limitări. Serverul de primire, la rândul lui, păstrează ce primește: când o copie poartă data ei originală, Exchange Online păstrează acea dată. Așadar, când datele apar greșit, instrumentul de migrare este cel de verificat, nu Microsoft 365.

Rezultat: fiecare email migrat pare să fi fost "primit" în ziua migrării. Indiferent că datează din 2019.

Scenariul în două etape: de ce găzduirea partajată agravează totul

Iată unde situația devine cu adevărat problematică pentru migrările de la furnizori de găzduire partajată precum OVH, Infomaniak, Gandi, Ionos sau o2switch.

Acești furnizori folosesc de obicei servere partajate Postfix, Dovecot sau cPanel cu configurații IMAP standard. Multe IMM-uri au acumulat acolo ani de emailuri, uneori din 2010 sau 2012. Când decid să treacă la Microsoft 365, migrarea se desfășoară adesea în două etape.

Etapa 1: prima corupere (înainte chiar de Microsoft 365)

În multe cazuri, emailurile au suferit deja o primă migrare. Compania a schimbat furnizorul de găzduire partajată de una sau două ori de-a lungul anilor: de la Gandi la OVH în 2018, apoi de la OVH la Infomaniak în 2022, de exemplu. Fiecare transfer IMAP a putut reseta INTERNALDATE-ul original la data transferului, atunci când instrumentul nu a transmis data originală, iar unele instrumente adaugă și anteturi proprii de migrare, marcate cu acea dată.

Când emailurile ajung pe Microsoft 365, poartă deja cicatrice. Antetul Date: original este intact (face parte din corpul mesajului, nimeni nu îl atinge), dar metadatele de dată au fost deja perturbate o primă dată.

Etapa 2: a doua corupere la trecerea spre Exchange Online

Instrumentul de migrare IMAP din EAC, sau un instrument terț precum BitTitan MigrationWiz configurat în modul IMAP, ingerează atunci aceste emailuri deja deteriorate. Dacă acel instrument nici el nu transmite data originală a fiecărui email, Exchange Online înregistrează emailul cu data transferului, și aceasta este "data de primire" pe care Outlook o afișează în final.

Un email trimis în martie 2017 poate purta astfel două straturi de date greșite: anteturile de migrare lăsate de mutarea din 2022, și data de primire din migrarea spre Microsoft 365 din 2024. Outlook afișează 2024. Utilizatorul vede 2024. E greșit pe două niveluri.

De fapt, pentru a fi complet precis, nu e sistematic cel mai recent antet Received: cel care e utilizat. Outlook determină data afișată dintr-o combinație între INTERNALDATE-ul înregistrat de Exchange Online și anteturile prezente. Dar, de câte ori instrumentul de migrare nu transmite datele originale, mutarea spre Exchange Online adaugă un nou strat de erori peste cel vechi.

Instrumente de migrare și furnizori: combinațiile cu risc

Câteva combinații revin foarte des în migrările de la găzduiri partajate:

• OVH / Infomaniak / Ionos + instrumentul IMAP din EAC: instrumentul nativ Microsoft e practic, dar notoriu pentru că nu păstrează corect datele la migrări IMAP de volum mare.
• cPanel (o2switch, LWS, etc.) + BitTitan MigrationWiz în modul IMAP: MigrationWiz în modul IMAP adaugă propriile anteturi de migrare. Rezultatul este documentat, printre altele, pe pagina corectarea datelor BitTitan în Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync e un instrument puternic, dar gestionarea INTERNALDATE-ului depinde de configurație. Fără opțiunea corespunzătoare, datele nu se păstrează. Vezi și imapsync: datele nu s-au păstrat.
• Orice migrare manuală prin drag-and-drop în Outlook: dacă cineva a copiat dosare întregi prin glisare între două conturi configurate în Outlook, INTERNALDATE-ul fiecărui email este rescris la data copierii. Fără excepție.

Numitorul comun: toate aceste metode duc la Exchange Online cu emailuri a căror dată afișată în Outlook nu mai corespunde niciunei realități.

De ce "să corectezi singur" e o idee proastă la scară mare

Să înțelegi problema e un lucru. Să corectezi 8.000 de emailuri distribuite în 40 de căsuțe Exchange Online, pe conturi cu structuri complexe de dosare, emailuri semnate S/MIME, atașamente voluminoase și fire de discuție imbricate, e cu totul altceva.

Un script PowerShell care pare să funcționeze pe zece emailuri de test poate eșua silențios la mesajul numărul 4.237 din cauza unei frontiere MIME corupte sau a unui antet codificat în RFC 2047 (acel format =?UTF-8?B?...?= pentru caracterele non-ASCII din numele expeditorilor). Fără un mecanism de verificare individuală, nu veți ști. Veți avea pur și simplu un email pierdut.

Riscurile concrete ale abordării DIY pentru acest tip de migrare:

• Mesaje duble dacă logica de inserție eșuează la jumătatea drumului
• Atașamente lipsă dacă structura multipart e reconstruită greșit
• Fire de discuție rupte în Outlook (conversațiile se bazează pe anteturile References: și In-Reply-To: care pot fi alterate)
• Erori 429 (Too Many Requests) de la API-ul Microsoft Graph la ora 3 dimineața, care întrerup procesarea fără niciun rollback
• Nicio modalitate simplă de a verifica că toate cele 8.000 de corecții au fost aplicate corect

Și în cazul specific al migrărilor de la furnizori de găzduire partajată, există o dificultate suplimentară: emailurile poartă mai multe straturi de anteturi Received: parazite, nu doar unul. Un script simplu care elimină "ultimul Received:" nu e suficient. Trebuie analizat lanțul complet pentru a identifica ce antet corespunde cărei migrări, și care reprezintă cu adevărat data originală de primire.

Ce face Redate.io diferit

Fiecare utilizator se conectează cu propriul cont Microsoft, iar Redate.io deschide astfel doar căsuța poștală respectivă, cu accesul oferit de această autentificare. Scanarea inițială este gratuită: Redate.io identifică toate emailurile a căror dată afișată nu corespunde datei reale, și oferă o estimare precisă pe căsuță.

Corecția se bazează pe un motor proprietar care analizează lanțul complet de anteturi al fiecărui mesaj, indiferent de instrumentul de migrare folosit, și reconstruiește metadatele de dată corect, chiar și atunci când mai multe straturi de corupere se suprapun. Fiecare email corectat este verificat individual. Redate.io nu șterge niciodată originalele. Acestea rămân într-un folder vizibil din propria cutie poștală până când le ștergeți dumneavoastră.

Pentru migrările de la furnizori de găzduire partajată, pipeline-ul de analiză multi-etapă al Redate.io gestionează explicit scenariile de dublă corupere: nu se mulțumește să privească ultimul antet Received:, ci parcurge istoricul complet pentru a regăsi data reală de primire. Consultați și corectarea datelor după migrare Microsoft 365 în general, și ghidul specific despre INTERNALDATE-urile stricate în IMAP pentru a înțelege mecanica de fond.

Înainte sau după migrare: două momente pentru a acționa

Două situații, două abordări.

Nu ați migrat încă. Vestea bună: se poate limita paguba. Unele instrumente de migrare (MigrationWiz în modul Exchange, CloudM cu opțiunile corecte) păstrează mai bine datele decât altele. Dar chiar și în cel mai bun caz, o migrare de la un furnizor de găzduire partajată fără un istoric curat va lăsa probabil urme. Planificați un pas prin Redate.io după migrare, înainte de a preda căsuțele utilizatorilor.

Ați migrat deja și ticithetele sosesc. Redate.io corectează căsuțele existente din Microsoft 365, indiferent de vechimea migrării. Scanarea vă va oferi o imagine precisă a stării reale a fiecărei căsuțe înainte de orice intervenție. Consultați și checklist-ul de migrare email pentru a evita aceleași probleme în viitor.

Ați migrat de la OVH, Infomaniak, Ionos sau o2switch spre Microsoft 365 și datele sunt greșite? Creați un cont Redate.io pentru a scana căsuțele gratuit și a vedea exact amploarea problemei înainte de a decide orice.