Takeout mbox diimpor: semua email bertanggal hari ini

Anda sudah membuka arsip Google Takeout, mengimpor file mbox ke Thunderbird dengan ImportExportTools NG (atau ke Apple Mail), lalu menyeret folder-foldernya ke akun IMAP yang baru. Di aplikasi email, semuanya tersusun rapi per tahun. Di akun tujuan, semua email bertanggal hari ini. Artikel ini menjelaskan apa yang terjadi pada Takeout mbox yang diimpor, mengapa tanggal yang tampil adalah tanggal salinan, cara mengonfirmasinya dalam beberapa menit, dan cara memperbaikinya di sisi server.

Hal pertama yang perlu Anda tahu: email Anda tidak rusak. Tanggal asli masih ada di dalam pesan. Hanya saja, tanggal itu bukan lagi yang ditampilkan oleh akun tujuan.

Skenario umum Takeout mbox yang diimpor

Anda baru saja menutup akun Gmail pribadi yang dibuka lima belas tahun lalu. Anda meminta ekspor lewat takeout.google.com, menunggu pesan dari Google (dua hari untuk kotak surat yang besar), lalu mengunduh empat arsip zip. Di dalam masing-masing ada satu file .mbox per label. Anda mengimpornya ke Thunderbird: folder lokal terisi penuh, pengurutan berdasarkan tanggal sempurna, 2009 di paling bawah, kemarin di paling atas.

Lalu Anda melakukan apa yang akan dilakukan siapa pun. Anda memilih folder-foldernya dan menyeretnya ke akun IMAP tujuan, entah Microsoft 365, penyedia hosting, atau Google Workspace. Transfernya memakan waktu semalaman. Senin pagi, Anda membuka webmail.

Masalahnya? Ke-18.400 email bertanggal akhir pekan, dalam rentang beberapa jam saja. Kontrak tahun 2014 kini bersebelahan dengan newsletter minggu lalu, dan tidak ada yang bisa menelusuri email secara kronologis lagi.

Kasus ini sangat mirip dengan email lama yang semuanya punya tanggal sama, dengan satu perbedaan besar: di sini tidak ada alat migrasi yang terlibat. Cukup dengan seret dan lepas.

Tiga tanggal dalam satu email

Untuk memahaminya, kita harus berhenti membicarakan tanggal sebuah email seolah-olah hanya ada satu. Pesan yang diimpor dari file mbox membawa setidaknya tiga tanggal, dan fungsinya berbeda-beda.

Header Date: tanggal dari pengirim

Ini adalah header Date: yang didefinisikan oleh RFC 2822 (dilanjutkan oleh RFC 5322). Aplikasi email pengirim menuliskannya saat pesan dikirim, misalnya Date: Tue, 14 Mar 2017 09:12:45 +0100. Header ini bagian dari pesan, ikut berpindah bersamanya, dan Takeout menyimpannya apa adanya. Karena tetap utuh, header inilah yang membuat perbaikan menjadi mungkin.

Baris From pada file mbox: tanggal tempelan

Dalam file mbox, setiap pesan didahului satu baris yang diawali From (dengan spasi, tanpa titik dua). Itu bukan header: itu pemisah khas format file, dan bukan bagian dari pesan. Tidak ada alat yang layak dipercaya untuk menentukan tanggal email dari baris ini.

INTERNALDATE: tanggal penyimpanan di server

Tanggal ketiga, dan yang paling tersembunyi: INTERNALDATE, yang didefinisikan oleh RFC 3501. Ini atribut yang disimpan server IMAP di samping pesan (bukan di dalamnya), dan menunjukkan kapan pesan itu ditaruh di kotak surat. Outlook, webmail, dan ponsel memakainya untuk menampilkan serta mengurutkan tanggal diterima. Untuk penjelasan mekanismenya, artikel tentang INTERNALDATE dan tanggal yang salah di IMAP membahasnya lebih dalam.

