Date greșite după migrarea Zoho spre Microsoft 365

Ce s-a întâmplat cu cutia poștală

Tocmai ați terminat migrarea domeniului de la Zoho Mail la Microsoft 365. Exchange Online este configurat, cutiile poștale sunt provizionate, înregistrările MX sunt actualizate. Apoi, luni dimineața, un utilizator deschide Outlook și observă că fiecare e-mail din 2021 arată data de azi. Un alt utilizator vede mesaje din anul trecut aflate în vârful inboxului, ca și cum ar fi tocmai sosit. Tichetele încep să se strângă.

Nu este un bug de Outlook. Nu este nici o problemă specifică Zoho. Este ceea ce se întâmplă atunci când instrumentul de migrare nu transmite data originală a fiecărui e-mail. Înțelegerea exactă a motivului este primul pas spre o corectare adecvată.

Cauza tehnică de fond: INTERNALDATE și antetele Received

Un e-mail stocat pe un server IMAP este alcătuit din două lucruri distincte: conținutul brut al mesajului (antetele RFC 2822, corpul, atașamentele) și metadatele de stocare gestionate de serverul IMAP, printre care INTERNALDATE. Aceste metadate sunt cele pe care clienții de e-mail le folosesc, de fapt, pentru afișarea și sortarea mesajelor.

Antetul Date: încorporat în mesajul brut (RFC 2822) reprezintă momentul în care mesajul a fost compus sau trimis de expeditor. INTERNALDATE este momentul în care serverul IMAP a primit sau stocat mesajul. Pe un server sănătos, cele două valori sunt apropiate. După o migrare, situația este cu totul alta.

Cum poate o migrare IMAP să corupă datele

Când un instrument de migrare (Zoho Migration Wizard, imapsync, BitTitan sau altul) transferă un mesaj de la Zoho Mail la Exchange Online, o face prin protocolul IMAP. Instrumentul se conectează la Zoho, preia mesajul, apoi îl introduce în Exchange Online. Și aici apar problemele.

Exchange Online păstrează data care îi este transmisă: atunci când instrumentul trimite INTERNALDATE original al fiecărui mesaj prin comanda APPEND, copia îl păstrează. Unele instrumente de migrare fac acest lucru. Altele nu, sau o fac incorect, caz în care Exchange Online atribuie momentul inserării, adică data migrării, ca INTERNALDATE.

Rezultatul: fie că un e-mail a fost trimis în 2019 sau în 2022, INTERNALDATE-ul lui indică acum săptămâna migrării. Outlook citește această valoare cu prioritate. Sortarea se prăbușește.

Cum se comportă specific Zoho Migration Wizard

Zoho oferă propriul instrument de migrare pentru cei care părăsesc platforma: Zoho Migration Wizard. Este comod pentru migrări simple, dar are un comportament documentat pe forumurile administratorilor: nu transmite întotdeauna corect INTERNALDATE original la inserarea în serverul de destinație.

Mai precis: atunci când Zoho Migration Wizard transmite data originală, Exchange Online o păstrează, iar Outlook arată data corectă. E-mailurile care arată data migrării sunt cele a căror dată nu a fost transmisă.

Administratorii care folosesc instrumente IMAP generice precum imapsync pentru a părăsi Zoho pot întâlni aceeași problemă: imapsync copiază data pe care serverul sursă o deține pentru fiecare mesaj, așa că o dată greșită la sursă devine o dată greșită la destinație. (Dacă ați derulat vreodată printr-un jurnal imapsync la ora două noaptea, căutând o eroare de sincronizare, știți deja că este un instrument puternic, dar nu foarte îngăduitor cu cazurile limită.)

De ce Outlook arată data greșită

Outlook nu se bazează exclusiv pe antetul Date: pentru a afișa data unui e-mail. În majoritatea vizualizărilor, INTERNALDATE furnizat de serverul IMAP/Exchange este cel care determină sortarea în inbox. Antetul Date: original rămâne prezent în mesaj, intact, dar este ignorat în favoarea INTERNALDATE.

De aceea, comutarea pe "Sortare după data trimiterii" în Outlook nu rezolvă, de fapt, nimic. Arată o altă valoare, e drept, dar comportamentul sortării rămâne instabil în funcție de versiunea Outlook și de modul de vizualizare (conversații grupate sau nu). Sortarea după data trimiterii nu este o soluție. Este un plasture care se dezlipește la următoarea actualizare a clientului.

Amploarea reală a problemei

La o migrare de dimensiune medie de la Zoho la Microsoft 365, vorbim cu ușurință de 50.000 până la 500.000 de mesaje afectate, în funcție de vechimea cutiilor poștale și de dimensiunea organizației. Fiecare e-mail transferat în fereastra de migrare poartă aceeași dată coruptă, ceea ce face problema vizibilă imediat pentru utilizatori, chiar din momentul în care deschid Outlook.

Folderele de Trimise sunt de multe ori cele mai afectate. Un agent de vânzări care caută o ofertă trimisă în martie 2022 trebuie să scotocească prin sute de e-mailuri care arată toate data migrării. Impactul operațional este real, nu doar cosmetic.

