Takeout mbox imports: visi e-pasti ar šodienas datumu

Jūs atvērāt Google Takeout arhīvu, importējāt mbox failu programmā Thunderbird ar ImportExportTools NG (vai programmā Apple Mail), pēc tam pavilkāt mapes uz jauno IMAP kontu. Klientā e-pasti bija sakārtoti pa gadiem. Mērķa kontā visi ir ar šodienas datumu. Šajā rakstā izskaidrots, kas notiek ar importētu Takeout mbox, kāpēc redzamais datums ir kopēšanas datums, kā to apstiprināt dažās minūtēs un kā labot serverī.

Pirmkārt: jūsu e-pasti ir neskarti. Sākotnējais datums joprojām ir ziņojumā. Vienkārši mērķa konts to vairs neizvirza priekšplānā.

Tipisks importēta Takeout mbox scenārijs

Jūs tikko slēdzāt personisko Gmail kontu, kas bija atvērts pirms piecpadsmit gadiem. Pieprasījāt eksportu vietnē takeout.google.com, gaidījāt Google ziņojumu (lielai pastkastītei tās ir divas dienas), lejupielādējāt četrus zip arhīvus. Katrā ir pa .mbox failam katrai iezīmei. Importējat tos programmā Thunderbird: lokālā mape piepildās, kārtošana pēc datuma ir kārtībā, 2009. gads pašā apakšā, vakardiena pašā augšā.

Tad jūs darāt to, ko darītu ikviens. Atlasāt mapes un velkat tās uz mērķa IMAP kontu, ar Microsoft 365, hostinga sniedzēju vai Google Workspace. Pārsūtīšana aizņem visu vakaru. Pirmdienas rītā atverat tīmekļa pastu.

Problēma? Visi 18 400 e-pasti ir datēti ar nedēļas nogali, dažu stundu diapazonā. 2014. gada līgums nonāk blakus pagājušās nedēļas jaunumu vēstulei, un hronoloģiskā secībā vairs nekas nav atrodams.

Šis gadījums ir ļoti tuvs tam, kas aprakstīts rakstā par vecajiem e-pastiem ar vienādu datumu, taču ar vienu lielu atšķirību: šeit neviens migrācijas rīks nav vainojams. Pietiek ar vilkšanu un nomešanu.

Trīs datumi vienā e-pastā

Lai to saprastu, jāpārstāj runāt par vienu e-pasta datumu. Ziņojums, kas importēts no mbox faila, nes vismaz trīs datumus, un tie kalpo dažādiem mērķiem.

Galvene Date: sūtītāja datums

Tā ir galvene Date:, ko definē RFC 2822 (to pārņem RFC 5322). Sūtītāja klients to ieraksta nosūtīšanas brīdī, piemēram, Date: Tue, 14 Mar 2017 09:12:45 +0100. Tā ir ziņojuma daļa, ceļo līdzi tam, un Takeout to saglabā nemainītu. Tieši tāpēc labošana ir iespējama: galvene paliek neskarta.

mbox faila rindiņa From: fasādes datums

mbox failā katram ziņojumam priekšā ir rindiņa, kas sākas ar From (ar atstarpi, bez kola). Tā nav galvene, bet faila formāta atdalītājs, kas nav ziņojuma daļa. Neviens nopietns rīks nedrīkstētu uz to paļauties, datējot e-pastu.

INTERNALDATE: ievietošanas datums serverī

Trešais datums, vismazāk pamanāmais: INTERNALDATE, ko definē RFC 3501. Tas ir atribūts, ko IMAP serveris glabā blakus ziņojumam (nevis tā iekšpusē) un kas atbilst brīdim, kad ziņojums ievietots pastkastītē. Outlook, tīmekļa pasts un tālruņi to izmanto, lai attēlotu un kārtotu saņemšanas datumu. Par mehānismu sīkāk stāstīts rakstā par INTERNALDATE un nepareiziem datumiem IMAP.

