eM Client: date greșite după import PST sau Thunderbird

Simptomul: toate emailurile au aceeași dată

Tocmai ați terminat un import PST în eM Client, sau ați migrat din Thunderbird spre noua dumneavoastră căsuță. Importul s-a desfășurat fără erori aparente. Dar la deschiderea căsuței de intrare, ceva nu e în regulă: sute, uneori mii de emailuri afișează toate aceeași dată, cea din ziua importului. Un email din 2019 pare să fi fost primit ieri. Un contract semnat acum trei ani apare ca și cum tocmai ar fi sosit.

Prima reacție naturală este să blamați eM Client. Setare greșită, coloană de sortare incorectă, bug de afișare... Căutați în preferințe. Comutați între "Dată primită" și "Dată trimisă". Nimic nu se schimbă. Sau mai exact, ceva se schimbă, dar nu rezolvă problema de fond.

E pentru că problema nu e în eM Client. Este în metadatele serverului.

Cauza reală: INTERNALDATE IMAP suprascris în timpul importului

Pentru a înțelege ce se întâmplă, trebuie să coborâm un nivel și să privim cum stochează protocolul IMAP emailurile.

Fiecare mesaj de pe un server IMAP are două tipuri distincte de date:

• Antetul Date: (definit de RFC 2822): este data pe care expeditorul a înscris-o în mesaj la momentul trimiterii. Este încapsulată în corpul mesajului, teoretic intangibilă.
• INTERNALDATE: o metadată de server, externă mesajului, care reprezintă data la care mesajul a fost depus în căsuță. Această valoare este cea pe care clienții de email o folosesc prioritar pentru sortare și afișare.

La un import PST sau la o migrare din Thunderbird, instrumentul de import (fie că e vorba de modulul nativ al eM Client, un instrument terț, sau o copiere manuală IMAP) depune mesajele pe serverul IMAP de destinație. Și dacă instrumentul nu păstrează explicit INTERNALDATE-ul original la momentul depunerii, serverul atribuie automat INTERNALDATE-ul curent, adică data și ora importului.

Rezultat: 8.000 de emailuri arhivate din 2017, toate ștampilate ca "primite" în momentul migrării dumneavoastră.

(De altfel, dacă ați încercat vreodată să citiți anteturile brute ale unui email cu Afișare sursă în eM Client, ați putut constata că antetul Date: original este încă acolo, intact. Acesta e semnul că problema vine din INTERNALDATE-ul serverului, nu din mesajul în sine.)

De ce schimbarea coloanei de sortare nu servește la nimic

Confuzia vine dintr-o distincție pe care puțini o cunosc. În eM Client, ca și în Outlook sau Thunderbird, există în general două coloane de dată:

• "Dată primită" (sau "Dată de sosire"): bazată pe INTERNALDATE-ul serverului.
• "Dată" sau "Dată trimisă": bazată pe antetul Date: al mesajului.

Mulți administratori descoperă asta și cred că au găsit soluția: comutarea pe "Dată trimisă", iar problema dispare vizual în eM Client. Dar nu e chiar exact.

De fapt, chiar sortând după data de trimitere în eM Client, problema persistă pentru toți ceilalți clienți și toate celelalte interfețe care accesează aceeași căsuță. Dacă utilizatorii dumneavoastră își consultă emailurile din OWA, din Outlook la birou, din aplicația Gmail pe mobil sau din orice alt client configurat în IMAP, vor vedea datele importului. Setarea de sortare din eM Client se aplică doar eM Client-ului, și nu acționează asupra metadatelor stocate pe server.

În plus, pe Microsoft 365 și Google Workspace, interfața web nativă sortează după INTERNALDATE. Nu puteți schimba acest comportament din client.

Sortarea după data de trimitere nu e o soluție. E un plasture care maschează o problemă reală fără să o corecteze.

Cazul particular al importului PST

Importul fișierelor PST merită un paragraf separat. Un fișier PST (Personal Storage Table) este un format proprietar Microsoft care stochează local emailuri, contacte și calendare. Când importați un PST în eM Client, sunt posibile două scenarii:

• Import local spre un cont IMAP: eM Client citește PST-ul și împinge mesajele pe serverul IMAP de destinație. Dacă data depunerii nu e păstrată, INTERNALDATE-ul este suprascris. Acesta e cazul cel mai frecvent, și acolo se corup datele.
• Import spre un dosar local: mesajele rămân pe mașina locală, în afara serverului. INTERNALDATE-ul nu există în acest context, iar eM Client poate afișa data Date: a mesajului. Mai puține probleme de dată aici, dar și mai puțină utilitate practică.

Pentru Thunderbird, situația e similară. Dacă folosiți funcția de import integrată din eM Client (care citește profilurile Thunderbird), sau dacă ați copiat dosare mbox prin IMAP, mesajele sunt redepuse pe server fără nicio garanție de păstrare a INTERNALDATE-ului. Iar un server care primește un mesaj fără instrucțiuni explicite de dată pentru INTERNALDATE va aplica sistematic marcajul temporal al momentului primirii.

Ce platforme sunt afectate?

Problema e identică indiferent de platforma de destinație, pentru că e vorba de un comportament standard al protocolului IMAP:

