Outlook: dată primită IMAP vs dată trimisă după migrare

Simptomul pe care toată lumea îl cunoaște

Tocmai ați terminat o migrare IMAP spre Microsoft 365 sau Google Workspace. Luni dimineața, tichetele încep să curgă: "Toate emailurile mele au aceeași dată", "Istoricul meu e distrus", "Nu mai găsesc nimic în căsuța mea". Deschideți Outlook și, într-adevăr, mii de emailuri afișează data weekendului trecut. Nu data la care au fost trimise. Data la care a avut loc migrarea.

Nu e un bug Outlook. Este o consecință directă a modului în care funcționează protocolul IMAP și instrumentele de migrare. Dar pentru a înțelege de ce, trebuie să deschidem capota.

Trei date într-un singur email

Un email este mai complex decât pare. Antet, corpul mesajului, atașamente... și mai multe marcaje temporale distincte care coexistă. (De altfel, dacă ați încercat vreodată să citiți anteturile brute ale unui email, știți că nu e tocmai lectură de plajă.)

Antetul Date: (RFC 2822)

Este data pe care expeditorul a introdus-o în mesaj la momentul trimiterii. Definit de RFC 2822, arată cam așa:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Acest antet este gravat în conținutul mesajului. Nu se schimbă niciodată, cu excepția cazului în care cineva modifică conținutul brut al mesajului. Aceasta este "data trimisă" în sens strict.

Antetul Received: (adăugat la fiecare salt de rețea)

Fiecare server care atinge un email în tranzit adaugă un antet Received: la începutul mesajului, cu propria dată. Un email care trece prin trei servere acumulează deci trei anteturi Received:. Cel mai recent este întotdeauna primul. Arată cam așa:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Rezultatul: când un instrument de migrare precum BitTitan MigrationWiz, CloudM, imapsync sau GSMMO mută un email de pe un server sursă pe un server destinație, se comportă și el ca un "salt de rețea". Injectează un nou antet Received: în vârful stivei, cu data și ora migrării.

INTERNALDATE IMAP

Este a treia dată și aceasta este cea care creează probleme. INTERNALDATE este o metadată stocată pe serverul IMAP, independentă de conținutul mesajului. Reprezintă data la care emailul a fost livrat (sau inserat) în căsuța de mail. Când un instrument de migrare inserează un email, el este cel care alege ce valoare să dea INTERNALDATE. Și în multe cazuri, instrumentele folosesc data momentului migrării. Nu data originală.

Aici se blochează totul.

De ce Outlook afișează data migrării

Outlook folosește INTERNALDATE pentru a afișa coloana "Primit". Acesta este comportamentul implicit, consistent cu specificația IMAP: INTERNALDATE ar trebui să reprezinte data primirii în căsuță. Într-un flux normal (un email real care sosește), INTERNALDATE este apropiată de data din antetul Date:. Cele două sunt coerente.

După o migrare ratată, INTERNALDATE a tuturor emailurilor importate indică noaptea de 14 spre 15 iunie 2024 (sau orice altă dată a migrării). Outlook citește această valoare, o afișează în coloana "Primit", iar rezultatul este catastrofal: 45.000 de emailuri par să fi fost primite în aceeași seară.

Ca să fiu precis, primul antet Received: (cel mai recent din stivă) influențează și el afișarea în anumite configurații. Dar INTERNALDATE rămâne determinantul principal pentru coloana "Primit" din Outlook în modul IMAP sincronizat.

Soluția de avarie "Adaugă coloana Trimis" în Outlook

Primul lucru pe care îl fac majoritatea administratorilor IT când descoperă problema este să caute o soluție de avarie pe partea clientului. Și există una, efectiv.

În Outlook, se poate modifica afișarea coloanelor unui dosar pentru a înlocui (sau completa) coloana "Primit" cu coloana "Dată" sau "Trimis". Coloana "Dată" citește direct antetul Date: al mesajului, nu INTERNALDATE. Deoarece antetul Date: nu a fost atins de migrare, datele originale reapar.

Cum se face în Outlook (desktop, versiunea Microsoft 365): clic dreapta pe antetul coloanei în lista mesajelor, "Setări afișare", apoi modificați coloanele pentru a elimina "Primit" și a adăuga "Dată". Se poate face prin GPO pentru o implementare în masă.

Bine. Pe hârtie, rezolvă problema vizuală. În practică, e un plasture pe o arteră.

Limitele concrete ale acestei soluții de avarie

Clienții mobili și web

Outlook pe iOS, Android și Outlook Web App (OWA) nu au aceleași opțiuni de personalizare. Modificarea de vizualizare pe care ați implementat-o pe stațiile Windows nu se propagă. Utilizatorii care își verifică emailurile pe telefon continuă să vadă data migrării. Iar într-o companie de dimensiuni medii, asta înseamnă probabil jumătate din utilizatori.

Căutarea

Căutarea Outlook folosește indexul Windows Search (sau indexul Exchange/Microsoft 365 pe partea serverului). Acest index este construit pe baza INTERNALDATE, nu a antetului Date:. Dacă un utilizator caută "emailuri din ianuarie 2022", căutarea returnează emailurile al căror INTERNALDATE este în ianuarie 2022. Nu cele al căror antet Date: este în ianuarie 2022. Rezultatul: emailurile vechi nu mai apar în filtrele de dată. Schimbarea coloanei de afișare nu schimbă nimic în privința asta.