Precizējums par galvenēm Received:, ko šeit bieži vaino nepamatoti. Eksportēta Gmail e-pasta rindas Received stāsta par ziņojuma īsto ceļu 2017. gadā: tajās ir vecie, likumīgie datumi. Šajā gadījumā nepareizais datums tātad dzīvo nevis ziņojumā, bet metadatos, ko serveris piešķir kopijai.

Kāpēc mērķa konts rāda kopēšanas datumu

Kad klients ievieto ziņojumu IMAP serverī, tas izmanto komandu APPEND. Šī komanda pēc izvēles pieņem datumu, ko piešķirt ziņojumam. Ja klients to norāda, serveris to saglabā kā INTERNALDATE. Ja nenorāda, serveris piemēro RFC 3501 paredzēto noteikumu: kārtējo datumu un laiku. Citiem vārdiem, redzamais datums ir atkarīgs no tā, kā rīks ierakstīja e-pastu. Rīks, kas nenodod sākotnējo datumu, iegūst kopēšanas datumu.

Rezultāts: kamēr velkat mapes, katrs ziņojums iegūst sava paša ievietošanas datumu. Mape ar 3000 e-pastiem, kas nokopēta 40 minūtēs, ietilpst 40 minūšu logā.

Bet kā tad ar Thunderbird lokālo mapi? Tā šķita ideāla, jo Thunderbird tur kārto pēc galvenes Date, nevis pēc servera datuma (lokālajai mapei servera nav). Apple Mail ar importētajām pastkastītēm uzvedas līdzīgi: kamēr ziņojumi paliek Mac datorā, viss šķiet kārtībā. Patiesība atklājas brīdī, kad IMAP pastkastīti nolasa cita programma, piemēram, Outlook.

Patiesībā nav gluži precīzi teikt, ka visi klienti kļūdās katru reizi. Dažas versijas datumu nodod, citas ne, un uzvedība ir mainījusies līdz ar atjauninājumiem. Tāpēc divi kolēģi, kas seko vienai un tai pašai metodei, var iegūt atšķirīgus rezultātus, un diagnostika kļūst mulsinošāka, nekā šķiet.

Vilkšana un nomešana nav migrācija. Tā ir kopēšana, un kopija nes savas izgatavošanas datumu.

Kā atpazīt šo gadījumu piecās minūtēs

Pirms meklējat risinājumu, pārliecinieties, ka esat tieši šajā scenārijā, nevis kādā citā. Pietiek ar četrām pārbaudēm.

• Salīdziniet abas vietas. Thunderbird lokālā mape (vai Apple Mail importētā pastkastīte) rāda pareizus datumus, bet IMAP konts tiem pašiem ziņojumiem rāda nesenus datumus.
• Paskatieties uz diapazonu. IMAP konta mapē saņemšanas datumi ietilpst dažās stundās, pat dažās minūtēs ap brīdi, kad pārvietojāt mapes.
• Atveriet ziņojuma avotu. Programmā Thunderbird: Skats, pēc tam Ziņojuma avots; programmā Outlook galvenes parāda ziņojuma rekvizīti. Tur jāatrod sena rinda Date:, kamēr displejā redzams nesens datums.
• Pārbaudiet secību. Ziņojumi parādās tādā secībā, kādā klients tos kopēja, nevis hronoloģiskā secībā.

Lūk, ko rāda salīdzinājums ar reālu ziņojumu:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (ziņojumā, neskarts)
IMAP kontā redzamais datums: kopēšanas diena   (servera metadati)

Ja šīs divas rindas stāsta atšķirīgus stāstus, jūs esat īstajā vietā. Bet, ja redzamie datumi ir nepareizi un arī Date: ir nepareizs, tā ir cita, retāka problēma, kas šī raksta tēmai nepieder.

(Starp citu, ja neesat nekad lasījis e-pasta neapstrādātās galvenes, sagatavojiet kafiju: tā nav tieši pludmales lasāmviela.)

Kārtošana pēc nosūtīšanas datuma: tikai plāksteris

Pirmais impulss ir pārslēgt kārtošanu uz nosūtīšanas datumu. Programmā Outlook tas darbojas aptuveni, ja to atkārtojat katrā mapē un katrā ierīcē. Taču meklēšana, paziņojumi, uz vecumu balstīti noteikumi un skati mobilajā ierīcē turpina izmantot saņemšanas datumu. Lietotājs, kas telefonā meklē pagājušā septembra vēstuli, neredzēs neko loģisku.

