Import PST în Outlook: de ce datele devin ziua importului

Simptomul: toate emailurile au data de azi

Tocmai ați terminat un import PST în Outlook. Bara de progres a ajuns la 100%, totul a decurs bine. Deschideți căsuța de intrare... și fiecare email importat afișează data de astăzi. Un mesaj din 2019, altul din 2021, o arhivă de cinci ani: toate poartă aceeași dată. Ziua importului.

Nu este un bug de afișare. Nu este o problemă de fus orar. Este un comportament perfect documentat, consistent cu modul în care IMAP gestionează metadatele de dată. Rămâne însă un dezastru pentru oricine trebuie să regăsească emailuri vechi după dată.

PST local și IMAP: două lumi complet diferite

Înainte de a explica de ce se strică datele, trebuie înțeles ce este un fișier PST din perspectiva gestionării datelor.

Un fișier PST (Personal Storage Table) este un format proprietar Microsoft. Stochează emailurile cu metadatele complete: dată de trimitere, dată de primire, atașamente, categorii, indicatori de citire. Aceste metadate sunt gestionate direct de Outlook, în afara oricărui protocol de mesagerie. Când consultați un PST în Outlook fără conexiune la un server, datele afișate provin direct din câmpurile interne ale fișierului PST. Până aici, totul e în ordine.

Problema apare când încercați să transferați acel conținut într-o căsuță poștală găzduită pe un server IMAP, fie că e vorba de Microsoft 365, Google Workspace sau orice alt furnizor clasic. Acolo ieșiți din lumea PST și intrați în lumea IMAP, iar regulile se schimbă radical.

IMAP APPEND și INTERNALDATE: inima problemei

În IMAP, fiecare mesaj stocat pe server are două tipuri de date privind data:

• Antetul Date: (RFC 2822), care face parte din conținutul mesajului în sine. Este data înscrisă în mesaj de către expeditor.
• INTERNALDATE, o metadată gestionată de serverul IMAP. Reprezintă momentul în care mesajul a fost depus pe server. Această valoare este cea pe care Outlook o folosește pentru a sorta mesajele în vizualizarea "Dată de primire".

(Apropo, dacă ați încercat vreodată să citiți anteturile brute ale unui email, știți că nu e tocmai lectură de vacanță. Dar acolo se petrece totul.)

Când un email ajunge normal pe server, serverul de mesagerie setează automat INTERNALDATE la momentul exact al primirii. Rezultat: data afișată în Outlook corespunde cu momentul în care ați primit mesajul.

Când Outlook importă un fișier PST într-o căsuță IMAP, folosește comanda IMAP APPEND pentru a trimite fiecare mesaj pe server. Standardul IMAP permite specificarea unui INTERNALDATE explicit la un APPEND. Dar Outlook nu face asta. Trimite mesajele fără a specifica un INTERNALDATE. Serverul IMAP, în absența unei instrucțiuni, aplică regula sa implicită: INTERNALDATE este setat la ora curentă, adică momentul importului.

Rezultat: 8.000 de emailuri importate, 8.000 de emailuri cu data de azi.

De ce se comportă astfel Outlook

Nu este o omisiune a Microsoft. Este o alegere de implementare care probabil părea rezonabilă la acea vreme: în cazul de utilizare original al importului PST, utilizatorul arhivează local mesaje și le "importă" în căsuța curentă. Data relevantă pentru sortare ar fi data originală de primire... dar Microsoft a ales să nu propageze INTERNALDATE în timpul operațiunii de import.

Pentru a fi precis, acest comportament privește importul PST prin expertul nativ din Outlook (Fișier > Deschidere și export > Import/Export). Alte metode de import, cum ar fi anumite instrumente terțe sau migrările prin Exchange Admin Center, se pot comporta diferit în funcție de implementarea lor a IMAP APPEND.

Acest comportament este cunoscut și documentat pe forumurile Microsoft de ani de zile. Nu s-a schimbat în Outlook 2016, nici în Outlook 2019, nici în versiunile actuale Microsoft 365. Un utilizator care importă un PST astăzi va întâmpina exact aceeași problemă ca în 2015.

Cum diferă față de o migrare IMAP clasică

Aici lucrurile devin interesante, pentru că importul PST produce un rezultat similar cu o migrare IMAP clasică cu date stricate, dar printr-un mecanism diferit.

Într-o migrare IMAP tipică, de exemplu cu BitTitan MigrationWiz sau imapsync, emailurile trec de pe un server IMAP sursă pe un server IMAP destinație. Instrumentul de migrare preia mesajele și le reinjectează prin IMAP APPEND. Unele instrumente păstrează corect INTERNALDATE, altele nu. Dar în orice caz, mesajele au deja un antet Received: cu data migrării adăugat în tranzit, ceea ce poate perturba afișarea în Outlook independent de INTERNALDATE.

Cu un import PST, mecanismul e mai simplu: nu există un antet Received: de migrare adăugat (fișierele PST nu tranzitează printr-un server de mesagerie intermediar), dar INTERNALDATE nu este setat niciodată la valoarea corectă. Rezultatul vizibil este identic, cauza de bază e ușor diferită.

Această distincție are o consecință directă asupra corectării: abordarea nu este exact aceeași în funcție de dacă tratați o migrare IMAP sau un import PST. Consultați și de ce INTERNALDATE cauzează date stricate pentru o explicație detaliată a ambelor cazuri.

