Takeout mbox: kõigi e-kirjade kuupäev on tänane

Olete avanud oma Google Takeouti arhiivi, importinud mbox-faili Thunderbirdi ImportExportTools NG-ga (või Apple Maili) ja lohistanud kaustad seejärel uude IMAP-kontole. Kliendis olid e-kirjad aasta haaval korras. Sihtkontol on need aga kõik tänase kuupäevaga. See artikkel selgitab, mis juhtub imporditud Takeout mbox-iga, miks kuvatakse kopeerimise kuupäev, kuidas seda mõne minutiga kinnitada ja kuidas serveri poolel parandada.

Kõigepealt see: teie e-kirjad ei ole kahjustatud. Algne kuupäev on sõnumis endiselt olemas. Sihtkonto lihtsalt ei too seda enam esile.

Imporditud Takeout mbox-i tüüpiline stsenaarium

Olete just sulgenud viisteist aastat tagasi avatud isikliku Gmaili konto. Tellisite ekspordi aadressil takeout.google.com, ootasite Google'i teadet (suure postkasti puhul kaks päeva) ja laadisite alla neli zip-arhiivi. Igas neist on iga sildi kohta üks .mbox-fail. Impordite need Thunderbirdi: kohalik kaust täitub, kuupäevajärjestus on laitmatu, 2009 päris all ja eilne päris peal.

Seejärel teete seda, mida igaüks teeks. Valite kaustad ja lohistate need sihtkonto IMAP-i, olgu selleks Microsoft 365, veebimajutaja postkast või Google Workspace. Ülekanne kestab terve õhtu. Esmaspäeva hommikul avate veebipostkasti.

Probleem? Kõik 18 400 e-kirja kannavad nädalavahetuse kuupäeva, mahutatuna mõnetunnisesse vahemikku. 2014. aasta leping on nüüd möödunud nädala uudiskirja kõrval ja kronoloogilises järjekorras ei leia keegi enam midagi üles.

Juhtum on väga sarnane olukorraga, kus vanad e-kirjad on kõik sama kuupäevaga, ühe olulise erinevusega: siin ei ole süüdi ükski migratsioonitööriist. Lohistamisest piisab.

Kolm kuupäeva ühes e-kirjas

Et asjast aru saada, tuleb lõpetada rääkimine e-kirja "kuupäevast" ainsuses. Mbox-failist imporditud sõnumil on vähemalt kolm kuupäeva ja need teenivad erinevaid eesmärke.

Date-päis: saatja kuupäev

See on RFC 2822 (hiljem RFC 5322) määratletud päis Date:. Saatja klient kirjutab selle saatmise hetkel, näiteks Date: Tue, 14 Mar 2017 09:12:45 +0100. See kuulub sõnumi juurde, rändab sõnumiga kaasa ja Takeout säilitab selle muutmata kujul. Just see teebki parandamise võimalikuks, sest päis jääb terveks.

Mbox-faili From-rida: kulissikuupäev

Mbox-failis eelneb igale sõnumile rida, mis algab sõnaga From ja tühikuga (ilma koolonita). See ei ole päis: tegemist on failivormingu enda eraldajaga, mis sõnumi osaks ei kuulu. Ükski tõsiseltvõetav tööriist ei tohiks e-kirja dateerimisel sellele toetuda.

INTERNALDATE: serverisse jõudmise kuupäev

Kolmas kuupäev ja kõige märkamatum on INTERNALDATE, mille määratleb RFC 3501. See on atribuut, mida IMAP-server hoiab sõnumi kõrval (mitte selle sees) ja mis vastab hetkele, mil sõnum postkasti pandi. Outlook, veebipostkastid ja telefonid kasutavad seda vastuvõtmise kuupäeva kuvamiseks ja sortimiseks. Mehhanismi üksikasjadest räägib pikemalt artikkel INTERNALDATE ja valed kuupäevad IMAP-is.