Regulile de mesagerie

Regulile Outlook ("dacă emailul a fost primit înainte de...", "dacă emailul a fost primit după...") folosesc și ele INTERNALDATE. O regulă de sortare sau arhivare bazată pe intervale de date nu va mai funcționa corect după migrare dacă INTERNALDATE nu a fost corectată.

Conformitate și eDiscovery

Acesta este poate punctul cel mai serios. Instrumentele de conformitate, arhivare legală și eDiscovery (Microsoft Purview, de exemplu) folosesc INTERNALDATE ca referință de dată pentru solicitările legale. Dacă organizația dumneavoastră face obiectul unor obligații de retenție sau trebuie să răspundă unor cereri de discovery, INTERNALDATE corupte pot crea probleme juridice reale. Un audit care solicită "toate emailurile între cutare și cutare dată" nu va returna rezultatele corecte.

Instrumentele terțe

CRM-uri, instrumente de ticketing, arhivatoare... orice se conectează la serverul de mail prin IMAP sau API-urile Microsoft 365/Google Workspace citește INTERNALDATE. Schimbarea vizualizării din Outlook nu corectează nimic pentru aceste sisteme.

Singura soluție reală: corectarea la nivelul serverului

Sortarea după data trimisă în Outlook nu este o soluție. Este un plasture. Corecția reală trebuie să se facă la nivelul metadatelor serverului, nu al vizualizării din client.

Concret, asta înseamnă corectarea INTERNALDATE a fiecărui email pentru a corespunde datei originale din antetul Date:. Antetul Date: original este întotdeauna prezent în mesaj (nu a fost șters de migrare), ceea ce face posibilă corecția. Acolo se află informația reală de dată.

Pe Google Workspace, API-ul Gmail expune un parametru internalDate care permite acțiunea directă asupra acestei metadate. Pe Microsoft 365, mecanismul este diferit, dar rezultatul așteptat este același. Pe un server IMAP standard, norma prevede că data poate fi specificată la inserarea unui mesaj.

În practică, realizarea acestei operațiuni pe zeci de mii de emailuri în producție, fără pierdere de date, fără duplicate, fără a strica firele de discuție sau labelurile, gestionând cazurile limită (mesaje semnate S/MIME, structuri MIME complexe, codificări non-ASCII conform RFC 2047, atașamente voluminoase)... este cu totul altceva. Un script care funcționează pe 50 de emailuri de test nu va rezista pe o căsuță de 40.000 de mesaje. Gestionarea erorilor 429 (cota API depășită), a timeout-urilor de rețea la 2 noaptea, a mesajelor a căror structură MIME este deja parțial coruptă după migrare... toate acestea necesită o inginerie serioasă.

Exact asta face Redate.io. Motorul de corecție proprietar analizează lanțul de anteturi al fiecărui email, identifică data originală fiabilă și aplică o corecție țintită a metadatelor fără a atinge conținutul mesajului. Fiecare email corectat este verificat individual. Originalele sunt păstrate într-un dosar de rezervă timp de 30 de zile, ceea ce asigură posibilitatea unui rollback în orice moment. Ceva pe care un script improvizat nu îl oferă niciodată.

Identificarea instrumentului de migrare responsabil

Problema se manifestă la fel indiferent de originea migrării, dar detaliile variază în funcție de instrumentul utilizat. BitTitan MigrationWiz, CloudM, imapsync și GSMMO au fiecare propria semnătură în anteturile Received: pe care le injectează. Pipeline-ul de analiză al Redate.io menține o bază de corespondență pentru sute de semnături ale instrumentelor de migrare cunoscute, pentru a distinge antetul de migrare de restul lanțului de tranzit legitim.

Dacă nu știți ce instrument a fost folosit pentru migrarea dumneavoastră (se întâmplă, mai ales când preluați un parc după alt MSP), scanarea gratuită Redate.io identifică căsuțele afectate și oferă o estimare a volumului de corectat înainte de orice angajament.

Pentru contexte specifice, sunt disponibile ghiduri detaliate: corectarea datelor imapsync în Outlook, corectarea datelor BitTitan în Outlook sau corectarea datelor CloudM în Outlook.

Ce faceți acum

Dacă citiți acest articol după o migrare, vestea bună este că antetul Date: original este intact în fiecare email al dumneavoastră. Informațiile de dată reală sunt acolo, prezente în fiecare mesaj. Problema se află în metadate, nu în conținut. Iar metadatele se pot corecta.

Puteți consulta și articolul IMAP INTERNALDATE: de ce se strică datele pentru a aprofunda mecanica problemei, sau ghidul complet despre datele greșite din Outlook după migrare dacă doriți o imagine de ansamblu a cazurilor posibile.

Gata să corectați datele din căsuțele dumneavoastră de mail? Lansați o scanare gratuită pe Redate.io pentru a identifica emailurile afectate și a estima volumul înainte de orice corecție.