Recrearea profilului Outlook: de ce se schimbă datele

Intervenția de depanare care strică datele

Un utilizator se plânge că Outlook nu mai sincronizează. Emailurile nu ajung, dosarul Trimise nu se actualizează, roata se învârte la infinit. Tehnicianul diagnostichează un profil corupt, șterge fișierul OST, recreează profilul Outlook de la zero. Rezultat: Outlook se reconectează, emailurile reapar, totul pare să funcționeze.

Până a doua zi dimineață, când utilizatorul deschide căsuța și realizează că 8 ani de corespondență afișează aceeași dată: astăzi.

Este exact același simptom ca o migrare IMAP ratată. Și din aceleași motive.

Ce se întâmplă din punct de vedere tehnic

Pentru a înțelege de ce recrearea unui profil produce acest rezultat, trebuie să revenim la o distincție pe care majoritatea tehnicienilor o cunosc prost: diferența dintre antetul Date: al unui email și INTERNALDATE-ul IMAP.

Fiecare email conține în antetele RFC 2822 un câmp Date: care indică momentul trimiterii mesajului. Acest câmp este scris de clientul de email al expeditorului la momentul trimiterii, apoi transportat intact prin toate serverele până în căsuța dumneavoastră. Nu se schimbă niciodată. Un email trimis pe 14 martie 2019 la 09:32 va avea întotdeauna acel câmp Date: intact, indiferent ce se întâmplă ulterior.

INTERNALDATE-ul IMAP este altceva. Este o metadată gestionată de serverul de email, independentă de conținutul mesajului. Indică momentul în care mesajul a fost "depus" în căsuță. În condiții normale, când un email ajunge prin SMTP, serverul înregistrează ora de primire ca INTERNALDATE. Un email primit pe 14 martie 2019 va avea deci un INTERNALDATE coerent cu data trimiterii.

Outlook, implicit, sortează și afișează emailurile după INTERNALDATE-ul transmis de serverul IMAP, nu după câmpul Date: din mesaj. (Apropo, dacă ați deschis vreodată proprietățile complete ale unui email în Outlook ca să vedeți antetele brute, știți că nu e exact o lectură de plajă.)

Ce declanșează ștergerea fișierului OST

Când Outlook folosește un cont IMAP, menține o bază de date locală: fișierul OST (Offline Storage Table). Acest fișier este o oglindă locală a emailurilor stocate pe server, cu metadatele lor, stările de citire, categoriile etc.

Ștergerea fișierului OST echivalează cu ștergerea acestei oglinzi locale. Outlook trebuie să retransfere totul de la serverul IMAP.

Problema? Când Outlook retransferă un mesaj prin IMAP, folosește comanda FETCH pentru a recupera conținutul. Dar nu utilizează sistematic comanda FETCH INTERNALDATE pentru a recupera și păstra data IMAP originală. În anumite configurații și versiuni de Outlook, clientul reconstruiește indexul local folosind data la care a retransferit mesajul, nu INTERNALDATE-ul stocat pe server.

Și astfel, toate emailurile din căsuță ajung să fie datate în ziua reîncărcării.

Nu toate versiunile de Outlook se comportă la fel

De fapt, acest comportament nu afectează toate versiunile de Outlook în mod identic, și tocmai asta face diagnosticarea dificilă.

Outlook 2016 și 2019 în modul IMAP au comportamente documentate de reconstruire incorectă a indexului după ștergerea cache-ului. Noul Outlook (bazat pe web, implementat progresiv din sfârșitul anului 2023) gestionează cache-ul diferit și poate produce rezultate variabile. Outlook prin Exchange/Microsoft 365 cu un cont configurat în modul Exchange este mai puțin expus acestei probleme specifice, deoarece protocolul MAPI/Exchange gestionează sincronizarea diferit față de IMAP.

Dar dacă utilizatorul dumneavoastră are un cont IMAP configurat în Outlook clasic și un tehnician a șters fișierul OST sau a recreat profilul: riscul este real.

Cum să distingem acest caz de o migrare reală

Un admin IT care primește tichete cu "datele mele sunt greșite" după o recreare de profil poate crede din greșeală că e vorba de o problemă de migrare. Iată cum să distingem cele două cazuri.

Cazul unei migrări IMAP

În cazul unei migrări IMAP (BitTitan, CloudM, imapsync etc.), instrumentul de migrare copiază emailurile de pe un server pe altul. Pentru fiecare mesaj copiat, creează o nouă intrare pe serverul de destinație. Dacă instrumentul nu specifică explicit INTERNALDATE-ul original, serverul de destinație înregistrează ora curentă. În plus, unele instrumente adaugă și un antet Received: cu data migrării, ceea ce agravează problema în anumiți clienți. Puteți citi detaliile acestui mecanism în articolul despre IMAP INTERNALDATE și datele stricate.

Cazul recreării profilului

Aici, emailurile se află în continuare pe același server, cu aceleași INTERNALDATE-uri originale. Nimic nu s-a schimbat pe server. Doar cache-ul local al Outlook a fost reconstruit cu date incorecte. Simptomul vizibil este identic (toate emailurile afișează aceeași dată recentă), dar originea este diferită.

Pentru a confirma: conectați-vă la căsuță prin webmail (Gmail, Outlook.com sau interfața webmail a furnizorului dumneavoastră). Dacă datele afișate în webmail sunt corecte, problema este pur locală în Outlook. Dacă datele sunt și în webmail incorecte, problema este pe server (migrare sau modificarea INTERNALDATE-urilor pe server).

