Noul Outlook: date greșite după migrare, cauze reale

Două versiuni de Outlook, două comportamente pentru aceleași emailuri

Dacă ați migrat recent căsuțe de email spre Microsoft 365 și unii utilizatori se plâng că toate emailurile vechi afișează aceeași dată (cea a migrării), probabil ați observat ceva ciudat: utilizatorii cu Outlook clasic văd uneori data corectă în panoul de lectură, în timp ce cei cu noul Outlook pentru Windows văd sistematic data migrării. Aceeași căsuță. Aceleași emailuri. Rezultate diferite.

Nu este un bug în sensul strict al cuvântului. Este o decizie de arhitectură cu consecințe directe asupra modului în care sunt afișate datele după o migrare IMAP. Pentru a înțelege ce se întâmplă, trebuie să intrăm în detaliile anteturilor de email și ale protocolului IMAP, ceea ce nu este exact lectură ușoară, dar explică de ce nicio manipulare din partea clientului nu este suficientă pentru a rezolva problema.

INTERNALDATE IMAP: adevăratul vinovat

Când un email este stocat pe un server IMAP, are două tipuri de date care coexistă fără a se confunda.

Prima este antetul Date:, definit de RFC 2822. Este data scrisă în mesajul propriu-zis, cea pe care expeditorul a setat-o la momentul trimiterii. Face parte din corpul mesajului și nu se schimbă niciodată, indiferent de traseul parcurs ulterior de email.

A doua este INTERNALDATE, un metadat gestionat de serverul IMAP, exterior mesajului. Este data la care serverul a înregistrat mesajul. În timpul unei migrări normale, instrumentele serioase păstrează INTERNALDATE originală. Dar în cazul unei migrări configurate greșit, sau cu anumite instrumente care nu gestionează corect acest metadat, INTERNALDATE este resetată la data zilei de migrare. Rezultatul: toate emailurile migrate poartă aceeași dată de primire din perspectiva serverului.

(De altfel, dacă ați citit vreodată jurnalele imapsync sau MigrationWiz, știți că există opțiuni specifice pentru a încerca să se păstreze INTERNALDATE. Aceste opțiuni nu funcționează întotdeauna, iar unele servere de destinație refuză să le respecte.)

Outlook clasic: cum citește datele

Outlook clasic, adică versiunile COM instalate local (Outlook 2016, 2019, 2021 și clientul desktop Microsoft 365 Apps), folosește un mecanism mai complex pentru a determina ce dată să afișeze în lista de mesaje.

Pentru emailurile din dosarul Trimise, se bazează pe antetul Date:. Pentru emailurile primite, folosește cu prioritate INTERNALDATE de pe server, dar în anumite contexte (în special când cache-ul OST este implicat sau la prima afișare în panoul de lectură) poate citi și lanțul anteturilor Received: pentru a reconstrui o dată de origine aproximativă.

De aceea se observă acest comportament inconsistent: Outlook clasic poate uneori afișa data corectă în panoul de lectură, pentru că citește antetul Date: original al mesajului pentru previzualizarea detaliată, chiar dacă lista de emailuri folosește INTERNALDATE coruptă. Dar atenție, nu este fiabil și nu corectează nimic. Sortarea rămâne stricată, căutările după dată rămân eronate.

Noul Outlook: o arhitectură radical diferită

Noul Outlook pentru Windows, implementat progresiv începând cu sfârșitul anului 2023, nu mai este o aplicație COM. Este, în esență, o Progressive Web App (PWA) bazată pe același cod ca Outlook pe web (OWA). Această reproiectare are implicații profunde.

Noul Outlook delegă complet afișarea datelor către API-ul Microsoft 365. Nu citește anteturile Received:, nu parcurge lanțul de antete pentru a găsi o dată de origine și nu face nicio tentativă de reconstrucție pe partea de client. Afișează pur și simplu ce returnează serverul: INTERNALDATE.

Rezultat: dacă INTERNALDATE a fost coruptă în timpul migrării, noul Outlook nu are nicio ezitare. Afișează data migrării pentru fiecare email afectat, fără excepție, fără nuanță. Este un comportament mai consistent și mai previzibil decât cel al Outlook clasic, dar face problema de migrare imediat vizibilă și imposibil de ignorat.

Un administrator care migrează 300 de căsuțe într-o vineri seară va descoperi luni dimineața că toți utilizatorii cu noul Outlook văd arhivele lor întregi datate cu weekendul trecut. Tichetele vin repede.

De ce nicio soluție de contornare pe client nu funcționează

Mulți administratori încearcă soluții pe partea de client înainte să înțeleagă că problema se află în datele serverului. Iată tentativele clasice și de ce eșuează.

Sortarea după "Dată trimitere" în loc de "Dată primire"

Sortarea după dată de trimitere în Outlook se bazează pe antetul Date: al mesajului, care este intact. Deci da, această sortare poate funcționa. Dar este un plasture, nu o soluție. Căutările după dată rămân stricate. Regulile bazate pe dată rămân inutilizabile. Și mai ales, utilizatorul trebuie să reconfigureze manual fiecare dosar, fiecare căsuță. Pe 300 de căsuțe, este irealist. Sortarea după data de trimitere nu este o soluție, iar utilizatorii finali nu înțeleg de ce li se cere să-și schimbe obiceiurile.

