Takeout mbox importas: visi el. laiškai su šiandienos data

Atidarėte savo Google Takeout archyvą, importavote mbox failą į Thunderbird su ImportExportTools NG (arba į Apple Mail), o paskui aplankus nuvilkote į naują IMAP paskyrą. Pašto programoje el. laiškai stovėjo tvarkingai, metai po metų. Paskirties paskyroje jie visi turi šiandienos datą. Šiame straipsnyje paaiškinta, kas vyksta su importuotu Takeout mbox, kodėl rodoma kopijos data, kaip tai patvirtinti per kelias minutes ir kaip pataisyti serverio pusėje.

Pirmiausia svarbiausia: jūsų el. laiškai nepažeisti. Pradinė data vis dar yra pačiame laiške. Tiesiog paskirties paskyra jos jau nerodo.

Tipinis importuoto Takeout mbox scenarijus

Ką tik uždarėte asmeninę Gmail paskyrą, kurią buvote susikūrę prieš penkiolika metų. takeout.google.com paprašėte eksporto, laukėte Google pranešimo (didelei pašto dėžutei tai užtrunka porą dienų) ir parsisiuntėte keturis zip archyvus. Kiekviename - po vieną .mbox failą kiekvienai etiketei. Importuojate juos į Thunderbird: vietinis aplankas prisipildo, rikiavimas pagal datą nepriekaištingas, 2009-ieji pačiame apačioje, vakardiena viršuje.

Tada darote tai, ką padarytų visi. Pažymite aplankus ir nuvelkate juos į paskirties IMAP paskyrą - Microsoft 365, kokio nors hostingo ar Google Workspace. Perkėlimas trunka visą vakarą. Pirmadienio rytą atidarote žiniatinklio paštą.

Problema? Visi 18 400 el. laiškų pažymėti savaitgaliu, sutilpusiu į kelių valandų intervalą. 2014 metų sutartis guli šalia praėjusios savaitės naujienlaiškio, ir chronologine tvarka nebeįmanoma rasti nieko.

Atvejis labai panašus į senus laiškus, kurie visi rodo tą pačią datą, tik su vienu esminiu skirtumu: čia jokio migracijos įrankio nebuvo. Užtenka paprasto nuvilkimo pele.

Trys datos viename el. laiške

Kad suprastumėte, reikia liautis kalbėti apie vieną el. laiško datą. Iš mbox failo importuotas laiškas turi bent tris datas, ir jos skirtos skirtingiems dalykams.

Antraštė Date: siuntėjo data

Tai antraštė Date:, apibrėžta RFC 2822 (perimta į RFC 5322). Siuntėjo pašto programa ją įrašo išsiųsdama laišką, pavyzdžiui, Date: Tue, 14 Mar 2017 09:12:45 +0100. Ji yra paties laiško dalis, keliauja kartu su juo, o Takeout ją išsaugo tokią, kokia yra. Būtent todėl taisymas apskritai įmanomas: ši antraštė lieka nepaliesta.

mbox eilutė From: fasadinė data

mbox faile prieš kiekvieną laišką eina eilutė, prasidedanti From (su tarpu, be dvitaškio). Tai ne antraštė, o failo formato skirtukas, kuris nėra laiško dalis. Jokia rimta programa neturėtų remtis ja nustatydama laiško datą.

INTERNALDATE: įdėjimo į serverį data

Trečioji data, pati nepastebimiausia: INTERNALDATE, apibrėžta RFC 3501. Tai atributas, kurį IMAP serveris saugo šalia laiško (ne jo viduje) ir kuris atitinka momentą, kai laiškas buvo įdėtas į pašto dėžutę. Outlook, žiniatinklio paštas ir telefonai pagal ją rodo ir rikiuoja gavimo datą. Apie mechanizmą išsamiau rašoma straipsnyje apie IMAP INTERNALDATE ir klaidingas datas.

