POP spre IMAP: emailurile vechi datează de azi

Scenariul clasic de luni dimineață

Tocmai ați trecut contul de email de la POP3 la IMAP. Configurarea a mers simplu, furnizorul v-a ghidat pas cu pas, totul părea în regulă. Până când ați redeschis căsuța de intrare. Emailurile din 2019, 2021, arhivele de anul trecut... toate afișează aceeași dată: astăzi. Uneori chiar aceeași oră, cu diferențe de câteva secunde.

Nu este un bug al clientului de email. Nu este o problemă de fus orar. Este comportamentul așteptat al protocolului IMAP, și afectează pe oricine remontează emailuri stocate local pe un server prin această metodă.

POP3 vs IMAP: o diferență fundamentală de stocare

Pentru a înțelege de ce apare această problemă, trebuie mai întâi să înțelegeți cum funcționează POP3, și în ce privință diferă radical de IMAP.

Cu POP3, serverul servește exclusiv ca o cutie poștală temporară. Clientul dumneavoastră (Outlook, Thunderbird, Apple Mail) se conectează, descarcă mesajele, apoi le șterge de pe server (sau le lasă, în funcție de configurație). Emailurile trăiesc apoi exclusiv local: într-un fișier .pst pentru Outlook, în profilul local Thunderbird, într-o bază de date pe discul dur.

Cu IMAP, lucrurile stau invers: emailurile trăiesc pe server. Clientul nu face decât să afișeze ce este stocat la distanță. De aici și sincronizarea transparentă între toate dispozitivele.

Problema apare în tranziția dintre cele două. Atunci când remontați emailurile POP locale pe serverul IMAP.

IMAP APPEND: comanda care schimbă totul

Când clientul de email remontează un mesaj local pe un server IMAP, folosește comanda IMAP APPEND. Această comandă spune serverului: „stochează acest mesaj în folderul cutare".

Serverul primește mesajul, îl înregistrează și îi atribuie un timestamp. Acest timestamp este INTERNALDATE. Este metadatele centrale ale IMAP: indică momentul în care mesajul a fost depus pe server. Și implicit, dacă clientul nu specifică explicit o dată în comanda APPEND, serverul folosește... momentul prezent.

Cu alte cuvinte: indiferent că mesajul conține în anteturile sale o dată din 2018, dacă nimeni nu spune serverului „acest email datează din 2018", serverul concluzionează că a fost depus acum și îi atribuie INTERNALDATE-ul de azi.

(Apropo, dacă ați privit vreodată anteturile brute ale unui email, ați văzut linia Date: printre o duzină de alte linii Received:. Acest câmp Date:, definit de RFC 2822, conține adevărata dată de trimitere. Dar INTERNALDATE IMAP este o metadată separată, stocată pe server, care nu are nicio legătură cu conținutul mesajului în sine.)

De ce diferă de o migrare IMAP-to-IMAP

Într-o migrare clasică de pe un server IMAP pe altul (cu BitTitan, CloudM, imapsync etc.), problema este ușor diferită. Instrumentul de migrare copiază mesajele de pe un server pe altul, și în acest caz poate (teoretic) transmite INTERNALDATE original serverului destinație prin comanda APPEND. Problema acolo este că unele instrumente adaugă un antet Received: cu data migrării, ceea ce perturbă afișajul în clienți precum Outlook.

În cazul dumneavoastră, plecați de la date pur locale. Nu există un INTERNALDATE sursă de copiat. Fișierul .pst sau profilul Thunderbird stochează mesajele în propriul format proprietar, cu propriile metadate interne. Când clientul de email recitește aceste mesaje pentru a le remonta pe serverul IMAP, reconstruiește comanda APPEND din conținutul mesajului. Și de cele mai multe ori, nu transmite nicio dată explicită.

Rezultat: serverul IMAP primește sute sau mii de mesaje în minutele care urmează și le atribuie tuturor același interval orar: acum.

Tocmai de aceea problema se propagă instantaneu pe toate dispozitivele. Telefonul, tableta, cel de-al doilea calculator: se conectează cu toții la același server IMAP și văd exact același lucru. Nicio corecție posibilă din partea clientului.

Ce afișează fiecare client, și de ce

Nu toți clienții de email reacționează la fel. Este un aspect pe care mulți administratori IT îl descoperă post-factum.

Outlook (în versiunile recente, mai ales după actualizările din 2023-2024) folosește INTERNALDATE-ul serverului pentru coloana "Primit". Afișează deci data remontării, nu data originală de trimitere. Pentru detalii despre acest comportament specific Outlook, consultați Outlook: dată primită IMAP vs dată trimisă după migrare.

Gmail / Google Workspace și Thunderbird au comportamente ceva mai nuanțate. Gmail, de exemplu, poate folosi uneori câmpul Date: din antetul mesajului pentru afișaj, ceea ce creează impresia că totul este în regulă... până când încercați să sortați după dată și realizați că ordinea este complet aleatorie.

Apple Mail afișează în general data extrasă din antetul Date:, dar sortarea și căutarea se fac prin INTERNALDATE în fundal. Astfel, emailurile pot "părea" corect datate vizual, dar funcționalitatea de sortare nu mai funcționează. Pentru detalii despre comportamentul Apple Mail, consultați Apple Mail: dată greșită după migrare.

