Perbaiki Tanggal Email imapsync

Janji --syncinternaldates (dan Di Mana Ia Berhenti)

Anda menjalankan perintah imapsync. Anda menyertakan --syncinternaldates karena Anda sudah membaca dokumentasinya dan Anda memang teliti seperti itu. Migrasi selesai, log mengatakan semuanya berhasil ditransfer, nol kesalahan. Lalu Anda membuka kotak surat di Outlook dan setiap email menampilkan tanggal kemarin.

Ini adalah salah satu frustrasi paling umum dengan imapsync, dan sudah membingungkan administrator sistem setidaknya sejak 2017. Flag --syncinternaldates seharusnya mempertahankan IMAP INTERNALDATE selama migrasi. Dan memang begitu: flag ini memberikan setiap salinan tanggal internal yang dimiliki server sumber. Justru di situlah letak jebakannya.

imapsync adalah tool open-source berbasis Perl yang ditulis oleh Gilles Lamiral, dan tool ini benar-benar bagus dalam apa yang dilakukannya. Ia menangani transfer kotak surat IMAP-ke-IMAP dengan tingkat keandalan yang membuat sebagian besar tool komersial iri. Tapi imapsync hanya bisa menyalin tanggal yang ditemukannya, dan di sinilah hal-hal menjadi rumit.

Bagaimana Tanggal IMAP Sebenarnya Bekerja

Ada tiga "tanggal" berbeda yang terlibat dalam setiap email, dan kebanyakan orang (termasuk beberapa administrator TI) mencampuradukkannya:

Header Date: (RFC 2822) - tanggal yang dicap oleh klien email pengirim pada pesan saat dibuat. Ini berada di dalam body pesan dan tidak pernah diubah oleh server email.
Header Received: - setiap server email yang memproses pesan menambahkan satu header dengan cap waktunya sendiri. Header-header ini membentuk rantai dari pengirim ke penerima. Header Received teratas (terbaru) adalah yang digunakan sebagian klien email untuk tampilan.
INTERNALDATE - cap waktu sisi server IMAP yang mengontrol cara pesan diurutkan di kotak surat. Ini diset saat pesan pertama kali disimpan melalui IMAP APPEND.

Ketika imapsync memigrasikan sebuah pesan, ia membaca pesan tersebut dari server sumber (termasuk INTERNALDATE-nya) dan menulisnya ke server tujuan menggunakan IMAP APPEND. Flag --syncinternaldates memberitahu imapsync untuk meneruskan INTERNALDATE sumber ke server tujuan selama APPEND.

Berikut kabar baiknya: Microsoft 365, Outlook.com, dan Gmail menyimpan tanggal yang diberikan kepada mereka. Jadi ketika tanggal keluar salah, masalahnya ada di tempat lain.

Mengapa Tanggal Masih Bisa Salah

Spesifikasi IMAP (RFC 3501) mengatakan bahwa jika tanggal-waktu disediakan bersama perintah APPEND, server SEHARUSNYA menggunakannya. "SEHARUSNYA" dalam bahasa RFC berarti "lakukan ini kecuali Anda punya alasan bagus untuk tidak melakukannya". Microsoft 365, Outlook.com, dan Gmail memang melakukannya: salinan yang membawa tanggal aslinya akan mempertahankannya.

Namun, yang diteruskan imapsync adalah tanggal yang dimiliki server SUMBER untuk setiap pesan, bukan tanggal email itu dikirim. Pada kotak surat yang sehat, kedua tanggal ini cocok. Pada kotak surat yang sudah pernah dimigrasikan sekali atau dipulihkan dari cadangan, sumber mungkin menyimpan tanggal operasi sebelumnya itu, dan imapsync menyalinnya begitu saja.

Gmail menjadi kasus khusus hanya ketika salinan melewati API impor milik Gmail sendiri, bukan IMAP: API tersebut menambahkan baris Received: bertanggal hari penyalinan, dan Outlook bisa menampilkan tanggal itu. imapsync berbicara dalam bahasa IMAP, jadi tidak terpengaruh.

Dovecot dan Cyrus, dua server IMAP open-source yang paling umum, juga menyimpan tanggal dari APPEND. Jadi apa pun tujuannya, pertanyaannya sama: tanggal apa yang dimiliki sumber?

Kesalahan Command Line imapsync Umum yang Merusak Tanggal

Selain tanggal sumber, administrator sering tersandung pada opsi command-line imapsync, atau menyalahkan opsi yang salah. Berikut kesalahan yang paling sering saya lihat:

Menyalin dari sumber yang tanggalnya sudah salah sejak awal

--syncinternaldates aktif secara default: imapsync memberikan setiap salinan tanggal internal yang dimiliki server sumber (dokumentasinya: "Sets the internal dates on host2 as the same as host1"). Jika kotak surat sumber itu sendiri adalah hasil migrasi atau pemulihan sebelumnya, tanggal internalnya mungkin sudah menjadi tanggal operasi tersebut, dan imapsync dengan setia menyalin tanggal yang salah itu. Ini adalah penyebab paling umum, dan yang paling mudah terlewat, karena log menunjukkan dua tanggal yang identik.

Menggunakan --syncinternaldates dengan --addheader

Beberapa panduan merekomendasikan penggunaan --addheader untuk menyuntikkan header kustom selama migrasi. Menambahkan header memodifikasi pesan (satu baris tambahan di atas) tapi tidak memodifikasi tanggal yang diteruskan imapsync, jadi ini tidak menjelaskan tanggal yang salah. Salinan itu sekadar tidak lagi identik dengan aslinya, yang menjadi penting jika Anda membandingkan keduanya.

Mencampurkan --minage dan --maxage dengan pelestarian tanggal

Flag --minage dan --maxage memfilter pesan mana yang dimigrasikan berdasarkan usianya. Keduanya tidak memengaruhi cara tanggal ditangani di tujuan. Saya pernah melihat administrator menghabiskan berjam-jam mengubah-ubah flag ini karena mengira akan memperbaiki masalah tanggal. Tidak akan.

Menyalahkan TLS atas Tanggal yang Bergeser

Melalui TLS (--ssl1, --ssl2), penyiapan koneksi menambah latensi, dan pada migrasi besar (50.000+ pesan) hal ini bisa bertambah hingga berjam-jam. Ini tidak menyentuh tanggal: setiap salinan membawa tanggal yang diteruskan imapsync, berapa pun waktu sebenarnya saat pesan itu tiba.

Membaca Log imapsync: Apa yang Sebenarnya Diberitahukan Output-nya

imapsync menghasilkan log yang detail, dan itu bagus. Tapi output log bisa menyesatkan soal tanggal.

Baris transfer yang berhasil biasanya terlihat seperti ini:

msg source stratemind/42 {5765} D:2019-01-15 13:22:07 -> dest stratemind/42 {5765} D:2019-01-15 13:22:07

Kedua tanggal cocok. Itu berarti imapsync mengirim INTERNALDATE yang benar ke tujuan. Dan Microsoft 365, Outlook.com, dan Gmail semuanya menyimpan tanggal yang diberikan kepada mereka. Tapi dua tanggal yang identik hanya membuktikan bahwa salinan itu setia pada SUMBER: jika tanggal sumber sudah salah, kedua kolom menunjukkan tanggal salah yang sama.

Ingin memverifikasi apa yang sebenarnya terjadi? Setelah migrasi, hubungkan ke tujuan dengan klien IMAP dan periksa INTERNALDATE secara langsung:

a1 SELECT INBOX
a2 FETCH 42 (INTERNALDATE)

Jika tanggal yang dikembalikan bukan tanggal email itu dikirim, lihat pesan yang sama di sumber: Anda akan menemukan tanggal salah yang sama di sana. Log itu tidak berbohong, ia hanya menyalin apa yang diberikan kepadanya.

Ini adalah salah satu aspek paling membuat frustrasi saat melakukan debug masalah tanggal: file log yang bersih, dua tanggal identik, dan tetap tanggal yang salah di Outlook, karena kesalahan itu sudah ada sebelum imapsync dijalankan.

Migrasi imapsync Skala Besar: Di Mana Masalah Tanggal Berlipat Ganda

Migrasi satu kotak surat dengan imapsync sudah menjengkelkan ketika tanggal rusak. Tapi MSP dan departemen TI yang menjalankan imapsync di ratusan kotak surat menghadapi skala masalah yang sama sekali berbeda.

Bayangkan skenario migrasi perusahaan yang khas. Anda memindahkan 200 kotak surat dari server Zimbra ke Microsoft 365. Anda menulis skrip wrapper yang melakukan loop melalui CSV daftar pengguna, memanggil imapsync untuk masing-masing. Migrasi berjalan selama akhir pekan. Senin pagi, Anda memiliki 200 kotak surat dengan tanggal salah, dan total sekitar 1,2 juta email yang menampilkan cap waktu migrasi.