• Microsoft 365 / Exchange Online: INTERNALDATE-ul este suprascris la orice import care nu folosește comanda IMAP APPEND cu un parametru de dată explicit. La fel și pentru o migrare din Exchange on-premise.
• Google Workspace: același comportament. Emailurile importate prin eM Client sau instrumente terțe afișează data importului în Gmail și în interfața de administrare.
• Găzduire IMAP clasică (OVH, Infomaniak, Ionos, o2switch etc.): nicio tratare specială a datei la primirea unui mesaj în APPEND. INTERNALDATE-ul va fi data depunerii.

Un client ne-a contactat după ce a migrat aproape o sută de căsuțe de pe un Exchange 2013 spre Microsoft 365, folosind eM Client ca instrument de tranziție pentru unele conturi VIP. Rezultat: căsuțele migrate corect prin MigrationWiz erau în ordine, dar cele trecute prin eM Client aveau toate datele de import. Utilizatorii afectați nu au apreciat deloc.

De ce un script de casă nu va rezolva ușor problema

Din punct de vedere tehnic, cineva care înțelege protocolul IMAP ar putea lua în calcul un script pentru corectarea INTERNALDATE-urilor. Antetul Date: original e acolo, intact în fiecare mesaj. Ar fi suficient să îl citești și să reconstruiești metadatele serverului corespunzător, nu?

În teorie, da. În practică, e un teren minat.

În primul rând, cazurile limită se acumulează rapid pe o căsuță de producție. Mesajele semnate digital cu S/MIME sunt deosebit de sensibile la orice manipulare de structură. La fel și mesajele PGP cifrate. Emailurile cu atașamente voluminoase, delimitatori MIME non-standard sau codificări Content-Transfer-Encoding neobișnuite se pot corupe în tăcere dacă procesarea nu e riguroasă. Un script care funcționează pe 50 de emailuri de test nu va funcționa fiabil pe o căsuță de 20.000 de mesaje cu 6 ani de istoric.

Apoi, gestionarea cotelor API. Pe Microsoft 365, limitele de rată pe API Graph sau pe EWS la 3 noaptea pe un batch de corectare de 8.000 de mesaje se gestionează. Dar nu se gestionează singure. Un script nesupervizat care întâlnește o eroare 429 Too Many Requests la mesajul numărul 3.741 poate continua, sau nu. Și nu veți ști neapărat ce mesaje au fost procesate.

Și mai ales: cum verificați că fiecare email corectat e intact după procesare? Un script de casă nu are de obicei niciun mecanism de verificare individuală. Redate.io face asta automat, pentru fiecare mesaj.

Corectarea datelor la sursă cu Redate.io

Redate.io atacă problema acolo unde se află: la nivelul metadatelor serverului, nu la nivelul clientului de email.

Procesul începe cu o fază de scanare gratuită. Redate.io se conectează la căsuța vizată (Microsoft 365 prin Azure AD, Google Workspace prin delegare de domeniu, sau IMAP direct pentru găzduirile clasice) și identifică emailurile ale căror metadate de dată sunt inconsistente cu conținutul mesajului. Vedeți rezultatul înainte de orice plată.

Corectarea folosește un motor proprietar care analizează lanțul complet de antete al fiecărui mesaj, aplică o corespondență de modele pe sute de semnături de instrumente de import cunoscute (inclusiv comportamentele specifice ale eM Client, Thunderbird, importurilor PST), și reconstruiește metadatele de dată în mod țintit fără a altera conținutul mesajului, atașamentele sau structura MIME.

Fiecare email corectat este verificat individual. Originalele sunt păstrate într-un dosar de backup vizibil timp de 30 de zile, ceva ce un script de casă nu va face niciodată implicit.

Prețul este simplu: plată unică per căsuță, bazată pe volumul de emailuri de corectat. Fără abonament, fără costuri recurente. Consultați pagina de pornire pentru detalii.

Pentru următoarea migrare: ce trebuie verificat

Dacă planificați o migrare și vreți să evitați această problemă din start, punctul de control este simplu: instrumentul pe care îl folosiți păstrează explicit INTERNALDATE-ul la depunerea mesajelor pe serverul de destinație?

Pentru importurile PST spre Microsoft 365, instrumentele certificate Microsoft (precum MigrationWiz în modurile sale native, sau instrumentul de migrare Exchange Online) gestionează de obicei această păstrare. Pentru importurile manuale prin eM Client sau Thunderbird, rar se întâmplă asta. Verificați documentația instrumentului dumneavoastră înainte de a lansa un import pe căsuțe de producție.

Un checklist bun de migrare email include întotdeauna o verificare post-migrare a datelor pe un eșantion de căsuțe. Dacă vreți să mergeți mai departe, checklist-ul de migrare email acoperă acest punct în detaliu.

Pentru administratorii care gestionează regulat migrări pentru clienții lor, articolul despre corectarea datelor email din perspectiva MSP și cel despre funcționarea INTERNALDATE IMAP oferă o viziune mai completă a problemei.

Datele emailurilor dumneavoastră sunt corupte după un import eM Client? Lansați o scanare gratuită pe Redate.io pentru a măsura amploarea problemei înainte de a decide ce să faceți.