Takeout mbox import: minden e-mail mai dátumú

Megnyitotta a Google Takeout archívumot, az mbox fájlt az ImportExportTools NG bővítménnyel importálta Thunderbirdbe (vagy Apple Mailbe), majd a mappákat áthúzta az új IMAP-fiókba. A levelezőkliensben az e-mailek szépen, évek szerint rendezve álltak. A célfiókban viszont mindegyik a mai dátumot viseli. Ez a cikk elmagyarázza, mi történik egy importált Takeout mbox esetében, miért a másolás dátuma jelenik meg, hogyan győződhet meg erről pár perc alatt, és hogyan javítható a hiba a szerver oldalán.

Először is az a legfontosabb tudnivaló, hogy az e-mailek nem sérültek. Az eredeti dátum még mindig ott van az üzenetben. Csak éppen nem az az adat kerül előtérbe, amelyet a célfiók mutat.

Egy importált Takeout mbox tipikus forgatókönyve

Éppen most zárt be egy tizenöt éve nyitott személyes Gmail-fiókot. Kérte az exportot a takeout.google.com oldalon, megvárta a Google értesítését (nagy postaládánál ez két nap), és letöltött négy zip-archívumot. Mindegyikben címkénként egy .mbox fájl. Ezeket importálja Thunderbirdbe: a helyi mappa megtelik, a dátum szerinti rendezés hibátlan, alul a 2009-es, felül a tegnapi levelek.

Ezután azt teszi, amit mindenki tenne. Kijelöli a mappákat, és áthúzza őket a célfiók IMAP-postaládájába, ami lehet Microsoft 365, egy tárhelyszolgáltató vagy Google Workspace. Az átvitel egy egész estét vesz igénybe. Hétfő reggel megnyitja a webmailt.

A gond? A 18 400 e-mail mind a hétvége dátumát viseli, néhány órás sávba zsúfolva. Egy 2014-es szerződés ott áll egy múlt heti hírlevél mellett, és időrendben senki nem talál meg semmit.

Az eset nagyon hasonlít arra, amikor a régi e-mailek mind ugyanazt a dátumot mutatják, egy jelentős különbséggel: itt nincs szó semmilyen migrációs eszközről. Elég hozzá a fogd és vidd.

Három dátum egyetlen e-mailben

A megértéshez el kell engednünk azt a szokást, hogy egy e-mail "dátumáról" beszélünk. Az mbox fájlból importált üzenet legalább hármat hordoz, és mindegyiknek más a szerepe.

A Date fejléc: a feladó dátuma

Ez az RFC 2822 (később az RFC 5322) által meghatározott Date: fejléc. A feladó levelezőprogramja írja bele küldéskor, például így: Date: Tue, 14 Mar 2017 09:12:45 +0100. Az üzenet része, együtt utazik vele, és a Takeout változtatás nélkül megőrzi. Éppen ez teszi lehetővé a javítást, hiszen sértetlen marad.

Az mbox fájl From sora: látszatdátum

Az mbox fájlban minden üzenetet egy From szóval kezdődő sor előz meg (szóközzel, kettőspont nélkül). Ez nem fejléc: a fájlformátum saját elválasztója, amely nem tartozik az üzenethez. Egyetlen komoly eszköz sem támaszkodhat rá egy e-mail keltezésénél.

Az INTERNALDATE: a szerverre kerülés dátuma

A harmadik dátum a legkevésbé feltűnő: az RFC 3501 által meghatározott INTERNALDATE. Ezt az attribútumot az IMAP-szerver az üzenet mellett (nem benne) tárolja, és azt az időpontot jelzi, amikor az üzenet a postaládába került. Az Outlook, a webmailek és a telefonok ebből jelenítik meg és rendezik a beérkezés dátumát. A mechanizmus részleteiről az IMAP INTERNALDATE és a hibás dátumok című cikk részletesebben szól.

