Takeout mbox -tuonti: kaikki sähköpostit tältä päivältä

Avasit Google Takeout -arkistosi, toit mbox-tiedoston Thunderbirdiin ImportExportTools NG:llä (tai Apple Mailiin) ja vedit kansiot uudelle IMAP-tilillesi. Sähköpostiohjelmassa viestit olivat siististi vuosi vuodelta. Kohdetilillä ne on kaikki päivätty tälle päivälle. Tässä artikkelissa selitetään, mitä tuodulle Takeout mbox -aineistolle tapahtuu, miksi näkyvä päivämäärä on kopioinnin hetki, miten asian voi varmistaa muutamassa minuutissa ja miten sen korjaa palvelimen puolella.

Ensimmäinen asia: sähköpostisi eivät ole vahingoittuneet. Alkuperäinen päivämäärä on edelleen viestissä. Kohdetili vain ei enää nosta sitä esiin.

Tyypillinen Takeout mbox -tilanne

Olet juuri sulkenut viisitoista vuotta vanhan henkilökohtaisen Gmail-tilin. Tilasit viennin osoitteesta takeout.google.com, odotit Googlen viestiä (kaksi päivää isolla postilaatikolla) ja latasit neljä zip-arkistoa. Jokaisessa on yksi .mbox-tiedosto tunnistetta kohden. Tuot ne Thunderbirdiin: paikallinen kansio täyttyy, päivämäärän mukainen lajittelu on moitteeton, vuosi 2009 alimpana ja eilinen ylimpänä.

Sitten teet sen, minkä kuka tahansa tekisi. Valitset kansiot ja vedät ne kohde-IMAP-tilille, joka on Microsoft 365, palveluntarjoajan tili tai Google Workspace. Siirto kestää koko illan. Maanantaiaamuna avaat selainpostin.

Ongelma? Kaikki 18 400 sähköpostia on päivätty viikonlopulle, muutaman tunnin haarukkaan. Vuoden 2014 sopimus on samassa kohdassa viime viikon uutiskirjeen kanssa, eikä mitään löydä enää aikajärjestyksessä.

Tilanne on hyvin lähellä sitä, mistä kerrotaan artikkelissa vanhat sähköpostit, sama päivämäärä, yhdellä isolla erolla: tässä yksikään siirtotyökalu ei ole syyllinen. Pelkkä vetäminen ja pudottaminen riittää.

Kolme päivämäärää yhdessä sähköpostissa

Ymmärtääksesi asian sinun täytyy lopettaa puhuminen sähköpostin "päivämäärästä" yksikössä. Mbox-tiedostosta tuodulla viestillä on vähintään kolme, eivätkä ne palvele samaa tarkoitusta.

Date-otsikko: lähettäjän päivämäärä

Tämä on RFC 2822:ssa määritelty Date:-otsikko (jonka RFC 5322 toistaa). Lähettäjän sähköpostiohjelma kirjoittaa sen lähetyshetkellä, esimerkiksi Date: Tue, 14 Mar 2017 09:12:45 +0100. Se kuuluu viestiin, kulkee sen mukana, ja Takeout säilyttää sen sellaisenaan. Juuri tämä tekee korjauksen mahdolliseksi, koska otsikko pysyy koskemattomana.

Mbox-tiedoston From-rivi: julkisivun päivämäärä

Mbox-tiedostossa jokaisen viestin edellä on rivi, joka alkaa sanalla From (välilyönnillä, ilman kaksoispistettä). Se ei ole otsikko vaan tiedostomuodon oma erotin, joka ei kuulu viestiin. Yhtään vakavasti otettavaa työkalua ei pitäisi ohjata luottamaan siihen.

INTERNALDATE: palvelimelle tallennuksen hetki

Kolmas päivämäärä on näkymättömin: RFC 3501:n määrittelemä INTERNALDATE. IMAP-palvelin tallentaa sen viestin viereen (ei sen sisään), ja se vastaa hetkeä, jolloin viesti talletettiin postilaatikkoon. Outlook, selainpostit ja puhelimet käyttävät sitä saapumispäivän näyttämiseen ja lajitteluun. Mekanismin yksityiskohdista kertoo tarkemmin artikkeli IMAP INTERNALDATE: miksi päivämäärät hajoavat.

Vielä tarkennus Received:-otsikoista, joita syytetään tässä usein väärin perustein. Viedyn Gmail-viestin Received-rivit kertovat viestin todellisen reitin vuonna 2017: niissä on vanhat ja aidot päivämäärät. Tässä tapauksessa väärä päivämäärä ei siis ole viestissä vaan metatiedoissa, jotka palvelin antaa kopiolle.