De ce datele originale pot fi recuperate

Vestea bună: în ambele cazuri (migrare sau recreare de profil), datele originale nu sunt pierdute.

Antetul Date: RFC 2822 este parte integrantă a mesajului. Este la fel de imuabil ca și corpul textului sau atașamentele. Un email trimis în 2017 conține în textul brut ceva de genul:

Date: Mon, 12 Jun 2017 14:23:41 +0200

Această linie se află în mesajul stocat pe server. Nu a fost modificată. Ceea ce afișează Outlook (incorect) este o metadată externă față de conținutul mesajului.

Asta face posibilă corectarea. Motorul Redate.io analizează lanțul de antete al fiecărui mesaj pentru a extrage data originală reală, după care efectuează o corecție țintită a metadatelor fără a altera conținutul mesajului. INTERNALDATE-ul vizibil de Outlook este reconstruit din această informație autentică, mereu prezentă în mesaj.

Capcana recreării "curate"

Tocmai ați rezolvat o problemă de sincronizare pentru un utilizator. Outlook-ul lui funcționează din nou, emailurile noi ajung. Închideți tichetul.

Trei zile mai târziu, utilizatorul sună din nou: caută un email de la un furnizor din anul trecut, dar în Outlook toate emailurile din 2023 apar ca primite "ieri". Nu găsește nimic. Arhivarea automată poate fi clasificat emailuri recente tratându-le ca vechi. Iar șeful îi cere o conversație email din septembrie 2022 pentru un litigiu.

Acest scenariu apare regulat. Nu pentru că tehnicianul a lucrat prost, ci pentru că acest comportament al Outlook nu este documentat în mod vizibil în ghidurile standard de depanare.

Soluțiile false care nu rezolvă nimic

Sortarea emailurilor după "Data trimiterii" în loc de "Data primirii" în Outlook este primul lucru pe care îl încearcă utilizatorii. Și pare să funcționeze... până când realizează că sortarea după data trimiterii e disponibilă doar pentru anumite dosare, că dispare când schimbi vizualizarea și că alte aplicații (mobil, webmail, reguli de sortare automată) continuă să folosească INTERNALDATE-ul incorect.

Sortarea după data trimiterii nu este o soluție. Este un plasture care ascunde simptomul fără să atingă problema reală. Explicăm asta în detaliu în articolul Sortarea după data trimiterii nu este o soluție.

Recrearea profilului a doua oară? Nu schimbă nimic dacă Outlook reconstruiește cache-ul cu data curentă.

Export și reimport în PST? Atenție. Un export PST dintr-un Outlook cu date corupte exportă metadatele corupte. Fișierul PST va conține datele greșite. Reimportarea acestui fișier nu corectează nimic și poate chiar agrava situația prin crearea de duplicate cu date incoerente. Subiectul este tratat separat în articolul despre importul PST și datele care devin ziua importului.

Ce face Redate.io în acest caz specific

Indiferent dacă problema vine dintr-o migrare IMAP sau o recreare de profil Outlook, rezultatul pe server este similar: emailuri ale căror metadate de dată sunt incoerente cu conținutul real.

Redate.io se conectează direct la căsuța de email (Google Workspace, Microsoft 365 sau IMAP direct), scanează toate mesajele pentru a identifica cele cu metadate incorecte, apoi aplică pipeline-ul de analiză multi-etapă pentru a corecta fiecare email individual. Fiecare corecție este verificată. Mesajele originale nu sunt niciodată șterse de Redate.io. Ele rămân într-un folder vizibil al propriei căsuțe poștale, până când le ștergeți dumneavoastră.

Procesul gestionează cazurile limită pe care scripturile făcute acasă le ratează sistematic: mesaje S/MIME semnate, emailuri cu codificări non-ASCII în antete (RFC 2047), structuri multipart complexe, antete Date: cu fusuri orare non-standard sau malformate. Un script care rulează corect pe 50 de emailuri de test într-o căsuță de dezvoltare poate corupe iremediabil 2.000 de mesaje în producție. Nu există rollback nativ în IMAP odată ce un mesaj a fost înlocuit fără backup prealabil.

Pentru cazurile legate specific de Outlook, pagina de corecție corectarea datelor copierii manuale IMAP în Outlook detaliază pașii pentru conectarea căsuței și lansarea analizei.

Prevenirea problemei la intervențiile viitoare

Dacă sunteți tehnician sau admin IT și interveniți regulat pe profiluri Outlook, câteva reflexe pot evita această situație.

Înainte de a șterge un fișier OST sau de a recrea un profil, verificați datele afișate în webmail. Dacă sunt corecte, notați asta în tichetul dumneavoastră. După recreare, reconectați-vă la webmail și comparați datele afișate cu cele din Outlook. Dacă apare o discrepanță, problema este identificată imediat, înainte ca utilizatorul să se plângă trei zile mai târziu.

Pentru migrările planificate, checklist-ul de migrare email listează verificările de făcut înainte și după pentru a detecta acest tip de problemă imediat după finalizarea operațiunii.

Ați recreat un profil Outlook și datele din căsuța dumneavoastră sunt acum toate greșite? Lansați un scan gratuit pe Redate.io pentru a identifica emailurile afectate și a corecta metadatele fără a atinge conținutul mesajelor.