Egy megjegyzés a Received: fejlécekről, amelyeket itt gyakran alaptalanul vádolnak. Egy exportált Gmail-levél Received sorai a 2017-es valódi útvonalat mesélik el: régi, jogos dátumokat tartalmaznak. Ebben az esetben tehát a rossz dátum nem az üzenetben él, hanem abban a metaadatban, amelyet a szerver a másolathoz rendel.

Miért a másolás dátumát mutatja a célfiók?

Amikor egy kliens üzenetet helyez el egy IMAP-szerveren, az APPEND parancsot használja. Ez a parancs opcionálisan megadhat egy dátumot az üzenethez. Ha a kliens megadja, a szerver ezt jegyzi meg INTERNALDATE-ként. Ha nem, a szerver az RFC 3501 szerinti szabályt alkalmazza: a pillanatnyi dátumot és időt. Vagyis a megjelenő dátum azon múlik, hogyan írta be az e-mailt az eszköz. Az az eszköz, amely nem adja át az eredeti dátumot, a másolás dátumát kapja.

Az eredmény: amíg húzza a mappákat, minden üzenet a saját elhelyezésének időpontját veszi fel. Egy 3000 e-mailes mappa, amelyet 40 perc alatt másoltak át, egy 40 perces ablakba esik.

És a Thunderbird helyi mappája? Azért tűnt tökéletesnek, mert a Thunderbird ott a Date fejléc alapján rendez, nem szerverdátum szerint, hiszen egy helyi mappának nincs szervere. Az Apple Mail az importált postaládákkal hasonlóan viselkedik: minden rendben van, amíg az üzenetek a Macen maradnak. Az igazság akkor derül ki, amikor egy másik program, mondjuk az Outlook, beolvassa az IMAP-postaládát.

Egyébként pontatlan lenne azt állítani, hogy minden kliens mindig téved. Egyes verziók átadják a dátumot, mások nem, és a viselkedés a frissítések során változott. Emiatt két kolléga, aki ugyanazt a módszert követi, eltérő eredményt kaphat, ami a diagnózist zavarosabbá teszi, mint gondolnánk.

A fogd és vidd nem migráció. Az másolás, a másolat pedig az elkészítése napját viseli.

Hogyan ismeri fel ezt az esetet öt perc alatt?

Mielőtt megoldást keresne, győződjön meg róla, hogy tényleg ebben a helyzetben van, és nem egy másikban. Négy ellenőrzés elég.

• Hasonlítsa össze a két helyet. A Thunderbird helyi mappája (vagy az Apple Mail importált postaládája) helyes dátumokat mutat, az IMAP-fiók ugyanezekre az üzenetekre friss dátumokat.
• Nézze meg a sávot. Az IMAP-fiók egy mappájában a beérkezés dátumai néhány órán, sőt perceken belül vannak, a mappák áthelyezésének időpontja körül.
• Nyissa meg egy üzenet forrását. Thunderbirdben a Nézet menü, majd az Üzenet forrása; Outlookban az üzenet tulajdonságai mutatják a fejléceket. Egy régi Date: sort kell találnia, miközben a megjelenítés friss dátumot mutat.
• Ellenőrizze a sorrendet. Az üzenetek abban a sorrendben állnak, ahogyan a kliens másolta őket, nem időrendben.

Íme, mit ad az összevetés egy valódi üzeneten:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (az üzenetben, sértetlen)
Az IMAP-fiók által mutatott dátum: a másolás napja   (a szerver metaadata)

Ha e két sor nem ugyanazt mondja, akkor jó helyen jár. És ha a megjelenített dátumok hibásak, de a Date: is az, az egy másik, ritkább probléma, amely nem tartozik e cikk körébe.

(Egyébként, ha még sosem olvasott nyers e-mail-fejléceket, készítsen hozzá egy kávét: nem éppen strandolvasmány.)

Rendezés küldési dátum szerint: tapasz a sebre

A kézenfekvő reflex az, hogy átállítjuk a rendezést a küldés dátumára. Outlookban ez nagyjából működik, ha minden mappán és minden eszközön újra megcsinálja. De a keresés, az értesítések, az életkoron alapuló szabályok és a mobilos nézetek továbbra is a beérkezés dátumát használják. Aki a telefonján "a tavaly szeptemberi levelet" keresi, semmi logikusat nem fog látni.

