Problema - toate emailurile afișează aceeași dată
După o migrare IMAP, utilizatorii deschid căsuța de email și descoperă ceva îngrijorător: fiecare email afișează exact aceeași dată. În loc de data trimiterii sau primirii originale, toate mesajele poartă data la care migrarea a fost efectuată. Ani de corespondență care par să fi sosit în aceeași zi.
Pentru administratorii IT, e un coșmar. Tichetele curg, utilizatorii nu mai găsesc nimic după dată, iar ordinea cronologică a căsuței de email este, de fapt, distrusă.
Cum arată în Outlook
În Microsoft Outlook, coloana "Primit" afișează data migrării pentru fiecare email. Indiferent dacă un mesaj a fost trimis în 2018 sau în 2023, Outlook arată aceeași dată, cea din ziua în care instrumentul de migrare a procesat căsuța. Inbox-ul, elementele trimise, fiecare folder este afectat. Utilizatorii care se bazează pe sortarea după dată au fluxul de lucru complet distrus.
Cum arată în Apple Mail
Apple Mail pe macOS și iOS se comportă similar. Data afișată lângă fiecare mesaj reflectă marca temporală a migrării, nu data originală. Deoarece Apple Mail folosește metadatele serverului IMAP pentru a determina datele de afișare, aceeași problemă de bază produce același rezultat vizibil. Parcurgând inbox-ul, se vede doar un perete de date identice.
Cum arată în Gmail (interfața web)
Interfața web Gmail prezintă o situație ușor diferită. Clientul web Gmail folosește de obicei headerul "Date" al emailului, astfel că mesajele pot apărea cu data corectă în Gmail. Dar INTERNALDATE-ul IMAP rămâne greșit, ceea ce înseamnă că orice client IMAP care se conectează la acel cont Gmail (Outlook, Thunderbird, Apple Mail) va afișa data migrării. Așadar, aceeași căsuță pare corectă într-un client dar greșită în altul. Destul de confuz.
De ce se întâmplă - cauza tehnică
Cauza profundă stă în modul în care instrumentele de migrare IMAP gestionează headerele de email și în modul în care clienții de email determină ce dată să afișeze. Înțelegerea acestui lucru necesită o scurtă privire asupra protocolului IMAP și a structurii headerelor.
Cum gestionează instrumentele de migrare IMAP headerele
Când un email este migrat de la un server la altul, instrumentul de migrare descarcă mesajul brut de pe serverul sursă și îl încarcă pe serverul de destinație prin comanda IMAP APPEND. În timpul acestui proces, protocolul IMAP impune serverului de destinație să adauge un header "Received" la mesaj. Acest header conține marca temporală a momentului în care mesajul a fost inserat în noul server, adică data migrării.
Headerul "Received" care strică totul
Mesajele email conțin de obicei mai multe headere "Received", fiecare adăugat de un server de email care a gestionat mesajul la livrarea originală. Clienții precum Outlook determină "data primirii" citind headerul "Received" cel mai recent, cel din vârful lanțului. Când un instrument de migrare adaugă un nou header "Received" cu marca temporală a migrării, acesta devine cel mai recent, iar clienții de email afișează această dată în locul celei originale.
Nu este un bug al instrumentului de migrare și nici al clientului de email. Ambele urmează corect standardele IMAP și email. Problema vine din faptul că aceste standarde nu au fost concepute pentru migrarea în masă, iar interacțiunea dintre IMAP APPEND și logica de afișare a datelor produce acest rezultat nedorit.
INTERNALDATE vs headerul Date
Serverele IMAP stochează două valori de dată diferite pentru fiecare mesaj. Headerul "Date" face parte din mesajul email în sine, înregistrează când mesajul a fost compus și trimis inițial. INTERNALDATE este o metadată stocată de serverul IMAP, reprezentând când mesajul a fost livrat sau inserat în acel server specific.
Unele instrumente de migrare încearcă să păstreze INTERNALDATE-ul original definindu-l în timpul comenzii APPEND. Dar chiar și atunci când INTERNALDATE este corect setat, headerul "Received" adăugat cauzează tot probleme în clienții care prioritizează data din "Received" față de INTERNALDATE.
Ce instrumente de migrare cauzează această problemă?
Aproape toate instrumentele de migrare IMAP pot provoca această problemă. Cauza este inerentă protocolului IMAP, nu specifică unui instrument. Unele sunt totuși mai des asociate cu problema din cauza utilizării lor pe scară largă.
BitTitan MigrationWiz
BitTitan MigrationWiz este unul dintre cele mai populare instrumente comerciale de migrare folosite de MSP-uri și consultanți IT. MigrationWiz adaugă un header "Received" care conține "mx.migrationwiz.com" în timpul procesului de migrare. Acest header devine cel mai recent din lanț, cauzând afișarea datei migrării în Outlook și alți clienți IMAP. Consultați ghidurile detaliate pentru corectarea datelor BitTitan în Outlook, Microsoft 365, Google Workspace și Exchange Online.
CloudM Migrate
CloudM Migrate (anterior Cloud Migrator) este utilizat pe scară largă pentru migrările Google Workspace. Ca și celelalte instrumente, CloudM adaugă propriul header "Received" la inserția IMAP. Emailurile migrate cu CloudM afișează data migrării în clienții care se bazează pe headerul "Received". Consultați ghidurile pentru corectarea datelor CloudM în Gmail, Outlook, Google Workspace și Microsoft 365.
imapsync
imapsync este un instrument open source popular printre administratorii Linux și furnizorii de hosting. Deși imapsync încearcă să păstreze INTERNALDATE-ul, serverul de destinație adaugă oricum un header "Received" în timpul operațiunii APPEND. FAQ-ul imapsync recunoaște această limitare dar nu propune o soluție integrată pentru eliminarea headerului adăugat după migrare. Consultați ghidurile pentru corectarea datelor imapsync în Outlook, Gmail, Microsoft 365 și Google Workspace.
GSMMO (Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook (GSMMO) este instrumentul propriu Google pentru migrarea din Exchange sau fișiere PST Outlook către Google Workspace. GSMMO poate produce aceeași problemă de dată, în special când migrarea implică o etapă IMAP intermediară. Consultați ghidurile pentru corectarea datelor GSMMO în Outlook, Gmail și Apple Mail.
Exchange Admin Center (import IMAP nativ)
Centrul de administrare Exchange al Microsoft include o funcționalitate de import IMAP nativă pentru migrarea către Exchange Online (Microsoft 365). Acest instrument de migrare integrat adaugă headere "Received" în timpul importului, cauzând aceeași problemă de afișare a datei. Consultați ghidurile pentru corectarea datelor de migrare Exchange IMAP în Outlook și OWA.
Copiere IMAP manuală
Chiar și copierea manuală a emailurilor între servere IMAP printr-un client precum Thunderbird poate produce această problemă de dată. Când un client de email copiază un mesaj prin IMAP, serverul de destinație îl tratează ca pe o nouă inserție și adaugă propriul header "Received" cu marca temporală curentă. Consultați ghidurile pentru corectarea datelor de copiere IMAP manuală în Outlook, Gmail, Thunderbird și Apple Mail.
De ce soluțiile obișnuite nu funcționează
Confruntați cu această problemă, utilizatorii și administratorii încearcă de obicei mai multe abordări înainte de a realiza că niciuna nu rezolvă cu adevărat problema.
"Sortați după data trimiterii" - de ce nu e suficient
Sugestia cea mai răspândită este trecerea de la sortarea după data de "primire" la data de "trimitere" în clientul de email. Asta schimbă efectiv ordinea de afișare, dar nu corectează datele de bază. Rezultatele căutării arată tot data greșită. Integrările cu calendarul, instrumentele de conformitate și fluxurile automate care depind de data primirii continuă să funcționeze incorect. Iar utilizatorii trebuie să schimbe această setare pe fiecare dispozitiv și în fiecare folder.
Re-migrare - costisitoare și riscantă
Unii administratori iau în considerare reluarea migrării, sperând să evite problema de dată la a doua trecere. Această abordare este costisitoare (500 până la 5.000 EUR în funcție de numărul de căsuțe), consumatoare de timp și riscantă. O a doua migrare introduce aceeași problemă de header "Received", dublează riscul de pierdere a datelor și necesită un timp semnificativ de indisponibilitate. Re-migrarea nu rezolvă problema datei decât dacă instrumentul de migrare este modificat de la bază.
Editarea manuală a headerelor - necesită acces la server
Tehnic, corecția implică eliminarea headerului "Received" de migrare din fiecare email. Dar a face asta manual necesită acces direct la server, cunoașterea structurii headerelor de email și scripting personalizat. Pentru o căsuță de 10.000 de emailuri, editarea manuală este impracticabilă și periculos de predispusă la erori. Emailuri semnate S/MIME, mesaje criptate PGP, structuri multipart cu granițe MIME imbricate, probleme de Content-Transfer-Encoding, headere non-ASCII (RFC 2047), atașamente supradimensionate: fiecare dintre aceste cazuri poate determina un script simplu să corupă date ireversibil. Cum confirmați că 10.000 de emailuri corectate sunt toate intacte? Nu puteți, decât cu un sistem de verificare construit special pentru asta.
Soluția reală - restaurarea datelor originale
Abordarea corectă constă în identificarea artefactelor de migrare din lanțul de headere al fiecărui email și aplicarea corecțiilor țintite care restaurează ordinea cronologică originală în toți clienții de email. Nu este o simplă editare de header. Procesul implică validarea conformității RFC, păstrarea structurii mesajului și potrivirea semnăturilor de migrare dintr-o bază de date cu profiluri de instrumente cunoscute.
Cum corectează Redate.io această problemă
Redate.io se conectează la căsuța de email (Google Workspace, Microsoft 365 sau orice server IMAP) și analizează fiecare email pentru a identifica mesajele afectate de headerele de migrare. Analiza este gratuită și arată exact câte emailuri sunt afectate înainte de orice plată.
Pentru fiecare email afectat, motorul de corecție proprietar Redate.io trece mesajul printr-un pipeline de analiză multi-etapă. Motorul aplică potrivirea semnăturilor pe sute de profiluri de instrumente de migrare cunoscute, construite din procesarea unor volume mari de date email reale. Gestionează problemele de codificare, structurile multipart, atașamentele inline și zeci de cazuri speciale care ar face ca un script DIY să corupă datele (nu genul de descoperire pe care o vrei într-o dimineață de luni). Fiecare email corectat trece printr-o verificare de integritate înainte de finalizare. Mesajul original este mutat într-un folder vizibil "Redate.io - Originals" (nu este șters) și păstrat timp de 30 de zile.
Rezultatul? Emailurile afișează datele lor originale corecte în toți clienții. Sortarea funcționează din nou. Istoricul cronologic al căsuței este restaurat.
Întrebări frecvente
Datele pot fi corectate la luni de zile după migrare?
Da. Headerul "Date" original este păstrat în interiorul mesajului email indiferent de momentul migrării. Redate.io poate corecta datele emailurilor la săptămâni, luni sau chiar ani după migrare. Corecția funcționează atât timp cât headerele originale ale emailului sunt intacte.
Corecția va șterge emailurile?
Nu. Redate.io nu șterge niciodată emailuri. Mesajele originale sunt mutate într-un folder vizibil numit "Redate.io - Originals" în căsuța de email, unde rămân accesibile timp de 30 de zile. Fiecare email corectat este verificat față de original înainte de finalizarea procesului. Dacă verificarea eșuează pentru un mesaj, originalul rămâne intact.
Funcționează cu căsuțele de email partajate?
Da. Redate.io funcționează cu căsuțele de email partajate în Google Workspace și Microsoft 365. Pentru căsuțele partajate, este necesar acces la nivel de administrator pentru a autoriza conexiunea. Procesul este identic cu cel pentru căsuțele individuale: analiză, corecție, verificare.
Pregătit să restaurați datele corecte? Lansați o analiză gratuită pentru a descoperi câte emailuri sunt afectate în fiecare căsuță de email.