Bisakah Anda menjalankan ulang imapsync untuk memperbaikinya? Secara teknis bisa, tapi imapsync akan melewati pesan yang sudah ada di tujuan (dirancang untuk bersifat idempoten). Anda memerlukan --delete2 untuk menghapus pesan di tujuan dan mentransfer ulang, yang berisiko pada kotak surat produksi. Dan jika tanggal sumber adalah masalahnya, jalan kedua hanya menyalin tanggal salah yang sama lagi.

Beberapa administrator mencoba pendekatan hibrida: menjalankan imapsync dengan --dry dahulu untuk menguji, lalu migrasi sungguhan. Tapi --dry hanya mensimulasikan transfer: ia menunjukkan tanggal yang akan diteruskan imapsync, bukan apakah itu tanggal email sebenarnya dikirim. Tidak ada yang memperingatkan Anda bahwa tanggal sumber sudah salah.

Perbaikan DIY dan Batasannya

Jika Anda mencari di forum dan mailing list (list imapsync-devel di SourceForge masih aktif sejak awal 2026), Anda akan menemukan saran mulai dari yang kreatif sampai yang berbahaya.

Sebagian orang menyarankan menggunakan Perl one-liner untuk memodifikasi INTERNALDATE langsung di server tujuan. Yang lain merekomendasikan mengekspor semua pesan ke format mbox, memanipulasi tanggalnya, lalu mengimpor ulang. Beberapa orang menulis skrip Python yang menggunakan imaplib untuk mengambil, memodifikasi, dan menyisipkan ulang pesan.

Semua pendekatan ini berbagi masalah fundamental yang sama. Bagaimana Anda menangani pesan bertanda tangan S/MIME tanpa merusak tanda tangannya? Bagaimana dengan struktur MIME multi-bagian dengan batas bersarang? Header non-ASCII yang dikodekan dengan RFC 2047? Pesan terenkripsi PGP yang isinya bahkan tidak bisa Anda periksa? Skrip yang menangani 50 pesan uji di lingkungan pengembangan akan tersendat pada kasus-kasus khusus di kotak surat produksi berisi 30.000 pesan.

Dan pertanyaan terbesar yang tidak ditanyakan siapa pun sampai terlambat: bagaimana Anda memverifikasi bahwa setiap pesan yang dimodifikasi masih utuh? Bahwa lampiran tidak rusak, bahwa threading masih berfungsi, bahwa spreadsheet 85 MB yang dikirim seseorang lewat email pada 2020 selamat dari manipulasi itu?

(Jika Anda pernah mencoba mem-parsing header email mentah di Perl, Anda tahu itu bukan kegiatan sore yang santai.)

Bagaimana Redate.io Memperbaiki Masalah Tanggal imapsync

Header Date: asli selalu tetap utuh setelah migrasi imapsync. imapsync mentransfer pesan mentah dengan setia; tanggal yang salah berada pada metadata yang diterima salinan itu, bukan pada pesannya. Header asli itulah yang membuat perbaikan menjadi mungkin.

Redate.io terhubung langsung ke kotak surat (Google Workspace, Microsoft 365, atau server IMAP apa pun), memindai email dengan anomali tanggal, dan menerapkan perbaikan metadata yang ditargetkan melalui pipeline analisis rantai header dan rekonstruksi tanggal milik sendiri. Redate.io tidak perlu tahu tool mana yang melakukan migrasi: ia menemukan email yang tanggal tampilannya tidak cocok dengan tanggal aslinya.

Setiap email yang diperbaiki diverifikasi satu per satu: integritas pesan, pelestarian lampiran, penempatan folder, threading, label. Email asli disimpan di folder cadangan Redate.io - Originals yang terlihat, dan tetap di sana sampai Anda menghapusnya sendiri. Jika ada yang terlihat salah, mengembalikan ke kondisi semula hanya perlu satu klik.

Pemindaian gratis terhubung ke kotak surat, mengidentifikasi setiap email dengan anomali tanggal, dan melaporkan jumlah persis serta biayanya. Tidak perlu kartu kredit, tidak perlu menginstal perangkat lunak. Untuk detail platform Anda:

Redate.io juga berfungsi pada migrasi yang terjadi berbulan-bulan atau bertahun-tahun lalu. Header Date: tidak kedaluwarsa, begitu juga kemampuan untuk memperbaiki apa yang salah.

Bermigrasi dengan imapsync dan terjebak dengan tanggal yang salah? Jalankan pemindaian gratis untuk melihat persis berapa banyak email yang terdampak.

imapsync Tidak Menyimpan Tanggal? Cara Memperbaiki