Miksi kohdetili näyttää kopioinnin päivämäärän

Kun sähköpostiohjelma tallettaa viestin IMAP-palvelimelle, se käyttää APPEND-komentoa. Komento hyväksyy valinnaisen päivämäärän, joka viestille annetaan. Jos ohjelma antaa sen, palvelin tallentaa sen INTERNALDATE-arvoksi. Muuten palvelin noudattaa RFC 3501:n mukaista sääntöä: nykyhetken päivä ja kellonaika. Toisin sanoen näkyvä päivämäärä riippuu siitä, miten työkalu kirjoitti sähköpostin. Työkalu, joka ei välitä alkuperäistä päivämäärää, saa kopioinnin päivämäärän.

Tulos: kun vedät kansioitasi, jokainen viesti saa oman talletushetkensä päivämäärän. Kolmen tuhannen sähköpostin kansio, joka kopioituu 40 minuutissa, mahtuu 40 minuutin ikkunaan.

Entä Thunderbirdin paikallinen kansio? Se näytti täydelliseltä, koska Thunderbird lajittelee siinä Date-otsikon mukaan eikä palvelimen päivämäärän, sillä paikallisella kansiolla ei ole palvelinta. Apple Mail käyttäytyy tuotujen postilaatikoiden kanssa samaan tapaan: kaikki on hyvin niin kauan kuin viestit pysyvät Macilla. Totuus paljastuu, kun jokin toinen ohjelma, vaikkapa Outlook, lukee IMAP-postilaatikon.

Tarkkaan ottaen ei ole täysin oikein sanoa, että kaikki sähköpostiohjelmat erehtyvät joka kerta. Jotkin versiot välittävät päivämäärän, toiset eivät, ja käytös on muuttunut päivitysten myötä. Siksi kaksi työkaveria, jotka seuraavat samaa ohjetta, voivat päätyä eri tulokseen, ja vian selvittäminen on hämmentävämpää kuin luulisi.

Vetäminen ja pudottaminen ei ole siirto. Se on kopiointi, ja kopio kantaa valmistushetkensä päivämäärää.

Näin tunnistat tilanteen viidessä minuutissa

Ennen kuin etsit ratkaisua, varmista, että olet juuri tässä tilanteessa etkä jossain toisessa. Neljä tarkistusta riittää.

• Vertaa kahta paikkaa. Thunderbirdin paikallisessa kansiossa (tai Apple Mailin tuodussa postilaatikossa) päivämäärät ovat oikein, IMAP-tilillä samojen viestien päivämäärät ovat tuoreita.
• Katso haarukkaa. IMAP-tilin kansiossa saapumispäivät mahtuvat muutamaan tuntiin tai jopa minuuttiin sen hetken ympärille, jolloin siirsit kansiot.
• Avaa viestin lähdekoodi. Thunderbirdissä valitse Näytä ja sen jälkeen Viestin lähde; Outlookissa viestin ominaisuudet näyttävät otsikot. Sieltä pitäisi löytyä vanha Date:-rivi, vaikka näkymässä lukee tuore päivämäärä.
• Tarkista järjestys. Viestit näkyvät siinä järjestyksessä, jossa sähköpostiohjelma kopioi ne, ei aikajärjestyksessä.

Näin vertailu näyttää oikean viestin kohdalla:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (viestin sisällä, koskematon)
IMAP-tilin näyttämä päivämäärä: kopiointipäivä   (palvelimen metatieto)

Jos nämä kaksi riviä kertovat eri tarinaa, olet oikeassa paikassa. Ja jos näkyvät päivämäärät ovat väärin mutta myös Date: on väärin, kyseessä on toinen, harvinaisempi ongelma, joka ei kuulu tähän artikkeliin.

(Muuten, jos et ole koskaan lukenut sähköpostin raakoja otsikoita, varaa kahvia: ei aivan rantakirjallisuutta.)

Lajittelu lähetyspäivän mukaan: laastari

Ensimmäinen refleksi on vaihtaa lajittelu lähetyspäivään. Outlookissa se toimii suunnilleen, kunhan sen tekee uudelleen jokaiselle kansiolle ja jokaiselle laitteelle. Mutta haku, ilmoitukset, iän mukaan toimivat säännöt ja mobiilinäkymät käyttävät edelleen saapumispäivää. Käyttäjä, joka etsii puhelimestaan "viime syyskuun viestiä", ei näe mitään järkevää.