Golirea cache-ului Outlook sau recrearea profilului

Nu afectează INTERNALDATE de pe server. După recrearea profilului, Outlook resincronizează emailurile de pe server și preia exact aceleași metadate corupte. Cache-ul nu este problema.

Utilizarea OWA în locul clientului desktop

OWA și noul Outlook partajează aceeași bază de date. Dacă INTERNALDATE este coruptă pe serverul Exchange Online, OWA afișează exact aceeași dată greșită. Schimbarea clientului nu schimbă datele.

Problema este pe server, în metadatele fiecărui mesaj. Nicio acțiune pe partea de client nu poate corecta datele stocate pe server.

Capcana anteturilor Received: de ce complică totul

Când un instrument de migrare copiază un email de pe un server pe altul via IMAP, serverul de destinație adaugă automat un antet Received: în fruntea lanțului, cu data și ora inserției. Acesta este comportamentul normal al serverelor SMTP și IMAP conforme cu RFC-urile.

Aceste antete se acumulează în ordinea inversă a traseului parcurs de email. Cel mai recent este primul. Unii clienți de email citesc primul Received: pentru a estima data de primire, ceea ce dă data migrării în loc de data originală.

Precizare: acest comportament nu este specific unui singur instrument. BitTitan MigrationWiz, CloudM, imapsync, GSMMO și chiar o copiere manuală IMAP între doi clienți Thunderbird produc același rezultat. Antetul Date: original rămâne intact în mesaj. Tocmai asta face posibilă corectarea tehnic. Dar INTERNALDATE este un metadat distinct gestionat de server și nu poate fi corectată prin simpla manipulare a anteturilor mesajului pe partea de client.

Pentru mai multe detalii despre acest mecanism, articolul despre IMAP INTERNALDATE și datele stricate explică în detaliu cum este gestionat acest metadat în funcție de servere.

Ce instrumente de migrare cauzează această problemă pe Microsoft 365

Întrebarea revine des: oare toate instrumentele de migrare provoacă această problemă?

Răspunsul scurt este că depinde de configurație și de platforma de destinație. Pe Exchange Online / Microsoft 365, serverul este deosebit de strict în gestionarea INTERNALDATE. Chiar și instrumentele care încearcă să o păstreze eșuează uneori, deoarece API Graph și EWS (Exchange Web Services) au comportamente diferite în funcție de calea de inserție folosită.

BitTitan MigrationWiz este unul dintre cele mai răspândite instrumente pentru migrările spre Microsoft 365, și totodată unul dintre cele cu problemele de date cel mai bine documentate. Pagina dedicată corectării datelor BitTitan în Microsoft 365 acoperă configurațiile specifice de urmărit. CloudM și imapsync au propriile particularități, documentate respectiv pe corectarea datelor CloudM în Microsoft 365 și corectarea datelor imapsync în Microsoft 365.

Ce au în comun toate aceste instrumente: antetul Date: original supraviețuiește migrării. Aceasta este baza pe care o corecție este posibilă.

De ce un script improvizat este o idee proastă aici

Înțelegerea problemei dă uneori iluzia că soluția este simplă. Nu este, nu la scara unui mediu de producție.

Modificarea metadatelor emailurilor stocate pe Exchange Online nu este banală. API Graph de la Microsoft impune limite stricte de rată (eroarea 429 Too Many Requests pe un batch de noapte apare repede). Gestionarea emailurilor semnate S/MIME sau criptate PGP necesită atenție deosebită pentru a nu invalida semnăturile. Structurile multipart cu atașamente voluminoase adaugă constrângeri legate de timeout-urile de rețea. Și mai ales: cum verificați, email cu email, că corecția a funcționat corect fără a altera conținutul sau atașamentele?

Un script care rulează bine pe 50 de emailuri de test nu se va comporta la fel pe o căsuță de 40.000 de mesaje cu 8 ani de istoric. Probabilitatea ca un caz limită să strice ceva crește cu fiecare mie de mesaje în plus. Și fără un mecanism de rollback, o eroare la jumătatea procesului lasă căsuța într-o stare inconsistentă.

Vedeți și: corectarea datei e-mailurilor după migrarea Microsoft 365 pentru o privire de ansamblu completă asupra opțiunilor disponibile.

Ce face Redate.io concret

Fiecare utilizator se conectează cu propriul cont Microsoft, fără parole stocate, iar Redate.io scanează gratuit e-mailurile cu date incorecte, apoi aplică un motor de corecție proprietar pe mesajele identificate. Pipeline-ul de analiză multi-etape realizează o potrivire pe sute de semnături ale instrumentelor de migrare cunoscute, validare de conformitate RFC și o analiză a lanțului de antete pentru reconstrucția metadatelor de dată corecte.

Fiecare email corectat este verificat individual. Mesajele originale sunt păstrate într-un dosar de backup vizibil, chiar în cutia poștală proprie, până sunt șterse de dumneavoastră. Modelul de tarifare este un plată unică per căsuță de email, fără abonament.

Noul Outlook afișează apoi datele corecte, deoarece datele de pe server sunt corectate, nu mascate.

Aveți căsuțe afectate pe noul Outlook? Lansați o scanare gratuită pe Redate.io pentru a identifica exact câte emailuri sunt afectate înainte de a decide cum să procedați.