Vestea bună: data originală este intactă

Antetul Date: al fiecărui email, cel care conține adevărata dată de trimitere (sau de primire), nu a fost atins. Este încă acolo, în corpul mesajului. Este ceea ce vedeți când deschideți un email și priviți detaliile.

Ce a „stricat" serverul IMAP este doar INTERNALDATE, această metadată externă mesajului. Mesajul în sine este intact.

Asta face posibilă corecția. Și tot asta explică de ce problema poate trece neobservată o vreme: emailurile par corecte când le deschideți unul câte unul. Abia privind lista căsuței de intrare, sortată după dată, problema devine vizibilă. Emailuri din 2019 apar în vârf ca și când tocmai ar fi sosit. Toate cu aceeași dată.

Problema de scară: 3.000 de emailuri sunt altceva decât 3

Poate vă spuneți: „Nu trebuie decât să șterg și să reimport, de data aceasta corect." Pe 5 sau 10 emailuri de test, da, funcționează. Pe o căsuță de 8.000 de mesaje cu dosare imbricate, atașamente voluminoase, emailuri S/MIME semnate și fire de discuție care datează din 2015... este cu totul altceva.

Un script improvizat care funcționează pe un lot de test de 50 de emailuri poate produce cu ușurință duplicate, poate pierde atașamente sau poate strica fire de conversație pe o căsuță de producție. Gestionarea cotelor API, a timeout-urilor de rețea, a mesajelor cu structuri MIME atipice... sunt tot atâtea cazuri-limită pe care un instrument nespecializat nu le gestionează.

Și dacă ceva merge prost la jumătatea drumului? Fără un mecanism de backup și rollback, pierdeți date fără posibilitate de recuperare.

Problema este bine cunoscută administratorilor care gestionează migrări de volum. A înțelege de ce datele sunt stricate este un lucru. A corecta corect 15.000 de emailuri păstrând fiecare structură de mesaj este cu totul altul. Pentru a merge mai departe pe acest subiect, articolul Se pot corecta datele emailurilor după migrare? detaliază diferitele abordări și limitele lor.

Cum gestionează Redate.io acest caz specific

Redate.io a fost conceput tocmai pentru acest tip de situație. Motorul de analiză identifică emailurile al căror INTERNALDATE nu corespunde datei conținute în anteturile mesajului, indiferent că este vorba de o migrare POP spre IMAP, de o migrare între servere IMAP sau de o remontare manuală a arhivelor locale.

Pipeline-ul de analiză în mai multe etape inspectează lanțul de antete al fiecărui mesaj, validează conformitatea RFC și reconstruiește metadatele de dată fără a altera conținutul mesajului: nici textul, nici atașamentele, nici structura MIME, nici eventualele semnături digitale. Fiecare email corectat este verificat individual înainte de validare.

Originalele sunt păstrate într-un dosar de backup vizibil timp de 30 de zile. Dacă ceva nu vă convine, puteți restaura.

Scanarea inițială este gratuită: Redate analizează căsuța dumneavoastră, identifică emailurile afectate și vă indică numărul exact înainte să decideți ceva. Fără angajament în necunoscut.

Redate.io se conectează direct la căsuțele dumneavoastră prin Google Workspace (delegare de domeniu), Microsoft 365 (Azure AD) sau IMAP direct. Nicio instalare locală. Niciun export de fișiere .pst de manipulat manual.

Pentru administratorii care gestionează mai multe căsuțe și doresc o perspectivă practică asupra acestui tip de caz, articolul MSP: corectarea datelor email ale clienților este o lectură complementară utilă. Și pentru specificul corectării în Thunderbird, care are propriul comportament la trecerea POP/IMAP, consultați Thunderbird: dată greșită după migrare.

Dacă urmează să o faceți: anticipați problema

Dacă nu ați remontat încă arhivele locale pe serverul IMAP, sau dacă planificați alte migrări de conturi POP în organizația dumneavoastră, iată ce trebuie reținut.

• Verificați dacă clientul de email suportă transmiterea explicită a datei în comanda APPEND. Thunderbird, de exemplu, a avut comportamente variabile în funcție de versiune pe acest punct.
• Faceți mai întâi un test pe un cont de validare cu 50-100 de mesaje reprezentative: emailuri vechi, cu atașamente, emailuri semnate. Verificați datele afișate în diferiți clienți.
• Planificați corecția înainte ca utilizatorii finali să înceapă să lucreze pe căsuța migrată. A corecta datele pe o căsuță activă este mai complex decât pe una nouă post-migrare.
• Documentați numărul de emailuri înainte și după migrare. Este singura metodă de a detecta pierderi silențioase.

Pentru o checklist completă a punctelor de verificat înainte și după o migrare, articolul Checklist migrare email: preveniți problemele de date acoperă toate cazurile.

Emailurile vechi afișează data de azi după trecerea de la POP la IMAP? Lansați o scanare gratuită pe Redate.io pentru a măsura amploarea problemei și a corecta metadatele de dată fără a atinge conținutul mesajelor.