eM Client: Tanggal Email Salah Setelah Import PST atau Thunderbird

Gejalanya: semua email menampilkan tanggal yang sama

Anda baru saja selesai mengimpor file PST ke eM Client, atau baru saja migrasi dari Thunderbird ke kotak surat baru. Proses impor berjalan tanpa pesan error. Tapi saat membuka kotak masuk, ada yang janggal: ratusan, bahkan ribuan email semuanya menampilkan tanggal yang sama, yaitu tanggal hari impor dilakukan. Email dari tahun 2019 seolah baru diterima kemarin. Kontrak yang ditandatangani tiga tahun lalu muncul seakan baru saja tiba.

Reaksi pertama yang wajar adalah menyalahkan eM Client. Pengaturan salah, kolom urutan keliru, bug tampilan... Lalu Anda mencari di menu preferensi. Beralih antara "Tanggal Diterima" dan "Tanggal Kirim". Tidak ada yang berubah. Atau lebih tepatnya, sesuatu berubah, tapi akar masalahnya tetap tidak terselesaikan.

Itu karena masalahnya bukan ada di eM Client. Masalahnya ada di metadata server.

Penyebab sebenarnya: INTERNALDATE IMAP tertimpa saat impor

Untuk memahami apa yang terjadi, kita perlu turun satu level dan melihat bagaimana protokol IMAP menyimpan email.

Setiap pesan di server IMAP memiliki dua jenis tanggal yang berbeda:

• Header Date: (didefinisikan oleh RFC 2822): ini adalah tanggal yang ditulis pengirim ke dalam pesan saat pengiriman. Nilainya terenkapsulasi di dalam isi pesan, secara teori tidak bisa diubah dari luar.
• INTERNALDATE: sebuah metadata server, terpisah dari isi pesan, yang merepresentasikan tanggal saat pesan ditempatkan ke dalam kotak surat. Nilai inilah yang digunakan klien email secara prioritas untuk mengurutkan dan menampilkan email.

Saat impor PST atau migrasi dari Thunderbird, alat impor (baik modul bawaan eM Client, alat pihak ketiga, maupun salinan IMAP manual) menempatkan pesan-pesan ke server IMAP tujuan. Dan di sinilah masalahnya: jika alat tersebut tidak secara eksplisit mempertahankan INTERNALDATE asli pada saat penempatan, server akan otomatis menetapkan INTERNALDATE saat ini, yaitu tanggal dan waktu impor dilakukan.

Hasilnya: 8.000 email arsip sejak 2017, semuanya dicap "diterima" pada saat migrasi Anda.

(Omong-omong, jika Anda pernah mencoba membaca header mentah email menggunakan Tampilkan Sumber di eM Client, Anda bisa melihat bahwa header Date: asli masih ada, utuh. Itu tanda bahwa masalahnya berasal dari INTERNALDATE server, bukan dari isi pesan itu sendiri.)

Mengapa mengubah kolom urutan tidak membantu

Kebingungan ini muncul dari perbedaan yang jarang diketahui orang. Di eM Client, seperti di Outlook atau Thunderbird, biasanya ada dua kolom tanggal:

• "Tanggal Diterima" (atau "Tanggal Tiba"): berbasis pada INTERNALDATE server.
• "Tanggal" atau "Tanggal Kirim": berbasis pada header Date: dari pesan.

Banyak admin yang menemukan ini dan mengira sudah menemukan solusinya: beralih ke "Tanggal Kirim", dan masalah pun hilang secara visual di eM Client. Tapi itu tidak sepenuhnya benar.

Faktanya, meskipun Anda mengurutkan berdasarkan tanggal kirim di eM Client, masalah ini tetap ada di semua klien lain dan semua antarmuka lain yang mengakses kotak surat yang sama. Jika pengguna Anda membuka email dari OWA, dari Outlook di kantor, dari aplikasi Gmail di ponsel, atau dari klien IMAP mana pun, mereka tetap akan melihat tanggal impor. Pengaturan urutan di eM Client hanya berlaku di eM Client, dan tidak memengaruhi metadata yang tersimpan di server.