Trumpa pastaba apie antraštes Received:, kurias čia dažnai kaltina be pagrindo. Iš Gmail eksportuoto laiško eilutės Received pasakoja tikrąjį 2017 m. laiško kelią: jose yra senos ir teisėtos datos. Taigi šiuo atveju klaidinga data slypi ne laiške, o metaduomenyse, kuriuos serveris priskiria kopijai.

Kodėl paskirties paskyra rodo kopijos datą

Kai pašto programa deda laišką į IMAP serverį, ji naudoja komandą APPEND. Ši komanda gali (bet neprivalo) nurodyti laiškui datą. Jei programa ją perduoda, serveris įsimena ją kaip INTERNALDATE. Jei ne, serveris taiko RFC 3501 numatytą taisyklę: dabartinę datą ir laiką. Kitaip tariant, rodoma data priklauso nuo to, kaip įrankis įrašė laišką. Įrankis, kuris nepaduoda pradinės datos, gauna kopijavimo datą.

Rezultatas: kol tempiate aplankus, kiekvienas laiškas gauna savo paties įdėjimo datą. 3 000 laiškų aplankas, kopijuotas 40 minučių, telpa į 40 minučių langą.

O kaip vietinis Thunderbird aplankas? Jis atrodė puikiai, nes Thunderbird jame rikiuoja pagal antraštę Date, o ne pagal serverio datą - vietinis aplankas serverio neturi. Apple Mail su importuotomis dėžutėmis elgiasi panašiai: kol laiškai lieka Mac kompiuteryje, viskas gerai. Tiesa išlenda tada, kai IMAP dėžutę perskaito kita programa, tarkime, Outlook.

Beje, nėra visiškai tikslu sakyti, kad visos pašto programos klysta kiekvieną kartą. Vienos versijos datą perduoda, kitos ne, o elgsena keitėsi su atnaujinimais. Todėl du kolegos, dirbantys tuo pačiu būdu, gali gauti skirtingus rezultatus, ir diagnozė tampa painesnė, nei atrodo.

Nuvilkimas pele nėra migracija. Tai kopija, o kopija turi pagaminimo datą.

Kaip atpažinti šį atvejį per penkias minutes

Prieš ieškodami sprendimo įsitikinkite, kad tai tikrai šis scenarijus, o ne koks nors kitas. Užtenka keturių patikrų.

• Palyginkite dvi vietas. Vietiniame Thunderbird aplanke (ar Apple Mail importuotoje dėžutėje) datos teisingos, o IMAP paskyroje tie patys laiškai rodo naujas datas.
• Pažiūrėkite į intervalą. IMAP paskyros aplanke gavimo datos telpa į kelias valandas ar net minutes aplink momentą, kai perkėlėte aplankus.
• Atidarykite laiško šaltinį. Thunderbird: Rodymas, tada Laiško šaltinis; Outlook: laiško ypatybėse matysite antraštes. Turėtumėte rasti senos datos eilutę Date:, nors ekrane rodoma nauja data.
• Patikrinkite tvarką. Laiškai išsirikiuoja ta tvarka, kuria juos kopijavo pašto programa, o ne chronologiškai.

Štai kaip atrodo palyginimas su tikru laišku:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (laiške, nepakitusi)
IMAP paskyros rodoma data: kopijavimo diena   (serverio metaduomuo)

Jei šios dvi eilutės pasakoja skirtingas istorijas, jūs jau atpažinote savo atvejį. O jei rodomos datos klaidingos, bet Date: irgi klaidinga, tai jau kita, retesnė problema, kuri į šį straipsnį nepatenka.

(Beje, jei dar niekada neskaitėte neapdorotų el. laiško antraščių, pasiruoškite kavos: tai nėra tiksliai skaitymas paplūdimyje.)

Rikiavimas pagal siuntimo datą: tik pleistras

Pirmas refleksas - perjungti rikiavimą pagal siuntimo datą. Outlook tai daugmaž veikia, jei tai kartojate kiekviename aplanke ir kiekviename įrenginyje. Tačiau paieška, pranešimai, taisyklės pagal laiško amžių ir peržiūros telefone ir toliau naudoja gavimo datą. Kas ieško "praėjusio rugsėjo laiško" telefone, nieko logiško nepamatys. Daugiau apie tai - straipsnyje rikiavimas pagal siuntimo datą nėra sprendimas.

