Date greșite după migrarea IMAP spre Exchange Online

Scenariul clasic de luni dimineață

Tocmai ați finalizat migrarea IMAP spre Exchange Online. Batch-ul s-a încheiat fără erori în centrul de administrare Exchange, cutiile sunt sincronizate, utilizatorii se pot conecta. Vineri seară închideți calculatorul cu sentimentul că ați terminat treaba.

Luni dimineață încep tichetele. "Toate emailurile mele sunt datate de vineri." "Istoricul din Inbox este inutilizabil." "Lipsesc emailuri vechi." De fapt nu lipsește nimic: emailurile sunt acolo, dar Outlook le afișează toate cu data migrării în loc de data originală de trimitere. Un email din 2019 apare datat de vinerea trecută. Rezultat: întreaga cutie pare să conțină doar mesaje recente.

Este una dintre cele mai frustrante probleme ale migrărilor IMAP spre Exchange Online, și este aproape sistematic subdocumentată de Microsoft.

De ce migrarea prin EAC strică datele

Când folosiți centrul de administrare Exchange (EAC) pentru a configura o migrare IMAP dintr-un server local (Dovecot, Courier, Cyrus, UW-IMAP, oricare ar fi), Exchange Online se conectează la serverul sursă prin IMAP, preia mesajele și le injectează în cutiile destinație prin propriul pipeline intern de transport.

Exact acolo apare problema.

Fiecare email care trece prin pipeline-ul de transport Exchange primește automat un antet Received: cu marcaj de timp. Acesta este un comportament standard al serverelor SMTP și IMAP de zeci de ani: fiecare server care atinge un mesaj îi aplică propria semnătură temporală. Problema este că Outlook (în special Outlook pentru Windows, în versiunile recente) folosește cel mai recent antet Received: ca referință de afișare atunci când alte metadate sunt ambigue.

Antetul Date: original (cel care indică momentul real al trimiterii, în sensul RFC 2822) este încă prezent în mesaj. Nu a fost șters. Dar este „eclipsat" de acel nou antet Received: adăugat de Exchange în timpul injectării.

În același timp, INTERNALDATE IMAP (metadatele pe care serverele IMAP le folosesc pentru a data intern mesajele, și care determină sortarea în majoritatea clienților) este setat la data injectării, nu la data originală a e-mailului. Exchange Online nu are o modalitate nativă de a păstra INTERNALDATE-ul serverului sursă în timpul unei migrări în lot prin EAC.

EAC vs. instrumente terțe: o diferență importantă

Aici merită separate două situații. Cu instrumente precum BitTitan MigrationWiz sau CloudM Migrate, aceeași problemă există, dar aceste instrumente includ uneori opțiuni de configurare (parțial documentate, adesea ascunse în setări avansate) care încearcă să păstreze anumite metadate de dată.

Migrarea nativă prin EAC nu oferă nimic de acest fel. Microsoft nu expune niciun parametru pentru a controla păstrarea INTERNALDATE în pipeline-ul de migrare în lot. Este o cutie neagră: configurați lotul, îl rulați, iar Exchange face ce vrea intern. Și ceea ce face, în mod constant, este să dateze mesajele cu momentul injectării.

(Dacă ați încercat vreodată să citiți anteturile brute ale unui e-mail migrat prin EAC, știți că antetul Received: adăugat de Exchange este instant recognoscibil: conține referințe la servere interne Microsoft precum *.protection.outlook.com sau *.prod.exchangelabs.com, cu un marcaj de timp care corespunde exact cu fereastra de migrare.)

De ce recrearea lotului nu rezolvă nimic

Reacția instinctivă a multor administratori IT este: „Dacă șterg cutiile poștale migrate și rulez lotul din nou de la zero, poate de această dată datele vor fi corecte."

E de înțeles. Dar nu funcționează.

Problema nu este în configurarea lotului. Nu este o casetă de bifat pe care ați ratat-o. Este în arhitectura însăși a pipeline-ului de transport Exchange, care se comportă identic la fiecare migrare. Rularea lotului din nou produce exact același rezultat: aceleași anteturi Received: cu noua dată de migrare și aceleași INTERNALDATE incorecte. Veți fi pierdut timp și veți fi deranjat utilizatorii a doua oară, pentru nimic.

Unii administratori încearcă și să ajusteze setările de sortare din Outlook („sortare după data trimiterii" în loc de „data primirii"). Sortarea după data trimiterii nu este o soluție. Este un bandaj. Antetul Date: și INTERNALDATE rămân greșite pentru clienții care nu expun această setare, pentru OWA, pentru Outlook Mobile și pentru orice aplicație terță care accesează cutia poștală prin IMAP sau EWS.

Ce se întâmplă de fapt în anteturi

Iată un exemplu simplificat al modului în care apare un e-mail după migrarea prin EAC. Antetul original:

Date: Thu, 14 Mar 2019 09:23:11 +0100
From: alice@olddomain.com
Subject: Q1 2019 Report

După migrare, mesajului i se adaugă la începutul lanțului de anteturi ceva de genul acesta:

Received: from DB7PR0101MB3304.eurprd01.prod.exchangelabs.com
   by DB7PR0101MB3305.eurprd01.prod.exchangelabs.com
   with HTTPS; Fri, 7 Jun 2024 22:41:03 +0000

