Takeout mbox importat: e-mailuri cu data de azi

Ați deschis arhiva Google Takeout, ați importat fișierul mbox în Thunderbird cu ImportExportTools NG (sau în Apple Mail), apoi ați tras folderele spre noul cont IMAP. În client, e-mailurile erau aranjate an de an. În contul de destinație, toate au data de azi. Articolul explică ce se întâmplă cu un Takeout mbox importat, de ce data afișată este cea a copierii, cum puteți confirma în câteva minute și cum se corectează pe partea de server.

Primul lucru de știut: e-mailurile dumneavoastră nu sunt stricate. Data originală se află în continuare în mesaj. Pur și simplu nu mai este cea pe care contul de destinație o pune în față.

Scenariul tipic al unui Takeout mbox importat

Tocmai ați închis un cont Gmail personal, deschis acum cincisprezece ani. Ați cerut exportul pe takeout.google.com, ați așteptat mesajul de la Google (două zile pentru o căsuță mare), ați descărcat patru arhive zip. În fiecare, câte un fișier .mbox pentru fiecare etichetă. Le importați în Thunderbird: folderul local se umple, sortarea după dată e impecabilă, 2009 jos de tot, ieri sus de tot.

Faceți atunci ce ar face oricine. Selectați folderele și le trageți spre contul IMAP de destinație, un Microsoft 365, o găzduire oarecare sau un Google Workspace. Transferul durează o seară întreagă. Luni dimineață, deschideți webmailul.

Problema? Cele 18.400 de e-mailuri au toate data weekendului, într-un interval de câteva ore. Un contract din 2014 stă lângă un newsletter din săptămâna trecută, iar nimeni nu mai găsește nimic în ordine cronoligică.

Cazul seamănă mult cu cel al e-mailurilor vechi care au toate aceeași dată, cu o diferență mare: aici niciun instrument de migrare nu e de vină. Glisarea folderelor e de ajuns.

Trei repere de timp într-un singur e-mail

Ca să înțelegeți, trebuie să încetați să vorbiți despre data unui e-mail ca și cum ar exista una singură. Un mesaj importat dintr-un fișier mbox poartă cel puțin trei repere de timp, iar ele nu servesc aceluiași scop.

Antetul Date: data expeditorului

Este antetul Date: definit de RFC 2822 (preluat de RFC 5322). Clientul expeditorului îl scrie în momentul trimiterii, de exemplu Date: Tue, 14 Mar 2017 09:12:45 +0100. Face parte din mesaj, călătorește odată cu el, iar Takeout îl păstrează neschimbat. Tocmai el face corectarea posibilă, fiindcă rămâne intact.

Linia From din fișierul mbox: o dată de fațadă

Într-un fișier mbox, fiecare mesaj este precedat de o linie care începe cu From (cu un spațiu, fără două puncte). Nu e un antet: este un separator propriu formatului de fișier, care nu face parte din mesaj. Niciun instrument serios nu ar trebui să se bazeze pe ea ca să dateze un e-mail.

INTERNALDATE: data depunerii pe server

A treia, și cea mai discretă: INTERNALDATE, definită de RFC 3501. Este un atribut pe care serverul IMAP îl stochează lângă mesaj (nu în el) și care corespunde momentului în care mesajul a fost depus în căsuță. Outlook, webmailurile și telefoanele îl folosesc pentru a afișa și a sorta data primirii. Pentru detalii, articolul despre INTERNALDATE și problemele de dată în IMAP merge mai departe.

O precizare despre antetele Received:, adesea acuzate pe nedrept aici. Liniile Received ale unui e-mail Gmail exportat povestesc traseul real al mesajului din 2017: poartă repere vechi și legitime. În cazul de față, data greșită nu trăiește deci în mesaj, ci în metadatele pe care serverul le atribuie copiei.

De ce contul de destinație afișează data copierii

Când un client depune un mesaj pe un server IMAP, folosește comanda APPEND. Comanda acceptă, opțional, o dată de atribuit mesajului. Dacă clientul o furnizează, serverul o reține ca INTERNALDATE. Altfel, serverul aplică regula din RFC 3501: data și ora momentului. Cu alte cuvinte, data afișată depinde de felul în care instrumentul a scris e-mailul. Un instrument care nu transmite data originală primește data copierii.

Rezultat: cât timp glisați folderele, fiecare mesaj primește data propriei depuneri. Un folder de 3.000 de e-mailuri copiat în 40 de minute încape într-o fereastră de 40 de minute.

Și folderul local din Thunderbird, atunci? Părea perfect pentru că Thunderbird sortează acolo după antetul Date, nu după o dată de server, fiindcă un folder local nu are server. Comportamentul Apple Mail cu căsuțele importate este comparabil: totul merge bine cât timp mesajele rămân pe Mac. Adevărul iese la iveală în clipa în care un alt program, Outlook de exemplu, citește căsuța IMAP.

De fapt, nu e chiar exact să spunem că toți clienții greșesc de fiecare dată. Unele versiuni transmit data, altele nu, iar comportamentul s-a schimbat de-a lungul actualizărilor. Așa că doi colegi care urmează aceeași metodă pot ajunge la rezultate diferite, ceea ce face diagnosticul mai derutant decât pare la prima vedere.

