Uvožen Takeout mbox: vsa e-pošta z današnjim datumom

Odprli ste arhiv Google Takeout, datoteko mbox uvozili v Thunderbird z dodatkom ImportExportTools NG (ali v Apple Mail), nato pa mape povlekli v svoj novi e-poštni račun IMAP. V odjemalcu so bila sporočila lepo razvrščena po letih. V ciljnem računu imajo zdaj vsa današnji datum. Ta članek pojasnjuje, kaj se zgodi z uvoženim Takeout mbox, zakaj je prikazani datum datum kopiranja, kako to potrdite v nekaj minutah in kako popravek opraviti na strani strežnika.

Prva stvar, ki jo morate vedeti: z vašimi sporočili je vse v redu. Izvirni datum je še vedno v sporočilu. Ciljni račun ga preprosto ne postavlja več v ospredje.

Tipičen scenarij uvoženega Takeout mbox

Pravkar ste zaprli osebni račun Gmail, odprt pred petnajstimi leti. Izvoz ste zahtevali na takeout.google.com, počakali na Googlovo sporočilo (dva dni za velik nabiralnik) in prenesli štiri arhive zip. V vsakem je ena datoteka .mbox na oznako. Uvozite jih v Thunderbird: lokalna mapa se napolni, razvrščanje po datumu je popolno, leto 2009 povsem spodaj, včerajšnji dan povsem zgoraj.

Potem storite to, kar bi storil vsak. Označite mape in jih povlečete v ciljni račun IMAP, bodisi Microsoft 365, pri gostitelju ali Google Workspace. Prenos traja cel večer. V ponedeljek zjutraj odprete spletno pošto.

Težava? Vseh 18.400 sporočil ima datum konca tedna, v razponu nekaj ur. Pogodba iz leta 2014 leži ob novici iz prejšnjega tedna in nihče več ne najde ničesar po kronološkem vrstnem redu.

Primer je zelo podoben starim e-poštnim sporočilom, ki imajo vsa isti datum, z bistveno razliko: tu nobeno orodje za migracijo ni krivo. Povleci in spusti popolnoma zadostuje.

Trije datumi v enem sporočilu

Da bi stvar razumeli, se moramo nehati pogovarjati o datumu e-poštnega sporočila, kot da bi bil samo eden. Sporočilo, uvoženo iz datoteke mbox, jih nosi vsaj tri, in ne služijo istemu namenu.

Glava Date: datum pošiljatelja

To je glava Date:, ki jo določa RFC 2822 (povzema jo RFC 5322). Odjemalec pošiljatelja jo zapiše ob pošiljanju, na primer Date: Tue, 14 Mar 2017 09:12:45 +0100. Je del sporočila, potuje z njim, Takeout pa jo ohrani nespremenjeno. Prav ta omogoča popravek, saj ostaja nedotaknjena.

Vrstica From v datoteki mbox: navidezen datum

V datoteki mbox pred vsakim sporočilom stoji vrstica, ki se začne z From (s presledkom, brez dvopičja). To ni glava: je ločilo, značilno za obliko datoteke, in ni del sporočila. Noben resen program se ne bi smel zanašati nanjo pri datiranju e-pošte.

INTERNALDATE: datum odložitve na strežniku

Tretji datum, najbolj neopazen: INTERNALDATE, opredeljen v RFC 3501. Je atribut, ki ga strežnik IMAP shrani ob sporočilu (ne v njem) in ustreza trenutku, ko je bilo sporočilo odloženo v nabiralnik. Outlook, spletna pošta in telefoni ga uporabljajo za prikaz in razvrščanje datuma prejema. Podrobnosti mehanizma najdete v članku IMAP INTERNALDATE: zakaj se datumi pokvarijo.

Pojasnilo o glavah Received:, ki jih tu pogosto po krivem obtožujejo. Vrstice Received izvoženega sporočila Gmail pripovedujejo pravo pot sporočila leta 2017: nosijo stare, legitimne datume. V tem primeru napačni datum torej ne živi v sporočilu, temveč v metapodatkih, ki jih strežnik dodeli kopiji.

Zakaj ciljni račun prikazuje datum kopiranja

Ko odjemalec odloži sporočilo na strežnik IMAP, uporabi ukaz APPEND. Ta ukaz sprejema neobvezen datum, ki naj ga sporočilo dobi. Če ga odjemalec poda, ga strežnik shrani kot INTERNALDATE. Sicer strežnik uporabi pravilo iz RFC 3501: trenutni datum in čas. Z drugimi besedami, prikazani datum je odvisen od tega, kako je orodje zapisalo sporočilo. Orodje, ki ne posreduje izvirnega datuma, dobi datum kopije.

Rezultat: medtem ko vlečete mape, vsako sporočilo prevzame datum svoje odložitve. Mapa s 3000 sporočili, kopirana 40 minut, pade v 40-minutno okno.

In lokalna mapa v Thunderbirdu? Zdela se je popolna, ker Thunderbird v njej razvršča po glavi Date in ne po datumu strežnika, saj lokalna mapa strežnika nima. Apple Mail z uvoženimi nabiralniki deluje podobno: vse je v redu, dokler sporočila ostanejo na Macu. Resnica pride na dan šele, ko drug program, denimo Outlook, prebere nabiralnik IMAP.

Pravzaprav ni povsem točno reči, da se vsi odjemalci vsakič zmotijo. Nekatere različice datum posredujejo, druge ne, vedenje pa se je skozi posodobitve spreminjalo. Zato lahko dva sodelavca z isto metodo dobita različna rezultata, kar diagnozo naredi bolj zmedeno, kot bi človek pričakoval.