Satu catatan soal header Received:, yang sering dituduh keliru dalam kasus ini. Baris Received pada email Gmail yang diekspor menceritakan perjalanan pesan yang sebenarnya di tahun 2017: tanggalnya lama dan sah. Jadi, dalam kasus ini tanggal yang salah tidak berada di dalam pesan, melainkan pada metadata yang diberikan server kepada salinannya.

Mengapa akun tujuan menampilkan tanggal salinan

Ketika sebuah aplikasi email menaruh pesan di server IMAP, ia memakai perintah APPEND. Perintah ini menerima, secara opsional, sebuah tanggal untuk diberikan kepada pesan. Jika aplikasi menyertakannya, server menyimpannya sebagai INTERNALDATE. Jika tidak, server menerapkan aturan dari RFC 3501: tanggal dan jam saat itu. Dengan kata lain, tanggal yang tampil bergantung pada cara alat menuliskan email tersebut. Alat yang tidak meneruskan tanggal asli akan mendapat tanggal salinan.

Hasilnya: selama Anda menyeret folder, setiap pesan mengambil tanggal penyimpanannya sendiri. Folder berisi 3.000 email yang disalin dalam 40 menit akan jatuh ke dalam jendela waktu 40 menit itu.

Lalu bagaimana dengan folder lokal Thunderbird? Folder itu tampak sempurna karena Thunderbird mengurutkannya berdasarkan header Date, bukan tanggal server, sebab folder lokal tidak punya server. Perilaku Apple Mail pada kotak surat yang diimpor mirip: semuanya baik-baik saja selama pesan tetap berada di Mac. Kebenarannya baru terlihat saat perangkat lunak lain, misalnya Outlook, membaca kotak surat IMAP tersebut.

Sebenarnya, tidak sepenuhnya tepat menyebut semua aplikasi selalu keliru. Beberapa versi meneruskan tanggal, yang lain tidak, dan perilakunya berubah seiring pembaruan. Akibatnya, dua rekan kerja yang memakai cara yang sama bisa mendapat hasil berbeda, sehingga diagnosisnya lebih membingungkan daripada yang terlihat.

Seret dan lepas bukanlah migrasi. Itu penyalinan, dan sebuah salinan membawa tanggal pembuatannya.

Cara mengenali kasus ini dalam lima menit

Sebelum mencari solusi, pastikan Anda memang berada dalam skenario ini dan bukan skenario lain. Empat pemeriksaan sudah cukup.

• Bandingkan kedua tempat. Folder lokal Thunderbird (atau kotak surat impor Apple Mail) menampilkan tanggal yang benar, sedangkan akun IMAP menampilkan tanggal baru untuk pesan yang sama.
• Lihat rentangnya. Di sebuah folder pada akun IMAP, tanggal diterima hanya berada dalam rentang beberapa jam, bahkan beberapa menit, di sekitar waktu Anda memindahkan folder.
• Buka sumber sebuah pesan. Di Thunderbird, menu View lalu Message Source; di Outlook, properti pesan menampilkan header-nya. Anda seharusnya menemukan baris Date: yang lama, padahal tampilannya menunjukkan tanggal baru.
• Periksa urutannya. Pesan muncul sesuai urutan saat aplikasi menyalinnya, bukan urutan kronologis.

Berikut hasil perbandingan pada satu pesan nyata:

Date: Tue, 14 Mar 2017 09:12:45 +0100          (di dalam pesan, utuh)
Tanggal yang tampil di akun IMAP: hari penyalinan   (metadata server)

Kalau kedua baris itu tidak menceritakan hal yang sama, berarti inilah kasus Anda. Dan jika tanggal yang tampil salah tetapi Date: juga salah, itu masalah lain yang lebih jarang dan tidak dibahas di artikel ini.

(Omong-omong, kalau Anda belum pernah membaca header mentah sebuah email, siapkan kopi: bacaannya tidak seasyik novel santai.)

Mengurutkan berdasarkan tanggal kirim: hanya plester