Täpsustus päiste Received: kohta, mida siin sageli ekslikult süüdistatakse. Eksporditud Gmaili e-kirja Received-read jutustavad sõnumi tegelikust teekonnast 2017. aastal: neis on vanad ja õiged kuupäevad. Sel juhul ei asu vale kuupäev seega sõnumis, vaid metaandmetes, mille server kopeerimisel omistab.

Miks sihtkonto kuvab kopeerimise kuupäeva

Kui klient paneb sõnumi IMAP-serverisse, kasutab ta käsku APPEND. See käsk võtab soovi korral kaasa kuupäeva, mille sõnumile anda. Kui klient selle edastab, jätab server selle INTERNALDATE-na meelde. Kui mitte, rakendab server RFC 3501 ettenähtud reeglit: hetke kuupäev ja kellaaeg. Teisisõnu sõltub kuvatav kuupäev sellest, kuidas tööriist e-kirja kirjutas. Tööriist, mis algset kuupäeva ei edasta, saab kopeerimise kuupäeva.

Tulemus: kaustade lohistamise ajal saab iga sõnum oma serverisse panemise kuupäeva. 3000 e-kirjaga kaust, mida kopeeritakse 40 minutit, mahub 40-minutilisse aknasse.

Aga Thunderbirdi kohalik kaust? See tundus täiuslik, sest Thunderbird sorteerib seal Date-päise järgi, mitte serveri kuupäeva järgi (kohalikul kaustal ei ole serverit). Apple Maili käitumine imporditud postkastidega on sarnane: kõik on korras seni, kuni sõnumid jäävad Maci. Tõde ilmneb hetkel, kui mõni teine tarkvara, näiteks Outlook, loeb IMAP-postkasti.

Tegelikult ei ole päris täpne öelda, et kõik kliendid eksivad iga kord. Mõned versioonid edastavad kuupäeva, teised mitte, ja käitumine on uuenduste käigus muutunud. Seetõttu võivad kaks kolleegi, kes järgivad sama meetodit, saada erineva tulemuse, mis muudab diagnoosimise segasemaks, kui esmapilgul paistab.

Lohistamine ei ole migratsioon. See on kopeerimine ja koopia kannab oma valmistamise kuupäeva.

Kuidas selle juhtumi viie minutiga ära tunda

Enne lahenduse otsimist veenduge, et tegu on just selle stsenaariumiga, mitte mõne muuga. Piisab neljast kontrollist.

• Võrrelge kahte kohta. Thunderbirdi kohalik kaust (või Apple Maili imporditud postkast) näitab õigeid kuupäevi, IMAP-konto aga samade sõnumite jaoks hiljutisi.
• Vaadake vahemikku. IMAP-konto kaustas mahuvad vastuvõtmise kuupäevad mõne tunni või isegi minuti sisse kaustade teisaldamise hetke ümber.
• Avage sõnumi allikas. Thunderbirdis leiate selle menüüst Vaade, Outlookis annab päised sõnumi atribuutide aken. Peaksite nägema vana Date: rida, kuigi kuvatud kuupäev on hiljutine.
• Kontrollige järjekorda. Sõnumid asuvad selles järjekorras, milles klient neid kopeeris, mitte kronoloogiliselt.

Näide ühe päris sõnumi võrdlusest:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (sõnumis, muutumatu)
IMAP-konto kuvatav kuupäev: kopeerimise päev   (serveri metaandmed)

Kui need kaks rida ei jutusta sama lugu, olete õiges kohas. Ja kui kuvatud kuupäevad on valed, aga Date: on samuti vale, on tegu teise, harvema probleemiga, mis siia artiklisse ei kuulu.

(Muide, kui te pole kunagi e-kirja toorpäiseid lugenud, varuge kohvi: see ei ole päris rannalugemine.)

Saatmiskuupäeva järgi sortimine: ajutine plaaster