Kitas viliojantis kelias - kopijuoti iš naujo. Jau naudojamoje paskyroje tai daugiausia sukuria dublikatus šalia jau esančių laiškų, su tomis pačiomis klaidingomis datomis ar kitomis. Po kelių dešimčių aplankų nebeturėsite nė vienos tvarkingos pašto dėžutės.

Taisymas serverio pusėje

Gera žinia: pradinė data vis dar yra. Taisymas reiškia, kad paskirties paskyra ją pradės rodyti, nelieičiant jūsų laiškų turinio.

Būtent tai daro Redate. Paslauga prisijungia prie pašto dėžutės (Google Workspace per domeno delegavimą, Microsoft 365, Outlook.com ir Hotmail su kiekvieno asmens Microsoft paskyra arba tiesiogiai per IMAP su adresu ir slaptažodžiu). Redate nereikia žinoti, kuris įrankis sukėlė problemą: jis suranda el. laiškus, kurių rodoma data nesutampa su pradine data, nesvarbu, ar priežastis - nuvilkimas iš Takeout mbox, ar kas nors kita. Pašto dėžutės skenavimas nemokamas ir parodo žalos mastą prieš priimant bet kokį sprendimą.

Pačiam taisymui Redate naudoja savo sukurtą taisymo variklį - daugiapakopę analizės grandinę, kuri išnagrinėja kiekvieno laiško antraščių grandinę ir grąžina jam pradinę datą. Kiekvienas pataisytas el. laiškas paskui tikrinamas atskirai: tikrinamas atitikimas RFC ir išsaugoma laiško struktūra. Originalai niekada netrinami - jie lieka matomame jūsų pašto dėžutės aplanke, kol patys juos ištrinsite.

Kodėl taisyti patiems rizikinga

Suprasti problemą - vienas dalykas. Pataisyti 15 000 el. laiškų nepamestant nė vieno - visai kitas.

Scenarijus, veikiantis su dešimčia bandomųjų laiškų, neišgyvena 30 000 laiškų gamybinėje dėžutėje. Jis susiduria su pasirašytais S/MIME laiškais, kuriuos menkiausias pakeitimas sugadina. Su užšifruotais PGP laiškais. Su įdėtomis multipart/alternative struktūromis, nenuosekliomis MIME ribomis, netikėtais Content-Transfer-Encoding, ne-ASCII antraštėmis, užkoduotomis pagal RFC 2047, 40 MB priedais. Po to prasideda API kvotos, klaida 429 Too Many Requests 3 val. nakties per partijos apdorojimą ir tinklo skirtieji laikai, nutraukiantys operaciją ties 11 874-uoju laišku.

O paskui? Kaip žinoti, kad kiekvienas laiškas sveikas? Be atšaukimo mechanizmo klaida palieka dubliuotus laiškus, dingusius priedus, suirusias susirašinėjimo gijas, išnykusias etiketes. Redate kiekvieną el. laišką patikrina automatiškai ir originalą palaiko po ranka, būtent tam, kad jums niekada nereikėtų statyti ant kortos savo archyvo.

Dar vienas nemokamas patarimas: išsaugokite pradinius Takeout archyvus, kol pašto dėžutė nepatvirtinta kaip tvarkinga. mbox failas lieka pagrindine atskaitos kopija, net kai paskirties paskyra atrodo tvarkinga.

Susiję taisymo vadovai pagal jūsų pašto programą

Priklausomai nuo to, kokia pašto programa buvo naudojama kopijavimui, šie išsamūs vadovai aprašo konkretų atvejį: rankinio IMAP kopijavimo datų taisymas Thunderbird ir tas pats atvejis Apple Mail.

Takeout jau nukopijuotas į IMAP paskyrą, o datos klaidingos? Paleiskite nemokamą Redate skenavimą, kad pamatytumėte, kiek el. laiškų paveikta, o paskui pataisykite juos vienkartiniu mokėjimu, be pašto dėžutės dydžio ribos.