IMAP INTERNALDATE: de ce se strică datele

Cele trei date din interiorul fiecărui email

Fiecare email stocat pe un server IMAP poartă cel puțin trei valori de dată distincte. Înțelegerea modului în care funcționează aceste date și a modului în care clienții de email aleg pe care dintre ele o afișează este cheia pentru a înțelege de ce migrația strică datele. Acest articol este o analiză tehnică aprofundată a sistemului de date IMAP, destinată administratorilor IT și oricui dorește să înțeleagă cauza reală a problemelor de dată apărute după migrare.

1. Headerul „Date" din RFC 2822

Headerul „Date" este definit în RFC 2822 (Internet Message Format). Este setat de clientul de email al expeditorului în momentul în care mesajul este compus și trimis. Acest header face parte din corpul mesajului însuși, călătorește împreună cu mesajul și nu este niciodată modificat de serverele de email de pe traseul de livrare. Un header Date tipic are următoarea formă:

Date: Mon, 15 Jan 2024 09:32:17 +0100

Headerul Date reprezintă „data trimiterii" mesajului. Este data cea mai fiabilă pentru că este setată o singură dată și nu este niciodată modificată. Totuși, reflectă ceasul expeditorului, care poate fi configurat greșit. În cazuri rare, headerul Date poate lipsi complet (în special în notificările automate ale sistemelor sau în mesajele formate incorect).

2. IMAP INTERNALDATE

INTERNALDATE este definit în RFC 3501 (protocolul IMAP4rev1). Este o valoare de metadate stocată pe server, care reprezintă data și ora la care mesajul a fost livrat serverului. Spre diferență de headerul Date, INTERNALDATE nu face parte din mesajul de email propriu-zis. Este stocat separat de serverul IMAP, ca metadată.

Când un email este livrat normal (fără migrare), serverul IMAP setează INTERNALDATE la ora curentă, în momentul livrării. Această valoare se apropie foarte mult de headerul Date, de obicei cu o diferență de câteva secunde sau minute. Clienții de email folosesc frecvent INTERNALDATE ca „dată de primire", pentru că reflectă momentul în care serverul a primit efectiv mesajul.

Aici devine interesant. Când un mesaj este inserat prin comanda IMAP APPEND (ceea ce folosesc instrumentele de migrare), comanda APPEND permite clientului să specifice explicit INTERNALDATE. Instrumentele de migrare bine concepute folosesc această funcție pentru a păstra INTERNALDATE original de pe serverul sursă. Dar, chiar și atunci când INTERNALDATE este setat corect, problema headerului „Received" (descrisă mai jos) poate în continuare să suprascrie data afișată în multe clienți de email.

3. Lanțul de headere „Received"

De fiecare dată când un email trece printr-un server de email, acel server adaugă la începutul mesajului un header „Received". Astfel se formează un lanț de headere Received, care înregistrează traseul urmat de email de la expeditor la destinatar. Cel mai recent header (situat sus) arată ultimul server care a procesat mesajul, iar cel mai vechi (situat jos) arată primul.

Un email normal poate avea între 3 și 6 headere Received, care documentează traseul de la serverul de trimitere al expeditorului, prin eventuale servere releu, până la serverul de primire al destinatarului. Fiecare header Received include o marcă temporală. Iată un exemplu simplificat:

Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100

Cum aleg clienții de email care dată să afișeze

Outlook (Desktop, Web, Mobil)

Microsoft Outlook folosește o combinație între INTERNALDATE și cel mai recent header „Received" pentru a determina data de „Primire" afișată în inbox. În practică, Outlook tinde să prioritizeze marca temporală din headerul Received cel mai recent pentru coloana „Primit". Coloana „Trimis" folosește headerul Date. Cum Outlook sortează implicit după coloana „Primit", marca temporală din headerul Received este ceea ce utilizatorii văd primii.

Apple Mail

Apple Mail pe macOS și iOS folosește în principal IMAP INTERNALDATE pentru afișarea datei. Dacă INTERNALDATE a fost păstrat corect în timpul migrării, Apple Mail poate afișa data corectă, dar numai dacă INTERNALDATE a fost setat explicit în timpul operațiunii APPEND. Dacă instrumentul de migrare nu a setat INTERNALDATE, serverul folosește implicit ora inserării (data migrării). Pentru detalii despre efectul asupra utilizatorilor Apple Mail, vezi Apple Mail: dată greșită după migrare.

Thunderbird

Mozilla Thunderbird oferă cea mai mare flexibilitate. Poate afișa atât „Date" (din headerul Date), cât și „Received" (din headerele Received). Implicit, Thunderbird arată valoarea headerului Date, ceea ce înseamnă că datele pot apărea corecte în Thunderbird chiar și atunci când sunt greșite în Outlook. Coloana „Received" din Thunderbird arată totuși data migrării. Vezi Thunderbird: dată greșită după migrare pentru mai multe detalii.