Selain itu, di Microsoft 365 dan Google Workspace, tampilan web bawaan mengurutkan berdasarkan INTERNALDATE. Anda tidak bisa mengubah perilaku ini dari sisi klien.

Mengurutkan berdasarkan tanggal kirim bukan solusi. Itu hanya plester yang menutupi masalah nyata tanpa memperbaikinya.

Kasus khusus impor PST

Impor file PST layak dibahas tersendiri. File PST (Personal Storage Table) adalah format proprietary Microsoft yang menyimpan email, kontak, dan kalender secara lokal. Saat Anda mengimpor PST ke eM Client, ada dua skenario yang mungkin terjadi:

• Impor lokal ke akun IMAP: eM Client membaca PST dan mendorong pesan-pesan ke server IMAP tujuan. Jika tanggal penempatan tidak dipertahankan, INTERNALDATE akan tertimpa. Ini adalah kasus yang paling umum, dan di sinilah tanggal-tanggal menjadi rusak.
• Impor ke folder lokal: pesan-pesan tetap berada di mesin lokal, di luar server. INTERNALDATE tidak ada dalam konteks ini, dan eM Client dapat menampilkan tanggal Date: dari pesan. Masalah tanggal lebih jarang terjadi di sini, tapi juga kurang praktis penggunaannya.

Untuk Thunderbird, situasinya serupa. Jika Anda menggunakan fungsi impor bawaan eM Client (yang membaca profil Thunderbird), atau jika Anda menyalin folder mbox melalui IMAP, pesan-pesan ditempatkan ulang ke server tanpa jaminan pelestarian INTERNALDATE. Dan server yang menerima pesan tanpa instruksi tanggal eksplisit pada INTERNALDATE akan selalu memberi cap waktu saat penerimaan.

Platform mana yang terdampak?

Masalahnya identik di semua platform tujuan, karena ini adalah perilaku standar protokol IMAP:

• Microsoft 365 / Exchange Online: INTERNALDATE tertimpa pada setiap impor yang tidak menggunakan perintah IMAP APPEND dengan parameter tanggal eksplisit. Hal yang sama berlaku untuk migrasi dari Exchange on-premise.
• Google Workspace: perilaku yang sama. Email yang diimpor melalui eM Client atau alat pihak ketiga menampilkan tanggal impor di Gmail dan di antarmuka administrasi.
• Hosting IMAP standar (OVH, Infomaniak, Ionos, dan sejenisnya): tidak ada penanganan khusus untuk tanggal saat menerima pesan melalui APPEND. INTERNALDATE akan menjadi tanggal penempatan.

Seorang klien menghubungi kami setelah berhasil memigrasikan lebih dari seratus kotak surat dari Exchange 2013 ke Microsoft 365, menggunakan eM Client sebagai alat transisi untuk beberapa akun VIP. Hasilnya: kotak surat yang dimigrasi dengan benar melalui MigrationWiz tampak baik-baik saja, tapi kotak surat yang melewati eM Client semuanya memiliki tanggal impor. Tidak perlu dikatakan bahwa pengguna yang bersangkutan tidak senang dengan hal itu.

Mengapa skrip buatan sendiri tidak akan menyelesaikan ini dengan mudah

Secara teknis, seseorang yang memahami protokol IMAP mungkin akan berpikir untuk menulis skrip guna memperbaiki INTERNALDATE. Header Date: asli ada di sana, utuh di setiap pesan. Tinggal membacanya dan merekonstruksi metadata server sesuai isinya, bukan?

Secara teori, ya. Dalam praktiknya, ini adalah ladang ranjau.