Egy másik csábító ötlet: megismételni a másolást. Egy már használt fiókban ez főleg duplikátumokat hoz létre a már meglévő üzenetek mellett, ugyanazokkal a hibás dátumokkal vagy másokkal. Száz mappával később már egyetlen tiszta postaládája sincs.

Javítás a szerver oldalán

A jó hír, hogy az eredeti dátum még megvan. A javítás lényege, hogy a célfiók azt jelenítse meg, az üzenetek tartalmának érintése nélkül.

Ezt teszi a Redate. A szolgáltatás csatlakozik a postaládához (Google Workspace esetén tartományszintű delegálással, Microsoft 365, Outlook.com és Hotmail esetén az egyes személyek Microsoft-fiókjával, vagy közvetlen IMAP-kapcsolattal a cím és a jelszó megadásával). A Redate-nek nem kell tudnia, melyik eszköz okozta a bajt: megtalálja azokat az e-maileket, amelyeknek a megjelenített dátuma nem egyezik az eredeti dátumukkal, akár egy Takeout mbox fogd és vidd másolása okozta, akár valami más. Az átvizsgálás ingyenes, és bármilyen döntés előtt megmutatja a kár mértékét.

A javításhoz a Redate saját fejlesztésű javítómotorra épít: egy többlépcsős elemzési folyamat vizsgálja minden üzenet fejlécláncát, és visszaadja az e-mailnek az eredeti dátumát. Minden javított e-mailt ezután egyenként ellenőriz, RFC-megfelelőségi validálással és az üzenetszerkezet megőrzésével. Az eredeti példányokat a Redate soha nem törli: látható mappában maradnak a postaládájában, amíg Ön maga nem törli őket.

Miért kockázatos házilag próbálkozni?

A probléma megértése egy dolog. Kijavítani 15 000 e-mailen úgy, hogy egyetlen egy se vesszen el, az már egy másik.

Az a szkript, amely tíz tesztüzeneten működik, nem éli túl egy 30 000 üzenetes éles postaládát. Belefut aláírt S/MIME e-mailekbe, amelyeknek a legkisebb módosítása is tönkreteszi az aláírását. Titkosított PGP-üzenetekbe. Egymásba ágyazott multipart/alternative szerkezetekbe, következetlen MIME-határolókba, váratlan Content-Transfer-Encoding értékekbe, RFC 2047 szerint kódolt, nem ASCII fejlécekbe, 40 MB-os mellékletekbe. Aztán jönnek az API-kvóták, a 429 Too Many Requests hiba hajnali háromkor, egy futó köteg közepén, és a hálózati időtúllépések, amelyek a 11 874. üzenetnél szakítják meg a műveletet.

És utána? Honnan tudja, hogy minden üzenet ép? Visszaállítási mechanizmus nélkül egy hiba dupla üzeneteket, elveszett mellékleteket, széttört beszélgetésszálakat és eltűnt címkéket hagy maga után. A Redate automatikusan ellenőriz minden e-mailt, és kéznél tartja az eredetit, pontosan azért, hogy ezen soha ne kelljen kockáztatnia.

Egy utolsó, ingyenes tanács: őrizze meg az eredeti Takeout archívumokat, amíg a postaládát nem hagyta jóvá. Az mbox fájl marad a hivatkozási másolat, akkor is, ha a célfiók rendben lévőnek látszik.

A kliensére szabott útmutatók

Attól függően, melyik klienssel másolt, a következő részletes útmutatók az adott esetet írják le: a Thunderbirdben végzett IMAP-másolás dátumainak javítása és ugyanez az eset Apple Mailben.

A Takeout már átkerült az IMAP-fiókba, és a dátumok hibásak? Indítsa el a postaláda ingyenes átvizsgálását a Redate-tel, hogy lássa, hány e-mailt érint, majd javítsa ki őket egyszeri fizetéssel, a postaláda méretére vonatkozó korlát nélkül.