De ce opțiunile de vizualizare din Outlook nu rezolvă nimic

Reacția obișnuită când descoperiți problema este să căutați prin setările Outlook. Și există într-adevăr o opțiune care pare promițătoare: posibilitatea de a sorta emailurile după "Dată" în loc de "Dată de primire".

Sortarea după data de trimitere nu este o soluție. Este un plasture.

Iată de ce: chiar dacă schimbați sortarea pentru a afișa coloana "Dată" (care corespunde antetului Date: din mesaj, deci data originală), mai multe probleme persistă:

• Căutarea în Outlook indexează pe baza INTERNALDATE. O căutare "emailuri din ianuarie 2020" nu va returna emailurile importate din ianuarie 2020, pentru că INTERNALDATE spune că datează din ziua importului.
• Dosarele "Azi", "Această săptămână", "Luna aceasta" din interfața Outlook sunt bazate pe INTERNALDATE, nu pe antetul Date:.
• În interfețele web (Outlook Web App, Gmail) și pe clienții mobili, data afișată și comportamentul de sortare depind aproape întotdeauna de INTERNALDATE-ul serverului.
• Regulile și filtrele automate aplicate pe data de primire nu vor funcționa corect.

Pe scurt, schimbarea vizualizării rezolvă afișarea pentru un utilizator specific, pe un client specific, într-o configurație specifică. Nu corectează problema la sursă.

Re-sincronizarea OST nu ajută nici ea

O altă încercare clasică: golirea cache-ului OST și forțarea unei re-sincronizări complete de pe server. Ideea e că problema vine poate din cache-ul local al Outlook, nu de pe server.

Pistă greșită. Fișierul OST este un cache local care reflectă starea serverului IMAP. Dacă INTERNALDATE este incorect pe server, va fi incorect în OST după re-sincronizare. Ștergerea OST nu schimbă cu nimic datele stocate pe serverul Exchange Online sau Google Workspace. Serverul este cel care are autoritate.

Singura modalitate de a corecta datele este să corectezi metadatele direct pe server, mesaj cu mesaj. Și exact acolo lucrurile devin complicate de făcut manual.

Problema de scară: 1 email e trivial. 15.000 e altă poveste

Tehnic, dacă înțelegi problema, ai putea imagina un script care parcurge căsuța, citește antetul Date: al fiecărui mesaj și corectează INTERNALDATE în consecință. A înțelege problema e un lucru. A corecta 15.000 de emailuri fără a pierde niciunul e cu totul altceva.

Câteva realități din teren:

• API-urile Microsoft Graph și Gmail impun limite de rată (rate limits). Un script naiv va declanșa erori 429 Too Many Requests, va întrerupe execuția în mijlocul unei corecții și vă va lăsa cu o căsuță parțial corectată, fără să știți ce emailuri au fost procesate și care nu.
• Unele emailuri dintr-un PST pot avea anteturi Date: malformate sau lipsă. Un script fără gestionarea acestor cazuri limită poate corupe acele mesaje sau le poate sări în tăcere.
• Emailurile semnate (S/MIME) sau criptate (PGP) au constrângeri suplimentare de integritate. Modificarea metadatelor lor fără precauție poate invalida semnătura criptografică.
• Structurile multipart/alternative cu frontiere MIME complexe reacționează uneori imprevizibil la operațiunile de modificare.
• Niciun mecanism de rollback. Dacă ceva merge prost la mijlocul procesării, cum reveniți la starea inițială?

Un script care funcționează pe 10 emailuri de test nu va funcționa pe o căsuță de producție cu 50.000 de mesaje. Anul trecut, un client cu o arhivă PST de 40 GB a încercat să rezolve asta cu un script Python găsit pe Stack Overflow. Rezultat: 3.000 de emailuri în duplicat, 200 de mesaje cu atașamente inaccesibile și două săptămâni de curățare manuală.

Ce face Redate.io în acest caz concret

Redate.io analizează metadatele fiecărui mesaj din căsuța țintă, identifică emailurile cu date incorecte (inclusiv cele provenite dintr-un import PST) și aplică o corecție prin motorul său proprietar. Pipeline-ul de analiză multi-etapă compară lanțul de anteturi al fiecărui mesaj, extrage data originală cu validare de conformitate RFC și procedează la o corecție țintită a metadatelor fără a altera conținutul mesajului.

Fiecare email corectat este verificat individual. Originalele sunt păstrate într-un dosar de backup vizibil timp de 30 de zile înainte de orice modificare definitivă. Corecția funcționează pe cele trei platforme principale: Microsoft 365 (via Azure AD), Google Workspace (via delegare de domeniu) și IMAP direct pentru furnizorii clasici.

Scanarea inițială este gratuită. Permite să vedeți exact câte emailuri sunt afectate și care este distribuția datelor incorecte, înainte de a decide orice.

Consultați și:

• Date greșite după migrare Microsoft 365
• Outlook: dată primită IMAP vs dată trimisă după migrare
• Se pot corecta datele emailurilor după migrare?

Importul PST a suprascris toate datele emailurilor dumneavoastră? Scanați căsuța gratuit pe Redate.io pentru a măsura amploarea problemei înainte de a acționa.