Toate emailurile vechi au aceeași dată: ce s-a întâmplat?

Simptomul: toate emailurile vechi grupate la aceeași dată

Deschideți Outlook, Gmail sau Apple Mail într-o dimineață. Ceva nu e în regulă. Sute, uneori mii de emailuri vechi afișează toate aceeași dată: cea de acum câteva zile sau câteva săptămâni. Mesaje din 2021, din 2019, din 2016 apar ca și cum ar fi fost primite ieri. Sortarea după dată nu mai are niciun sens. Căutați un email important din anul trecut și e îngropat într-un bloc de mii de mesaje care par să vină toate din aceeași zi.

Emailurile noi, în schimb, afișează date corecte. Doar mesajele vechi sunt afectate.

Ce s-a putut întâmpla?

Primul reflex: să dăm vina pe software

În mod firesc, ne gândim la un bug. Outlook a crăpat. O actualizare care a mers prost. Un fișier corupt. Și de aici începe de obicei un drum lung: căutăm „bug dată Outlook", dăm peste forumuri care vorbesc despre fișiere OST, despre SCANPST.exe, despre recrearea profilului Outlook de la zero...

Petrecem două ore încercând totul. Problema persistă.

De altfel, SCANPST este un instrument de reparare a fișierelor locale de date Outlook (fișierele .pst sau .ost stocate pe calculatorul dumneavoastră). Poate corecta anumite corupții de fișier, dar nu atinge datele stocate pe serverul de email. Altfel spus, chiar dacă reparați fișierul OST la perfecție, datele vor rămâne greșite, pentru că problema nu e la dumneavoastră.

Problema este în emailurile înseși, pe server.

Ce s-a întâmplat de fapt: o migrație

În aproape toate cazurile, acest simptom apare după o migrație de email. Compania dumneavoastră a trecut de la un sistem vechi la Google Workspace, Microsoft 365, sau un server nou. Cineva, undeva, a folosit un instrument pentru a transfera toate emailurile dintr-un loc în altul.

Poate nu ați fost informat. Sau ați știut, dar nu ați făcut legătura cu problema de date. E absolut normal.

Instrumentele de migrație fac o muncă considerabilă: copiază mii de mesaje, dosare întregi, atașamente. Dar au un efect secundar destul de insidios. Când un email este transferat de pe un server pe altul, instrumentul adaugă o linie tehnică mică în email, numită antet "Received:", care înregistrează momentul în care mesajul a ajuns pe noul server. Cu alte cuvinte: data migrării.

Aici e rădăcina problemei.

Cum decide clientul de e-mail ce dată să afișeze

Un e-mail conține de fapt mai multe date diferite, ascunse în datele sale tehnice. Există data trimiterii originale (cea pe care o vedeți de obicei), dar și antete "Received:" care înregistrează fiecare etapă prin care a trecut mesajul pe internet.

(Dacă ați apăsat vreodată pe "Afișare sursă" sau "Vizualizare antete complete" pe un e-mail, probabil ați văzut acele linii criptice care par un zid incomprehensibil de text. Exact asta sunt.)

În condiții normale, clientul dumneavoastră de e-mail se uită la cel mai recent antet "Received:" pentru a decide ce dată să afișeze. Această logică funcționează perfect: ultimul "Received:" corespunde întotdeauna momentului în care mesajul a ajuns în cutia poștală, la câteva secunde după ce a fost trimis.

Dar după o migrare, această logică se întoarce împotriva dumneavoastră. Instrumentul de migrare a adăugat un nou antet "Received:" chiar în vârf, cu ștampila datei transferului. Clientul dumneavoastră de e-mail citește acel antet primul, vede data migrării și o afișează. Data trimiterii originale este încă acolo, intactă, ascunsă mai jos în datele e-mailului. Clientul dumneavoastră nu ajunge niciodată la ea, pentru că se oprește la primul antet.

Rezultat: 8.000 de e-mailuri care par să fi ajuns toate în aceeași marți din noiembrie.

Ce instrumente provoacă acest lucru?

Majoritatea instrumentelor de migrare uzuale se comportă astfel. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (instrumentul gratuit al Google pentru migrarea din Outlook), și multe altele. Nu e neapărat un defect din partea lor: este o consecință a modului în care funcționează tehnic protocolul de e-mail. Aceste instrumente adaugă acel antet pentru că exact asta cere protocolul atunci când un mesaj este retransmis de la un server la altul.

Problema este că nimeni nu avertizează utilizatorii că se va întâmpla asta.

Dacă firma dumneavoastră a schimbat recent furnizorul de e-mail, sau departamentul IT a rulat o "migrare în cloud", cel mai probabil despre asta este vorba. Puteți verifica uitându-vă la datele afectate: se grupează toate în jurul aceleiași perioade? Dacă da, acea perioadă este fereastra de migrare.

Piste false de evitat