Și, contrar a ceea ce s-ar putea spera, problema nu se atenuează cu timpul. INTERNALDATE este fixat în momentul inserării. Nu se corectează de la sine. Fără o intervenție activă, acele e-mailuri își păstrează data greșită la nesfârșit.

De ce corectarea pe cont propriu este mai riscantă decât pare

Tentația este de înțeles: din moment ce antetul Date: original este încă în mesaj, trebuie doar să... corectați metadatele. Logic, pare simplu. În practică, pe o cutie poștală de producție cu 80.000 de e-mailuri, este o operațiune care poate deraia catastrofal.

Iată câteva cazuri limită pe care un script artizanal probabil nu le va gestiona bine:

• E-mailuri semnate S/MIME, unde semnătura acoperă întreaga structură a antetelor. Orice modificare a mesajului invalidează semnătura criptografică.
• Mesaje criptate PGP, unde conținutul este opac și orice manipulare a plicurilor MIME poate corupe mesajul.
• Antete non-ASCII codificate conform RFC 2047 (nume de expeditori cu caractere speciale), care se deteriorează dacă scriptul nu gestionează corect codificarea.
• Atașamente codificate Base64 cu terminații de linie malformate, delimitatori MIME non-standard sau structuri multipart imbricate.
• E-mailuri fără antet Date: valid (acestea există, mai ales în exporturile Zoho mai vechi), unde scriptul trebuie să decidă ce să facă.

Un script care funcționează pe 50 de e-mailuri de test nu va funcționa pe o cutie poștală Zoho de producție cu ani de istoric. Și cum verificați, mesaj cu mesaj, că fiecare e-mail corectat este intact și niciun atașament nu a fost trunchiat? Verificarea este cel puțin la fel de complexă ca corectarea în sine.

Există și problema cotelor. API-ul Exchange Online, prin Microsoft Graph, impune limite stricte de rată (clasica eroare 429 Too Many Requests). Un lot netamponat de peste 100.000 de mesaje poate declanșa blocări temporare sau erori silențioase, aproape imposibile de diagnosticat după fapt. Fără un mecanism corect de reîncercare, o luați de la zero.

Cum corectează Redate.io datele după o migrare Zoho

Redate.io se conectează la cutia dvs. poștală Microsoft 365 din momentul în care vă autentificați cu propriul cont Microsoft, fără o aplicație Azure de înregistrat, fără o etapă de consimțământ al administratorului de configurat în avans. Scanarea inițială este gratuită: Redate.io identifică cutiile poștale afectate și estimează volumul de e-mailuri cu data greșită, comparând INTERNALDATE cu valorile păstrate în lanțul de antete al mesajului.

Corectarea folosește un motor propriu care analizează întregul lanț de antete al fiecărui mesaj, nu are nevoie să știe care instrument a făcut migrarea (Zoho Migration Wizard, imapsync sau altul) și reconstruiește metadatele de dată printr-un flux de validare în mai multe etape. Fiecare e-mail corectat este verificat individual: integritatea conținutului, păstrarea atașamentelor, conformitatea RFC. Originalele rămân într-un folder vizibil al propriei dvs. cutii poștale, până când le ștergeți dvs. înșivă.

Fără o nouă migrare. Fără timp de nefuncționare. Utilizatorii continuă să lucreze în Outlook în timp ce corectarea se desfășoară în fundal.

Prețul este o plată unică, în funcție de volum, fără abonament. Detaliile sunt disponibile direct pe site.

Scenarii conexe utile de cunoscut

Dacă gestionați mai multe migrări simultan sau sunteți un MSP care se ocupă de clienți care părăsesc Zoho, rețineți că aceeași problemă apare la migrarea din alte platforme spre Exchange Online. Mecanismul este identic: copia primește data pe care o transmite instrumentul, indiferent de sursă.

Pentru migrările de la Google Workspace, Exchange local sau prin instrumente precum BitTitan MigrationWiz sau CloudM, articole dedicate pe blogul Redate.io descriu comportamentul specific al fiecărui instrument. Articolul Data greșită a e-mailurilor după o migrare Exchange Online oferă o privire de ansamblu completă asupra fiecărui scenariu care ajunge pe acel tenant.

Dacă migrarea dvs. include cutii poștale partajate sau resurse Exchange (săli, echipamente), problema este aceeași, și se aplică aceleași instrumente de corectare. Ghidurile de corectare a datei de migrare Exchange IMAP de pe site-ul Redate.io parcurg pașii de conectare la tenant.

Pentru echipele care folosesc specific imapsync pentru a părăsi Zoho, ghidul imapsync: date neconservate documentează opțiunile de configurare imapsync și de unde provin cu adevărat datele greșite.

Încă vedeți datele migrării Zoho în Outlook? Scanați-vă gratuit cutiile poștale pe Redate.io pentru a măsura amploarea exactă a problemei înainte de a decide cum să acționați.