Vēl viens vilinošs ceļš: kopēt no jauna. Kontā, kas jau tiek lietots, tas galvenokārt rada dublikātus blakus jau esošajiem ziņojumiem, ar tiem pašiem nepareizajiem datumiem vai citiem. Kādu simtu mapju vēlāk jums vairs nav neviena tīra pastkastīte.

Labošana serverī

Labā ziņa: sākotnējais datums joprojām ir. Labošanas mērķis ir panākt, lai mērķa konts to rāda, neskarot ziņojumu saturu.

Tā rīkojas Redate. Pakalpojums pieslēdzas pastkastītei (Google Workspace ar domēna deleģēšanu, Microsoft 365, Outlook.com un Hotmail ar katras personas Microsoft kontu vai tiešs IMAP ar adresi un paroli). Tam nav jāzina, kurš rīks izraisījis problēmu: tas atrod e-pastus, kuru redzamais datums neatbilst sākotnējam datumam, vienalga, vai cēlonis ir vilkšana no Takeout mbox vai kaut kas cits. Pastkastītes skenēšana ir bez maksas un parāda apjomu pirms jebkāda lēmuma.

Pašai labošanai Redate izmanto paša izstrādātu labošanas dzinēju, daudzpakāpju analīzes cauruli, kas izvērtē katra ziņojuma galveņu ķēdi un katram e-pastam atjauno sākotnējo datumu. Katrs labotais e-pasts pēc tam tiek pārbaudīts atsevišķi, ar RFC atbilstības validāciju un ziņojuma struktūras saglabāšanu. Sākotnējie e-pasti netiek dzēsti: tie paliek redzamā mapē jūsu pastkastītē, līdz paši tos izdzēsīsiet.

Kāpēc pašrocīga labošana ir riskanta

Saprast problēmu ir viena lieta. Izlabot 15 000 e-pastu, nezaudējot nevienu, ir pavisam cita.

Skripts, kas darbojas ar desmit testa ziņojumiem, neizturēs 30 000 ziņojumu produkcijas pastkastīti. Tas uzdurs S/MIME parakstītiem e-pastiem, kuros mazākā izmaiņa sabojā parakstu. PGP šifrētiem ziņojumiem. Ligzdotām multipart/alternative struktūrām, pretrunīgām MIME robežām, negaidītiem Content-Transfer-Encoding, ne-ASCII galvenēm, kas kodētas pēc RFC 2047, 40 MB pielikumiem. Pēc tam seko API kvotas, kļūda 429 Too Many Requests plkst. 3:00 naktī paketes vidū, tīkla taimauti, kas pārtrauc operāciju pie 11 874. ziņojuma.

Un tad? Kā uzzināt, ka katrs ziņojums ir vesels? Bez atgriešanas mehānisma kļūda atstāj dublētus ziņojumus, zaudētus pielikumus, saplēstus sarunu pavedienus, pazudušas iezīmes. Redate katru e-pastu pārbauda automātiski un tur sākotnējo eksemplāru pa rokai, tieši tāpēc, lai jums nekad nebūtu jāriskē.

Vēl viens padoms, bez maksas: saglabājiet sākotnējos Takeout arhīvus, kamēr pastkastīte nav apstiprināta. mbox fails paliek atsauces kopija pat tad, ja mērķa konts izskatās pareizs.

Pamācības jūsu klientam

Atkarībā no klienta, ar kuru veicāt kopēšanu, šīs pamācības apraksta konkrēto gadījumu: manuālās IMAP kopēšanas datumu labošana programmā Thunderbird un tas pats gadījums programmā Apple Mail.

Takeout jau nokopēts IMAP kontā, un datumi ir nepareizi? Palaidiet bezmaksas pastkastītes skenēšanu, lai redzētu, cik e-pastu problēma skar, un pēc tam izlabojiet tos ar vienreizēju maksājumu, bez pastkastītes izmēra ierobežojuma.