Toinen houkutteleva ratkaisu on kopioida kaikki uudelleen. Jo käytössä olevalla tilillä se tuottaa lähinnä kaksoiskappaleita jo olemassa olevien viestien viereen, samoilla vääriä päivämäärillä tai uusilla. Sadan kansion jälkeen sinulla ei ole yhtään puhdasta postilaatikkoa.

Korjaus palvelimen puolella

Hyvä uutinen on, että alkuperäinen päivämäärä on edelleen olemassa. Korjaus tarkoittaa sitä, että kohdetili saadaan näyttämään se koskematta viestiesi sisältöön.

Tämän Redate tekee. Palvelu yhdistää postilaatikkoon (Google Workspace toimialueen laajuisella delegoinnilla, Microsoft 365, Outlook.com ja Hotmail kunkin käyttäjän Microsoft-tilillä tai suora IMAP sähköpostiosoitteella ja salasanalla). Redaten ei tarvitse tietää, mikä työkalu ongelman aiheutti: se löytää sähköpostit, joiden näkyvä päivämäärä ei vastaa alkuperäistä päivämäärää, olipa syynä Takeout mbox -aineiston vetäminen ja pudottaminen tai jokin muu. Postilaatikon ilmainen skannaus näyttää vahinkojen laajuuden ennen kuin päätät mitään.

Itse korjausta varten Redate nojaa Redaten kehittämään korjausmoottoriin, monivaiheiseen analyysiputkeen, joka tutkii jokaisen viestin otsikkoketjun ja palauttaa jokaiselle sähköpostille sen alkuperäisen päivämäärän. Jokainen korjattu sähköposti tarkistetaan sen jälkeen erikseen, RFC-yhdenmukaisuuden validoinnilla ja viestin rakenteen säilyttämisellä. Alkuperäisiä ei koskaan poisteta: ne pysyvät näkyvässä kansiossa postilaatikossasi, kunnes poistat ne itse.

Miksi itse näpertely on riskialtista

Ongelman ymmärtäminen on yksi asia. Sen korjaaminen 15 000 sähköpostille menettämättä yhtäkään on aivan toinen.

Skripti, joka toimii kymmenellä testiviestillä, ei selviä 30 000 viestin tuotantopostilaatikosta. Se törmää allekirjoitettuihin S/MIME-sähköposteihin, joissa pieninkin muutos rikkoo allekirjoituksen. Salattuihin PGP-viesteihin. Sisäkkäisiin multipart/alternative-rakenteisiin, ristiriitaisiin MIME-rajoihin, odottamattomiin Content-Transfer-Encoding-arvoihin, RFC 2047 -koodattuihin ei-ASCII-otsikoihin ja 40 Mt:n liitteisiin. Sitten tulevat API-kiintiöt, 429 Too Many Requests -virhe kolmelta yöllä kesken erän ja verkon aikakatkaisut, jotka katkaisevat työn viestissä 11 874.

Ja sen jälkeen? Mistä tiedät, että jokainen viesti on ehjä? Ilman palautusmekanismia yksi virhe jättää jälkeensä kaksoiskappaleita, kadonneita liitteitä, rikkoutuneita keskusteluketjuja ja hävinneitä tunnisteita. Redate tarkistaa jokaisen sähköpostin automaattisesti ja pitää alkuperäisen käden ulottuvilla, juuri jotta sinun ei koskaan tarvitse veikata sen varaan.

Vielä yksi ilmainen vinkki: säilytä alkuperäiset Takeout-arkistosi kokoanan niin kauan, kunnes postilaatikko on validoitu. Mbox-tiedosto on edelleen vertailukopio, vaikka kohdetili näyttäisi olevan kunnossa.

Sähköpostiohjelmaasi liittyvät oppaat

Riippuen siitä, millä ohjelmalla kopioinnin teit, seuraavat yksityiskohtaiset oppaat käsittelevät juuri sinun tapaustasi: Thunderbirdillä tehdyn IMAP-kopioinnin päivämäärien korjaaminen ja sama tilanne Apple Mailissa.

Onko Takeoutisi jo kopioitu IMAP-tilille ja päivämäärät ovat väärin? Käynnistä Redaten ilmainen skannaus nähdäksesi, kuinka moni sähköposti on kyseessä, ja korjaa ne kertamaksulla, ilman rajaa postilaatikon koolle.