Exchange IMAP: de ce data e-mailurilor se strica

Timp de lectură: 8 min Ultima actualizare:

Importurile IMAP din Exchange și data e-mailurilor

Exchange Online atribuie fiecărui mesaj dintr-o cutie poștală o dată, și aceasta este data după care Outlook afișează și sortează mesajele. Pentru un e-mail care ajunge de pe internet, este momentul livrării. Pentru un e-mail copiat printr-o migrare, este data pe care migrarea a dat-o copiei: cea originală, atunci când migrarea o transmite, sau ziua importului, atunci când nu o face.

De aici vine problema datei greșite în importurile Exchange IMAP. Exchange Online nu suprascrie o dată care îi este transmisă. Dar atunci când un import nu transportă data originală a fiecărui e-mail, copia unui mesaj vechi de 7 ani primește data importului, ca și cum ar fi fost livrat chiar atunci.

Rezultatul? Importați 4.000 de e-mailuri de pe un server IMAP vechi în Exchange Online, și e-mailurile arată data importului în loc de data proprie. E-mailuri din 2018, 2020, 2023, datate azi. Utilizatorii dumneavoastră deschid Outlook luni dimineață și văd un perete de mesaje cu exact aceeași dată.

Cum funcționează asistentul de migrare din Exchange Admin Center

Exchange Admin Center (EAC) include un asistent de migrare integrat pentru importurile IMAP. Este interfața grafică la care recurg mai întâi majoritatea administratorilor Exchange: accesați Recipients, apoi Migration, creați un lot nou, selectați "Migrate to Exchange Online", alegeți IMAP ca sursă, încărcați un CSV cu corespondența cutiilor poștale și porniți lotul.

În culise, asistentul de migrare EAC creează un New-MigrationBatch cu tipul de endpoint setat la IMAP. Exchange se conectează la serverul IMAP sursă, citește fiecare mesaj și îl scrie în cutia poștală Exchange Online de destinație. Suficient de simplu pe hârtie.

Dar aici este ce întâlnesc administratorii. Microsoft nu documentează modul în care migrarea stabilește data fiecărui mesaj copiat, iar administratorii raportează e-mailuri care ies cu data sincronizării în loc de data la care au fost primite. Outlook, OWA și orice alt client conectat la acea cutie poștală folosesc apoi acea dată pentru afișare și sortare.

Antetul original Date: din 2019? Este tot acolo, îngropat în anteturile mesajului. Dar Exchange nu îl folosește pentru ordinea de sortare din Inbox.

Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequest și aceeași problemă

Administratorii care preferă linia de comandă recurg de obicei la New-MailboxImportRequest pentru importul fișierelor PST, sau la New-MigrationBatch cu endpoint-uri IMAP pentru migrări server-to-server. Așteptarea este că PowerShell oferă mai mult control. Și oferă, pentru unele lucruri. Nu și în privința datei mesajelor.

New-MailboxImportRequest importă fișiere PST în cutii poștale Exchange Online. Fișierul PST conține marcajele de timp originale pentru fiecare mesaj. Dar cmdlet-ul PowerShell nu are un parametru care să controleze ce dată primește fiecare mesaj importat. Nu există un parametru -PreserveDates (și credeți-mă, administratorii au căutat unul).

New-MigrationBatch -SourceEndpoint cu un endpoint IMAP funcționează similar cu asistentul EAC, doar fără interfața grafică. Aceeași conexiune IMAP, același rezultat pentru dată. Cmdlet-ul oferă parametri pentru filtrarea după interval de dată (-StartAfter, -CompleteAfter) și excluderea folderelor, dar nimic care să controleze modul în care Exchange gestionează marcajul de timp al mesajului primit.

Pentru precizie, acest lucru afectează mai ales data de afișare și ordinea de sortare. Conținutul mesajului, inclusiv antetul Date original, ajunge intact. Doar data primită de copie este greșită, și aceasta este cea din spatele a tot ce vede utilizatorul.

Import IMAP direct vs. instrumente terțe

Are vreo importanță dacă folosiți importul IMAP nativ al Exchange sau un instrument terț precum BitTitan MigrationWiz sau CloudM? Răspunsul scurt: problema datei apare în ambele cazuri, dar din motive puțin diferite.

Cu importul IMAP nativ al Exchange (asistentul EAC sau PowerShell), Exchange însuși se conectează la serverul IMAP sursă și extrage mesajele. Modul în care stabilește data fiecărei copii depinde de Microsoft și nu este documentat.

Cu instrumente terțe, instrumentul de migrare acționează ca intermediar. Citește din sursă, poate transformă mesajul, și scrie în Exchange Online. Când instrumentul scrie prin IMAP, Exchange Online păstrează data pe care o transmite instrumentul: dacă instrumentul trimite data originală a fiecărui e-mail, copia o păstrează; dacă nu, copia primește data migrării. Unele instrumente adaugă și propriul lor antet Received: în timpul transferului.

Diferența practică? Anteturile rămase în urmă nu sunt aceleași de la un instrument la altul, așa că o corectare nu se poate baza pe un singur șablon fix. Problema de fond este identică: data afișată nu este data originală a e-mailului.

De ce regulile de transport din Exchange Online înrăutățesc lucrurile