Câteva soluții care apar constant pe forumuri și care nu funcționează:

Repararea fișierului de date cu SCANPST

Cum am menționat mai sus: SCANPST repară fișierele Outlook locale (fișierele .pst sau .ost aflate pe calculatorul dumneavoastră). Nu modifică e-mailurile de pe server. După reparare, e-mailurile dumneavoastră vor avea în continuare aceeași dată greșită, pentru că acea dată se află în interiorul e-mailurilor înseși, nu în fișierul local.

Recrearea profilului Outlook

Aceeași logică. Recrearea unui profil Outlook înseamnă să începeți din nou local, apoi să redescărcați toate e-mailurile de pe server. Acele e-mailuri redescărcate vor avea exact aceeași dată greșită ca înainte. Ați pierdut doar timp reconfigurând totul.

Sortarea după "data trimiterii" în loc de "data primirii"

Unele forumuri sugerează schimbarea opțiunii de sortare din Outlook, trecând de la data primirii la data trimiterii. Poate ajuta în unele cazuri... dar nu întotdeauna. Și nu repară nimic pentru alte aplicații, alte dispozitive sau alte persoane care accesează cutia dumneavoastră poștală. Cauza de fond rămâne aceeași. Sortarea după data trimiterii nu este o soluție, este un bandaj.

Reinstalarea clientului de e-mail

Nu. E-mailurile sunt pe server, nu în program. Reinstalarea Outlook, Gmail, Apple Mail sau Thunderbird nu schimbă nimic la datele stocate online.

Vestea bună: datele reale sunt încă acolo

Iată ceva important de înțeles, și care face posibilă corectarea: data trimiterii originale a fiecărui e-mail nu a fost ștearsă. Este încă în e-mail, într-un antet numit "Date:" care corespunde datei de trimitere alese de expeditor. Acesta este un standard de e-mail (definit de o specificație tehnică numită RFC 2822) pe care toate instrumentele de migrare îl respectă, pentru că modificarea lui ar fi o violare gravă a protocolului.

Cu alte cuvinte, dacă ați primit un e-mail pe 14 martie 2022, acel e-mail conține încă acea dată undeva în datele sale. Doar că nu mai este cea pe care clientul dumneavoastră o afișează primul.

Exact asta face posibilă corectarea. Nu este o pierdere de date. Este o problemă de citire a metadatelor: clientul dumneavoastră de e-mail citește data greșită, în timp ce data corectă este încă prezentă. Puteți citi mai multe despre mecanismul de fond în această explicație detaliată despre motivul pentru care e-mailurile arată date greșite după migrare.

De ce corectarea pe cont propriu este riscantă

Poate vă întrebați dacă o persoană din IT ar putea scrie un script care să repare asta. Înțelegerea a ceea ce se întâmplă este un lucru. Corectarea ei curată pe mii de e-mailuri fără să pierdeți niciunul este cu totul altceva.

Un e-mail nu este un simplu fișier text. Poate conține atașamente, semnături digitale, conținut codificat în formate complexe. Modificarea metadatelor unui astfel de mesaj fără a-i strica structura înseamnă gestionarea a zeci de cazuri particulare: mesaje semnate S/MIME, e-mailuri criptate PGP, codificări nestandard, structuri multipart... Un script propriu care funcționează pe 20 de e-mailuri de test va da foarte probabil greș pe o cutie poștală de producție cu 15.000 de mesaje. Și dacă ceva nu merge bine, cum verificați că niciun e-mail nu a fost deteriorat sau pierdut? Cu un script propriu: nu puteți.

Fără un mecanism de backup și o verificare pe fiecare mesaj în parte, riscul unor pagube colaterale este real.

Ce face Redate.io

Redate.io este un serviciu construit special pentru această problemă. Se conectează la cutia dumneavoastră poștală (Google Workspace, Microsoft 365, sau un server IMAP), identifică e-mailurile a căror dată a fost alterată de o migrare, și le corectează printr-un motor propriu care analizează lanțul de antete și reconstruiește metadatele de dată pentru fiecare mesaj în parte.

Fiecare e-mail corectat este verificat individual. Originalele sunt păstrate într-un folder de backup vizibil în propria cutie poștală, până când le ștergeți dumneavoastră înșivă. Dacă ceva nu pare în regulă, puteți reveni la starea inițială.

Scanarea inițială este gratuită: Redate.io analizează cutia dumneavoastră poștală și vă arată exact câte e-mailuri sunt afectate, înainte să decideți orice. Fără surprize.

Prețul este o plată unică, în funcție de volumul de e-mailuri de corectat. Fără abonament. Plătiți o singură dată, problema este rezolvată.

Vreți să vedeți amploarea reală a problemei înainte să vă angajați la ceva? Rulați o scanare gratuită a cutiei dumneavoastră poștale pe Redate.io și aflați în câteva minute câte e-mailuri sunt afectate.