Refleks pertama adalah mengganti pengurutan ke tanggal kirim. Di Outlook cara ini lumayan berhasil, asalkan diulang di setiap folder dan di setiap perangkat. Namun pencarian, notifikasi, aturan berbasis usia email, dan tampilan di ponsel tetap memakai tanggal diterima. Pengguna yang mencari email bulan September lalu di ponselnya tidak akan menemukan hasil yang masuk akal.

Jalan lain yang menggoda: mengulang penyalinan. Pada akun yang sudah dipakai, ini terutama menghasilkan duplikat di samping pesan yang sudah ada, dengan tanggal salah yang sama atau yang lain. Setelah seratusan folder, Anda tidak lagi memiliki satu pun kotak surat yang bersih.

Perbaikan di sisi server

Kabar baiknya, tanggal asli masih ada. Perbaikannya berupa membuat akun tujuan menampilkan tanggal itu, tanpa menyentuh isi pesan Anda.

Itulah yang dilakukan Redate. Layanan ini terhubung ke kotak surat (Google Workspace lewat delegasi seluruh domain, Microsoft 365, Outlook.com dan Hotmail dengan akun Microsoft masing-masing orang, atau IMAP langsung dengan alamat dan kata sandi). Redate tidak perlu tahu alat mana yang menyebabkan masalah: ia menemukan email yang tanggal tampilannya tidak cocok dengan tanggal aslinya, baik penyebabnya seret dan lepas dari Takeout mbox maupun hal lain. Pemindaian gratis dan menunjukkan besarnya kerusakan sebelum Anda mengambil keputusan apa pun.

Untuk perbaikannya sendiri, Redate mengandalkan mesin koreksi milik sendiri, sebuah pipeline analisis bertahap yang memeriksa rantai header setiap pesan dan mengembalikan tanggal asli ke setiap email. Setiap email yang sudah diperbaiki kemudian diverifikasi satu per satu, dengan validasi kepatuhan RFC dan pemeliharaan struktur pesan. Email asli tidak pernah dihapus: ia tetap berada di folder yang terlihat di kotak surat Anda sampai Anda sendiri yang menghapusnya.

Mengapa mengerjakan sendiri itu berisiko

Memahami masalahnya itu satu hal. Memperbaiki 15.000 email tanpa kehilangan satu pun adalah hal lain.

Skrip yang berjalan baik pada sepuluh pesan uji tidak akan bertahan di kotak surat produksi berisi 30.000 pesan. Ia akan bertemu email S/MIME bertanda tangan, yang tanda tangannya rusak begitu ada perubahan sekecil apa pun. Pesan PGP terenkripsi. Struktur multipart/alternative yang bersarang, batas MIME yang tidak konsisten, Content-Transfer-Encoding yang tak terduga, header non-ASCII yang dikodekan dengan RFC 2047, lampiran 40 MB. Lalu datang kuota API, galat 429 Too Many Requests pukul 3 pagi di tengah batch, dan timeout jaringan yang menghentikan proses tepat di pesan ke-11.874.

Lalu bagaimana? Bagaimana Anda tahu setiap pesan masih utuh? Tanpa mekanisme rollback, satu kesalahan meninggalkan pesan ganda, lampiran hilang, utas percakapan terputus, dan label lenyap. Redate memeriksa setiap email secara otomatis dan menyimpan aslinya tetap dalam jangkauan, justru agar Anda tidak perlu bertaruh soal itu.

Satu saran terakhir, gratis: simpan arsip Takeout asli Anda sampai kotak surat baru dinyatakan beres. File mbox tetap menjadi salinan acuan, sekalipun akun tujuan tampak sudah benar.

Panduan terkait aplikasi yang Anda pakai

Tergantung aplikasi yang Anda pakai untuk menyalin, panduan rinci berikut membahas kasusnya secara spesifik: memperbaiki tanggal salinan IMAP manual di Thunderbird dan kasus yang sama di Apple Mail.

Takeout Anda sudah tersalin ke akun IMAP dan tanggalnya salah? Jalankan pemindaian gratis Redate untuk melihat berapa banyak email yang terdampak, lalu perbaiki dengan pembayaran sekali bayar, tanpa batas ukuran kotak surat.