Glisarea folderelor nu e o migrare. E o copie, iar o copie poartă data fabricării ei.

Cum recunoașteți cazul în cinci minute

Înainte să căutați o soluție, confirmați că vă aflați în acest scenariu și nu în altul. Patru verificări sunt de ajuns.

• Comparați cele două locuri. Folderul local din Thunderbird (sau căsuța importată în Apple Mail) afișează data corectă, iar contul IMAP o dată recentă pentru aceleași mesaje.
• Priviți intervalul. Într-un folder al contului IMAP, data primirii se înscrie în câteva ore, uneori în câteva minute, în jurul momentului în care ați mutat folderele.
• Deschideți sursa unui mesaj. În Thunderbird, Vizualizare, apoi Sursa mesajului; în Outlook, proprietățile mesajului arată antetele. Trebuie să găsiți acolo o linie Date: veche, în timp ce afișajul indică o dată recentă.
• Verificați ordinea. Mesajele apar în ordinea în care clientul le-a copiat, nu în ordine cronologică.

Iată ce dă comparația pe un mesaj real:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (în mesaj, intact)
Data afișată de contul IMAP: ziua copierii     (metadată a serverului)

Dacă cele două linii nu spun aceeași poveste, ați identificat cazul. Iar dacă data afișată e greșită, dar și Date: e greșit, e o altă problemă, mai rară, care nu ține de acest articol.

(Apropo, dacă nu ați citit niciodată antetele brute ale unui e-mail, luați o cafea: nu e tocmai lectură de plajă.)

Sortarea după data trimiterii: un plasture

Reflexul este să treceți sortarea pe data trimiterii. În Outlook merge cât de cât, cu condiția s-o refaceți pe fiecare folder și pe fiecare dispozitiv. Dar căutarea, notificările, regulile bazate pe vechime și vizualizările de pe mobil continuă să folosească data primirii. Un utilizator care caută e-mailul din septembrie trecut pe telefon nu va vedea nimic logic.

Altă pistă tentantă: reluarea copierii. Pe un cont deja folosit, produce mai ales dubluri lângă mesajele existente, cu aceeași dată greșită sau cu alta. După vreo sută de foldere, nu mai aveți nicio căsuță curată.

Corectarea pe partea de server

Vestea bună este că data originală se află în continuare acolo. Corectarea înseamnă ca![contul de destinație să o afișeze, fără a atinge conținutul mesajelor dumneavoastră.

Asta face Redate. Serviciul se conectează la căsuța de e-mail (Google Workspace prin delegare la nivel de domeniu, Microsoft 365, Outlook.com și Hotmail cu contul Microsoft al fiecărei persoane, sau IMAP direct cu adresa și parola). Redate nu are nevoie să știe ce instrument a produs problema: găsește e-mailurile a căror dată afișată nu corespunde datei lor originale, fie că vine dintr-o glisare a unui Takeout mbox, fie din altceva. Scanarea gratuită vă arată amploarea problemei înainte de orice decizie.

Pentru corectarea propriu-zisă, Redate se bazează pe un motor de corectare propriu, un pipeline de analiză în mai multe etape care examinează lanțul de antete al fiecărui mesaj și redă fiecărui e-mail data originală. Fiecare e-mail corectat este apoi verificat individual, cu validarea conformității RFC și păstrarea structurii mesajului. Originalele nu sunt șterse niciodată: rămân într-un folder vizibil din căsuța dumneavoastră până când le ștergeți chiar dumneavoastră.

De ce e riscant să improvizați singur

A înțelege problema este un lucru. A corecta 15.000 de e-mailuri fără a pierde vreunul este cu totul altceva.

Un script care merge pe zece mesaje de test nu supraviețuiește unei căsuțe de producție cu 30.000 de mesaje. Dă peste e-mailuri S/MIME semnate, la care cea mai mică modificare strică semnătura. Mesaje PGP criptate. Structuri multipart/alternative imbricate, limite MIME incoerente, Content-Transfer-Encoding neașteptate, antete non-ASCII codate conform RFC 2047, atașamente de 40 MB. Apoi urmează cotele de API, eroarea 429 Too Many Requests la 3 dimineața, în plin batch, și întreruperile de rețea care opresc operațiunea la mesajul 11.874.

Și după aceea? Cum aflați că fiecare mesaj e intact? Fără posibilitate de revenire, o greșeală lasă mesaje duplicate, atașamente pierdute, conversații rupte, etichete dispărute. Redate verifică automat fiecare e-mail și păstrează originalul la îndemână, tocmai ca să nu fie nevoie să pariați pe asta.

Un ultim sfat, gratuit: păstrați arhivele Takeout originale cât timp căsuța nu este validată. Fișierul mbox rămâne copia de referință, chiar și atunci când contul de destinație pare în ordine.

Ghiduri legate de clientul dumneavoastră

În funcție de clientul folosit pentru copiere, ghidurile detaliate de mai jos descriu cazul exact: corectarea datei după o copie IMAP făcută în Thunderbird și același caz în Apple Mail.

Takeout-ul dumneavoastră este deja copiat pe contul IMAP, iar data e greșită? Porniți scanarea gratuită Redate ca să vedeți câte e-mailuri sunt afectate, apoi corectați-le cu o plată unică, fără limită de mărime a căsuței.