Interfața web Gmail

Clientul web Gmail folosește headerul Date pentru afișarea principală a datei. Aceasta înseamnă că Gmail web arată de multe ori date corecte, chiar și după migrare. Dar INTERNALDATE de pe serverul Gmail rămâne greșit, ceea ce afectează fiecare client IMAP care se conectează la acel cont Gmail. Diferența dintre Gmail web și Outlook sau Apple Mail este o sursă frecventă de confuzie și una care consumă mult timp de depanare pentru administratori.

De ce IMAP APPEND strică datele

Ce se întâmplă în timpul migrării

Când un instrument de migrare mută un email de pe Serverul A pe Serverul B, instrumentul se conectează la Serverul A prin IMAP și descarcă mesajul brut, apoi se conectează la Serverul B și folosește comanda APPEND pentru a-l insera. În timpul inserării, Serverul B procesează mesajul primit și adaugă un nou header Received cu marca temporală curentă, adică data migrării. Acesta este comportamentul IMAP standard definit în protocol. Serverul tratează fiecare APPEND ca pe o livrare nouă de mesaj.

Rezultatul: un lanț de headere contaminat

După migrare, headerele Received ale emailului arată astfel:

Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100

Headerul Received al instrumentului de migrare este acum intrarea cea mai de sus. Orice client de email care folosește cel mai recent header Received pentru a determina data afișată (Outlook, în special) va arăta „11 aprilie 2025" în loc de „15 ianuarie 2024". Headerul Date original și headerele Received originale rămân intacte dedesubt, dar nu mai sunt în poziția pe care clienții de email o prioritizează.

Chiar și o gestionare corectă a INTERNALDATE nu previne această problemă

Unele instrumente de migrare setează corect INTERNALDATE în timpul operațiunii APPEND. De exemplu, imapsync păstrează explicit INTERNALDATE al serverului sursă. Dar headerul Received este adăugat de serverul de destinație, nu de instrumentul de migrare. Instrumentul de migrare nu are niciun control asupra acestui comportament. Chiar și cu o păstrare perfectă a INTERNALDATE, cel mai recent header Received conține tot data migrării, iar clienți precum Outlook continuă să afișeze data greșită.

Așadar, ce se poate face în realitate?

Ce instrumente de migrare adaugă headere Received

Orice instrument de migrare IMAP cauzează această problemă, pentru că headerul Received este adăugat de serverul de destinație, nu de instrumentul de migrare în sine. Conținutul headerului adăugat variază însă în funcție de instrument și de server.

BitTitan MigrationWiz adaugă un header Received care conține „mx.migrationwiz.com". CloudM Migrate adaugă headere care fac referire la „cloudm.io". imapsync declanșează un header Received generic din partea serverului de destinație. GSMMO adaugă headere cu referințe la „gmailapi.google.com".

Soluția: restaurarea datelor corecte

Vestea bună este că informația de dată corectă există în continuare în interiorul fiecărui email. Headerul Date original este intact. Headerele Received originale sunt intacte. Problema este că un header contaminant se află peste ele.

Motorul de corecție proprietar al Redate.io analizează lanțul complet de headere al fiecărui email afectat, identificând anomaliile de dată din structura mesajului pentru a determina exact ce headere necesită corectare, indiferent de instrumentul de migrare folosit. Pipelinul de analiză în mai multe etape gestionează cazurile limită care blochează abordările mai simple: mesaje semnate S/MIME, conținut criptat PGP, structuri multipart/alternative, probleme de Content-Transfer-Encoding, headere non-ASCII (RFC 2047), atașamente de dimensiuni mari și limite MIME corupte.

După corectare, fiecare email trece printr-un proces de verificare a integrității, pentru a confirma că structura, conținutul și atașamentele mesajului sunt păstrate identic. Originalele sunt mutate într-un folder de backup vizibil în cutia poștală și rămân acolo până când clientul le elimină.

S-ar putea scrie un script pentru a încerca această corecție de unul singur? Tehnic, da. Dar diferența dintre „funcționează pe 95% dintre emailuri" și „funcționează pe 100% dintre emailuri, fără să corupă vreunul singur" reprezintă luni de muncă de inginerie. Și când vorbim despre întreaga căsuță de email a unei persoane, un procent de eșec de 5% înseamnă sute de mesaje deteriorate în tăcere, fără nicio modalitate de a verifica ce a decurs greșit.

Vreți să vedeți câte emailuri din căsuța dumneavoastră au date greșite? Rulați o analiză gratuită cu Redate.io pentru a obține instantaneu numărul de emailuri afectate, fără plată necesară.