Outlook vede mai întâi acest antet Received: (este adăugat în vârful blocului de anteturi), îl interpretează drept cea mai recentă dată de procesare și îl afișează drept data primirii. Antetul Date: original din 2019 este încă acolo, intact, câteva linii mai jos. Dar Outlook nu îl folosește pentru afișare în lista de mesaje.

Mai precis: comportamentul variază ușor între versiunile de Outlook. Versiunile de după 2021 (și mai ales noul Outlook pentru Windows, lansat de la finalul anului 2023) sunt deosebit de sensibile la acest lucru pentru că se bazează mai mult pe metadatele Exchange Graph decât pe antetul brut Date:. Asta înseamnă că migrări care nu au cauzat nicio problemă vizibilă cu Outlook 2016 pot acum să dea greș cu noul Outlook.

Cine este de fapt afectat

Cele mai comune servere IMAP sursă în acest tip de migrare sunt Dovecot (răspândit în medii Linux/cPanel) și Courier. Ambele expun valori INTERNALDATE prin IMAP pe care EAC nu le păstrează. Dacă migrați de la Exchange local la Exchange Online (hibrid sau cutover), comportamentul este diferit pentru că Microsoft folosește un protocol de transport intern (MAPI/EWS) care păstrează mai bine metadatele. Migrarea IMAP generică prin EAC este cea care cauzează problema.

Utilizatorii cel mai greu afectați sunt cei cu istorice lungi ale cutiei poștale (5+ ani) și volume mari de mesaje. Un utilizator cu 300 de e-mailuri își va recupera rapid situația. Un director de vânzări cu 12.000 de e-mailuri sortate după dată, pe care se bazează zilnic pentru a găsi conversațiile cu clienții, este practic paralizat.

De ce un script făcut în casă e o idee proastă aici

Unii administratori IT care înțeleg problema tehnică sunt tentați să scrie un script PowerShell sau Python pentru a corecta manual anteturile. Conceptul de bază poate părea simplu odată identificat mecanismul. Dar a rula efectiv o corecție în producție este cu totul altă poveste.

Mai întâi, cazurile limită. E-mailurile semnate S/MIME și mesajele criptate PGP au o structură care nu tolerează modificarea anteturilor fără a invalida semnătura. Mesajele multipart/alternative cu limite MIME malformate (frecvente pe serverele Courier mai vechi) pot fi corupte de un script care modifică mesajul fără a reconstrui corect structura. Anteturile non-ASCII codate conform RFC 2047 (nume de expeditori cu caractere accentuate sau japoneze, de exemplu) sunt o sursă clasică de erori.

Apoi este volumul. Un script care funcționează pe 50 de e-mailuri de test într-un mediu de dezvoltare nu gestionează limitele de rată ale API-ului Exchange Online în producție. O eroare 429 Too Many Requests la ora 2 dimineața, în timpul unui lot de 8.000 de mesaje, fără mecanism de reîncercare, înseamnă o noapte nedormită și posibil mesaje duplicate sau pierdute.

Și întrebarea mai mare: cum verificați că fiecare e-mail corectat este intact? Că niciun fișier atașat nu a fost trunchiat, niciun fir de discuție nu a fost rupt, că etichetele și folderele sunt păstrate? Fără validare individuală, doar speri că totul a mers bine.

Corectarea datelor e-mailurilor după migrare este o problemă care pare un script de 50 de linii, dar are nevoie de mii de linii pentru a fi fiabilă în producție.

Ce face Redate.io diferit

Fiecare persoană se autentifică cu propriul cont Microsoft, iar Redate.io deschide acea cutie poștală pentru a o scana și a găsi e-mailurile a căror dată afișată nu corespunde datei originale, corupte de migrare. Acest pas de scanare este gratuit și oferă o imagine exactă a amploarei problemei: numărul de mesaje afectate, care cutii poștale, intervalul datelor corupte.

Motorul de corectare proprietar al Redate.io procesează apoi fiecare e-mail individual, printr-un flux de analiză în mai multe etape care include verificarea conformității cu RFC și validarea integrității structurale înainte și după corectare, indiferent de instrumentul care a produs migrarea. E-mailurile semnate S/MIME, structurile MIME complexe, codificările non-standard: toate sunt gestionate prin căi de procesare dedicate.

Fiecare mesaj corectat este verificat individual. Originalele rămân într-un folder de backup vizibil, în interiorul propriei cutii poștale, până când le ștergeți dumneavoastră înșivă. Dacă un mesaj anume pare suspect, este lăsat neschimbat: Redate.io semnalează anomalia în loc să riște corupția.

Corectarea se face o singură dată, per cutie poștală, fără abonament.

Pentru migrările Exchange Online în special, fiecare utilizator se autentifică cu propriul cont Microsoft, iar dacă organizația necesită aprobarea unui administrator, Redate.io pregătește un link pe care îl puteți trimite acelui administrator, ceea ce simplifică mult orchestrarea procesării pentru un administrator IT sau un MSP care gestionează multe cutii poștale.

Dacă gestionați mai mulți clienți care au trecut prin acest tip de migrare, consultați și ghidul complet despre corectarea datelor e-mailurilor după o migrare Microsoft 365 pentru o privire de ansamblu asupra diferitelor scenarii acoperite.

E-mailurile sunt acolo, și la fel și datele originale. Rulați o scanare gratuită pe Redate.io pentru a vedea exact câte mesaje sunt afectate în cutiile dvs. poștale Exchange Online, înainte de a decide ce faceți în continuare.