Iată ceva ce ia prin surprindere chiar și administratorii Exchange experimentați. Exchange Online are reguli de transport (numite acum "mail flow rules" în centrul de administrare) care se pot activa pe mesajele importate. Dacă organizația dumneavoastră are reguli care marchează anteturi, adaugă mențiuni legale sau modifică mesaje pe baza unor condiții, acele reguli pot procesa și e-mailurile importate.

Asta înseamnă că unui e-mail din 2020 i se poate adăuga un subsol cu mențiuni legale, sau un antet X marcat de o regulă de conformitate care nu exista atunci când e-mailul original a fost trimis. Data greșită este simptomul cel mai vizibil, dar regulile de transport pot crea modificări suplimentare neașteptate.

Puteți dezactiva regulile de transport în timpul importului? Da, temporar. Dar majoritatea administratorilor nu se gândesc să o facă, pentru că nici nu se așteaptă ca pipeline-ul de transport să proceseze mesajele migrate. Până își dau seama ce s-a întâmplat, lotul de import este deja complet, iar prejudiciul e deja produs.

Ce înseamnă o dată greșită pentru mediile Exchange

Mediile Exchange tind să fie medii de afaceri. Firme de avocatură, instituții financiare, organizații din domeniul sănătății, agenții guvernamentale. Acestea nu sunt conturi Gmail personale, unde o dată greșită este ușor deranjantă. Acestea sunt cutii poștale în care marcajele de timp ale e-mailurilor au semnificație legală și de reglementare.

O reținere juridică (litigation hold) în Exchange păstrează e-mailurile în funcție de intervalul de timp în care au fost trimise. Dacă fiecare e-mail importat arată data importului în loc de data originală, reținerea captează un set greșit de mesaje. O căutare eDiscovery pentru "toate comunicările dintre ianuarie și martie 2022" nu returnează nimic, pentru că acele e-mailuri arată acum aprilie 2026.

Politicile de retenție se lovesc de aceeași problemă. O organizație cu o politică de retenție de 3 ani poate șterge din greșeală e-mailuri care par să fie din 2026 (și deci "noi") când sunt de fapt din 2019 și ar trebui păstrate. Sau invers: e-mailuri care ar fi trebuit eliminate conform politicii de retenție rămân, pentru că data lor aparentă este recentă.

Un scenariu din finalul anului 2025: un MSP a migrat circa 200 de cutii poștale de la un furnizor Exchange hostat către Microsoft 365, folosind asistentul de migrare EAC. Trei săptămâni mai târziu, responsabilul de conformitate al clientului a semnalat că rapoartele trimestriale de arhivare a e-mailurilor arătau fiecare mesaj arhivat cu aceeași dată. Întreaga arhivă de e-mailuri, veche de 5 ani, părea să fi ajuns într-o singură marți din noiembrie.

Corectarea datei e-mailurilor importate prin Exchange IMAP

Antetul original Date: supraviețuiește importului intact. Importul nu modifică anteturile RFC 2822 originale din interiorul mesajului. Această dată originală este punctul de ancorare pentru corectare.

Redate.io se conectează la cutia poștală Exchange Online (fiecare persoană se autentifică cu propriul cont Microsoft), scanează mesajele cu anomalii de dată cauzate de importul IMAP și aplică un motor propriu de corectare, care efectuează validarea conformității RFC, păstrarea structurii mesajului și reconstrucția țintită a metadatelor. Redate nu are nevoie să știe care instrument a făcut importul: găsește e-mailurile a căror dată afișată nu corespunde datei lor originale.

Fiecare mesaj corectat este verificat individual: integritatea conținutului, sumele de control ale fișierelor atașate, plasarea în folder și înlănțuirea conversațiilor. Originalele rămân într-un folder de backup vizibil din propria cutie poștală, până când le ștergeți dumneavoastră. Dacă ceva nu arată bine, revenirea este la un singur clic distanță.

De ce nu se rezolvă cu un script PowerShell? Pentru că înțelegerea problemei antetului Received este partea simplă. Corectarea a 8.000 de e-mailuri în 50 de cutii poștale fără a deteriora mesajele semnate S/MIME, fără a rupe structurile MIME imbricate, fără a strica anteturile RFC 2047 non-ASCII sau fără a pierde alocările de folder, aceasta este partea grea. Cum verificați că fiecare mesaj corectat dintr-un mediu de producție este intact, că niciun fișier atașat nu s-a pierdut, că niciun fir de conversație nu s-a rupt? Un script care funcționează pe o cutie poștală de test cu 30 de mesaje se va bloca pe cazurile limită din lumea reală. Contractul acela cu un fișier atașat de 42 MB și trei imagini inline încorporate într-o structură multipart/mixed, în interiorul unui multipart/alternative? Baftă.

Ghiduri specifice platformei

Corectarea datei se aplică la nivelul cutiei poștale Exchange Online, dar utilizatorii își accesează e-mailurile prin clienți diferiți. Fiecare afișează datele diferit:

Căutați un context mai larg despre problemele de dată din Microsoft 365, la diferite instrumente de migrare? Consultați ghidul complet de corectare a datei e-mailurilor după migrarea Microsoft 365.

Importul Exchange IMAP a lăsat cutiile poștale cu dată greșită? Începeți cu o scanare gratuită pentru a vedea câte e-mailuri sunt afectate și cât costă corectarea, fără card de credit.

Articole conexe