Esimene refleks on lülitada sortimine saatmiskuupäevale. Outlookis töötab see enam-vähem, tingimusel et teete seda igas kaustas ja igas seadmes uuesti. Aga otsing, teavitused, vanusel põhinevad reeglid ja mobiilivaated kasutavad endiselt vastuvõtmise kuupäeva. Kasutaja, kes otsib telefonist "eelmise septembri kirja", ei näe midagi loogilist.

Teine ahvatlev mõte: kopeerida uuesti. Juba kasutuses kontol tekitab see eelkõige duplikaate olemasolevate sõnumite kõrvale, samade või teiste valede kuupäevadega. Paarsada kausta hiljem ei ole teil enam ühtegi puhast postkasti.

Parandus serveri poolel

Hea uudis on see, et algne kuupäev on alles. Parandus seisneb selles, et sihtkonto hakkaks seda kuvama, puudutamata teie sõnumite sisu.

Seda Redate teebki. Teenus ühendub postkastiga (Google Workspace domeeni delegeerimise kaudu, Microsoft 365, Outlook.com ja Hotmail iga inimese Microsofti kontoga või otse IMAP-i kaudu e-posti aadressi ja parooliga). Redate'il ei ole vaja teada, milline tööriist probleemi tekitas: ta leiab e-kirjad, mille kuvatav kuupäev ei vasta nende algsele kuupäevale, olgu põhjuseks Takeout mbox-i lohistamine või midagi muud. Skaneerimine on tasuta ja näitab kahju ulatust enne igasugust otsust.

Parandamiseks kasutab Redate isearendatud parandusmootorit, mitmeastmelist analüüsikonveierit, mis uurib iga sõnumi päisteahelat ja annab igale e-kirjale tagasi tema algse kuupäeva. Iga parandatud e-kiri kontrollitakse seejärel eraldi, sealhulgas RFC-vastavuse kontroll ja sõnumi struktuuri säilitamine. Originaale ei kustutata kunagi: need jäävad teie postkasti nähtavasse kausta, kuni te need ise kustutate.

Miks omal käel nokitsemine on riskantne

Probleemi mõistmine on üks asi. Selle parandamine 15 000 e-kirjal ilma ühtegi kaotamata on hoopis teine.

Skript, mis töötab kümnel testsõnumil, ei pea vastu 30 000 sõnumiga toodangupostkastile. See kohtab signeeritud S/MIME e-kirju, mille väikseimgi muutmine rikub allkirja. Krüpteeritud PGP-sõnumeid. Pesastatud multipart/alternative struktuure, ebaühtlaseid MIME-piire, ootamatuid Content-Transfer-Encoding väärtusi, RFC 2047 järgi kodeeritud mitte-ASCII päiseid, 40 MB manuseid. Siis tulevad API kvoodid, viga 429 Too Many Requests kell kolm öösel keset partiid ja võrgu ajalõpud, mis katkestavad töö sõnumil 11 874.

Ja edasi? Kuidas teada saada, et iga sõnum on terve? Ilma tagasipööramise mehhanismita jätab iga viga endast maha topeltsõnumeid, kadunud manuseid, katkenud vestlusahelaid ja kadunud silte. Redate kontrollib iga e-kirja automaatselt ja hoiab originaali käepärast, just selleks, et te ei peaks kunagi selle peale kihla vedama.

Üks viimane nõuanne, tasuta: hoidke oma algsed Takeouti arhiivid alles, kuni postkast pole kinnitatud. Mbox-fail jääb võrdluskoopiaks ka siis, kui sihtkonto tundub korras olevat.

Teie kliendiga seotud juhendid

Sõltuvalt kliendist, millega kopeerisite, kirjeldavad konkreetset juhtumit järgmised juhendid: Thunderbirdis tehtud IMAP-kopeerimise kuupäevade parandamine ja sama juhtum Apple Mailis.

Kas teie Takeout on juba IMAP-kontole kopeeritud ja kuupäevad on valed? Käivitage Redate'i tasuta skaneerimine, et näha, mitu e-kirja on mõjutatud, ning parandage need ühekordse maksega, postkasti suuruse piiranguta.