Pertama, kasus-kasus tepi bertumpuk dengan cepat di kotak surat produksi. Pesan yang ditandatangani secara digital dengan S/MIME sangat sensitif terhadap manipulasi struktur apa pun. Begitu juga pesan terenkripsi PGP. Email dengan lampiran berukuran besar, batas MIME yang tidak standar, atau encoding Content-Transfer-Encoding yang tidak biasa bisa rusak secara diam-diam jika penanganannya tidak teliti. Skrip yang berhasil pada 50 email uji tidak akan berjalan andal pada kotak surat berisi 20.000 pesan dengan riwayat 6 tahun.

Kemudian, ada soal manajemen kuota API. Di Microsoft 365, batas rate pada API Graph atau EWS pukul 3 pagi saat memproses batch koreksi 8.000 pesan itu bisa dikelola. Tapi tidak bisa berjalan sendiri tanpa pengawasan. Skrip yang tidak diawasi yang menemukan error 429 Too Many Requests pada pesan ke-3741 mungkin akan melanjutkan, mungkin tidak. Dan Anda belum tentu tahu pesan mana saja yang sudah diproses.

Dan yang terpenting: bagaimana cara memverifikasi bahwa setiap email yang diperbaiki masih utuh setelah diproses? Skrip buatan sendiri umumnya tidak memiliki mekanisme verifikasi per pesan. Redate.io melakukan ini secara otomatis, untuk setiap pesan.

Memperbaiki tanggal dari sumbernya dengan Redate.io

Redate.io menyerang masalah di mana masalah itu berada: di level metadata server, bukan di level klien email.

Prosesnya dimulai dengan fase pemindaian gratis. Redate.io terhubung ke kotak surat yang bersangkutan (Microsoft 365 melalui Azure AD, Google Workspace melalui delegasi domain, atau IMAP langsung untuk hosting standar) dan mengidentifikasi email yang metadata tanggalnya tidak konsisten dengan isi pesan. Anda melihat hasilnya sebelum membayar apa pun.

Koreksi menggunakan mesin proprietary yang menganalisis rantai header lengkap setiap pesan, menerapkan pencocokan pola terhadap ratusan tanda tangan alat impor yang dikenal (termasuk perilaku spesifik eM Client, Thunderbird, dan impor PST), dan merekonstruksi metadata tanggal secara terarah tanpa mengubah isi pesan, lampirannya, maupun struktur MIME-nya.

Setiap email yang diperbaiki diverifikasi satu per satu. Pesan asli disimpan dalam folder cadangan yang terlihat selama 30 hari, sesuatu yang tidak pernah dilakukan skrip buatan sendiri secara default.

Harganya sederhana: pembayaran satu kali per kotak surat, berdasarkan volume email yang perlu diperbaiki. Tidak ada langganan, tidak ada biaya berulang. Kunjungi halaman pendaftaran untuk melihat detailnya.

Untuk migrasi berikutnya: apa yang perlu diperiksa

Jika Anda sedang merencanakan migrasi dan ingin menghindari masalah ini sejak awal, poin kontrolnya sederhana: apakah alat yang Anda gunakan secara eksplisit mempertahankan INTERNALDATE saat menempatkan pesan ke server tujuan?

Untuk impor PST ke Microsoft 365, alat yang disertifikasi Microsoft (seperti MigrationWiz dalam mode natifnya, atau alat migrasi Exchange Online) umumnya menangani pelestarian ini. Untuk impor manual melalui eM Client atau Thunderbird, hal itu jarang terjadi. Periksa dokumentasi alat Anda sebelum menjalankan impor pada kotak surat produksi.

Checklist migrasi email yang baik selalu menyertakan verifikasi tanggal pasca-migrasi pada sampel kotak surat. Jika ingin lebih jauh, checklist migrasi email kami membahas poin ini secara mendetail.

Untuk admin yang secara rutin menangani migrasi klien, artikel tentang perbaikan tanggal email dari sisi MSP dan artikel tentang cara kerja INTERNALDATE IMAP memberikan gambaran yang lebih lengkap tentang masalah ini.

Tanggal email Anda rusak setelah impor eM Client? Jalankan pemindaian gratis di Redate.io untuk mengukur sejauh mana masalahnya sebelum memutuskan langkah selanjutnya.