Povleci in spusti ni migracija. Je kopiranje, kopija pa nosi datum svojega nastanka.

Kako prepoznati ta primer v petih minutah

Preden iščete rešitev, potrdite, da ste res v tem scenariju in ne v drugem. Zadostujejo štiri preverjanja.

• Primerjajte obe mesti. Lokalna mapa v Thunderbirdu (ali uvoženi nabiralnik v Apple Mail) kaže prave datume, račun IMAP pa za ista sporočila nedavne.
• Poglejte razpon. V mapi računa IMAP datumi prejema padejo v nekaj ur, včasih celo nekaj minut, okrog trenutka, ko ste premaknili mape.
• Odprite izvor sporočila. V Thunderbirdu Pogled, nato Izvor sporočila; v Outlooku glave prikažejo lastnosti sporočila. Tam morate najti staro vrstico Date:, medtem ko prikaz kaže nedaven datum.
• Preverite vrstni red. Sporočila se pojavijo v vrstnem redu, v katerem jih je odjemalec kopiral, ne v kronološkem.

Takole izgleda primerjava na resničnem sporočilu:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (v sporočilu, nedotaknjen)
Datum, ki ga prikazuje račun IMAP: dan kopiranja   (metapodatek strežnika)

Če ti dve vrstici ne pripovedujeta iste zgodbe, ste na pravem mestu. In če so prikazani datumi napačni, pa je napačen tudi Date:, gre za drug, redkejši problem, ki ni tema tega članka.

(Mimogrede, če še nikoli niste brali surovih glav e-pošte, si privoščite kavo: to ni ravno branje za na plažo.)

Razvrščanje po datumu pošiljanja: le obliž

Prvi refleks je preklop razvrščanja na datum pošiljanja. V Outlooku to približno deluje, če ga ponovite v vsaki mapi in na vsaki napravi. A iskanje, obvestila, pravila, ki temeljijo na starosti, in pogledi na mobilnem telefonu še naprej uporabljajo datum prejema. Uporabnik, ki na telefonu išče sporočilo iz lanskega septembra, ne bo videl nič smiselnega.

Druga zapeljiva pot: ponovno kopiranje. Na že uporabljenem računu to povzroči predvsem dvojnike ob že prisotnih sporočilih, z istimi napačnimi datumi ali drugimi. Sto map kasneje nimate več niti enega čistega nabiralnika.

Popravek na strani strežnika

Dobra novica: izvirni datum je še vedno tam. Popravek pomeni, da ga ciljni račun začne prikazovati, ne da bi se dotaknili vsebine vaših sporočil.

To počne Redate. Storitev se poveže z nabiralnikom (Google Workspace prek delegiranja domene, Microsoft 365, Outlook.com in Hotmail z Microsoftovim računom vsake osebe ali neposredni IMAP z naslovom in geslom). Redate ne potrebuje vedeti, katero orodje je povzročilo škodo: poišče sporočila, katerih prikazani datum se ne ujema z izvirnim datumom, pa naj bo vzrok povleci in spusti iz Takeout mbox ali kaj drugega. Pregled je brezplačen in pokaže obseg težave, preden se karkoli odločite.

Za sam popravek se Redate opira na lasten popravljalni mehanizem, večstopenjski analitični cevovod, ki preuči verigo glav vsakega sporočila in vsakemu vrne njegov izvirni datum. Vsako popravljeno sporočilo se nato posamično preveri, z validacijo skladnosti z RFC in ohranitvijo strukture sporočila. Izvirniki se nikoli ne izbrišejo: ostanejo v vidni mapi vašega nabiralnika, dokler jih ne izbrišete sami.

Zakaj je lastno reševanje tvegano

Razumeti težavo je eno. Popraviti jo na 15.000 sporočilih, ne da bi izgubili enega samega, je drugo.

Skript, ki deluje na desetih testnih sporočilih, ne preživi produkcijskega nabiralnika s 30.000 sporočili. Naleti na podpisana sporočila S/MIME, pri katerih vsaka sprememba podpis uniči. Na šifrirana sporočila PGP. Na ugnezdene strukture multipart/alternative, nedosledne meje MIME, nepričakovane vrednosti Content-Transfer-Encoding, glave z znaki zunaj ASCII, kodirane po RFC 2047, in priponke po 40 MB. Potem pridejo še kvote API, napaka 429 Too Many Requests ob 3. uri zjutraj sredi paketa, omrežni timeouti, ki prekinejo operacijo pri sporočilu 11.874.

In potem? Kako veste, da je vsako sporočilo nedotaknjeno? Brez mehanizma za povrnitev (rollback) napaka pusti podvojena sporočila, izgubljene priponke, pretrgane niti pogovorov, izginule oznake. Redate vsako sporočilo preveri samodejno in ohrani izvirnik pri roki, prav zato, da vam ni treba staviti na srečo.

Še en nasvet, brezplačen: obdržite izvirne arhive Takeout, dokler nabiralnik ni potrjen. Datoteka mbox ostaja referenčna kopija, tudi ko ciljni račun izgleda pravilen.

Vodniki za vaš odjemalec

Glede na odjemalca, ki ste ga uporabili za kopiranje, konkretni primer opisujeta naslednja vodnika: popravek datumov ročnega IMAP kopiranja v Thunderbirdu in isti primer v Apple Mail.

Je vaš Takeout že kopiran v račun IMAP, datumi pa so napačni? Zaženite brezplačni pregled Redate, da vidite, koliko sporočil je prizadetih, nato jih popravite z enkratnim plačilom, brez omejitve velikosti nabiralnika.