Tanggal Email Salah Setelah Migrasi Zoho ke Microsoft 365

Apa yang Terjadi di Kotak Surat Anda

Migrasi domain Anda dari Zoho Mail ke Microsoft 365 baru saja selesai. Infrastruktur Exchange Online sudah berjalan, kotak surat sudah diprovisikan, catatan MX sudah diperbarui. Lalu, Senin pagi, seorang pengguna membuka Outlook dan melihat semua email dari 2021 menampilkan tanggal hari ini. Pengguna lain menemukan pesan-pesan dari tahun lalu muncul di paling atas kotak masuk, seolah baru saja tiba. Tiket-tiket mulai berdatangan.

Ini bukan bug Outlook. Bukan juga masalah khusus Zoho. Ini terjadi ketika alat migrasi tidak meneruskan tanggal asli setiap email. Memahami dengan tepat mengapa hal ini terjadi adalah langkah pertama untuk memperbaikinya dengan benar.

Akar Masalah Teknis: INTERNALDATE dan Header Received

Email yang tersimpan di server IMAP terdiri dari dua hal yang berbeda: isi pesan mentah (header RFC 2822, badan pesan, lampiran) dan metadata penyimpanan yang dikelola server IMAP, termasuk INTERNALDATE. Metadata inilah yang digunakan klien email untuk menampilkan dan mengurutkan pesan.

Header Date: yang ada di dalam pesan mentah (RFC 2822) merepresentasikan tanggal pesan dibuat atau dikirim oleh pengirim. INTERNALDATE, sebaliknya, adalah tanggal server IMAP menerima atau menyimpan pesan tersebut. Pada server yang sehat, kedua nilai ini biasanya berdekatan. Setelah migrasi, ceritanya berbeda.

Bagaimana Migrasi IMAP Bisa Merusak Tanggal

Ketika alat migrasi (Zoho Migration Wizard, imapsync, BitTitan, atau alat lainnya) memindahkan pesan dari Zoho Mail ke Exchange Online, prosesnya melalui protokol IMAP. Alat tersebut terhubung ke Zoho, mengambil pesan, lalu menyisipkannya ke Exchange Online via perintah IMAP APPEND. Di sinilah masalah mulai muncul.

Exchange Online menyimpan tanggal yang diberikan kepadanya: ketika alat migrasi meneruskan INTERNALDATE asli setiap pesan melalui perintah APPEND, salinannya menyimpan tanggal itu. Beberapa alat migrasi melakukannya. Yang lain tidak, atau melakukannya dengan tidak tepat, sehingga Exchange Online menetapkan saat penyisipan, yaitu tanggal migrasi, sebagai INTERNALDATE.

Hasilnya: baik email yang dikirim tahun 2019 maupun 2022, INTERNALDATE-nya kini menunjuk ke minggu migrasi. Outlook membaca nilai ini sebagai prioritas utama. Urutan tampilan pun kacau.

Perilaku Khusus Zoho Migration Wizard

Zoho menyediakan alat migrasinya sendiri untuk meninggalkan platformnya: Zoho Migration Wizard. Alat ini praktis untuk migrasi sederhana, tapi ada perilaku yang sudah tercatat di forum-forum administrator: alat ini tidak selalu meneruskan INTERNALDATE asli dengan benar saat menyisipkan pesan ke server tujuan.

Lebih tepatnya: ketika Zoho Migration Wizard memang meneruskan tanggal asli, Exchange Online menyimpannya dan Outlook menampilkan tanggal yang benar. Email yang menampilkan tanggal migrasi adalah email yang tanggalnya tidak diteruskan.

Admin yang menggunakan alat IMAP generik seperti imapsync untuk migrasi keluar dari Zoho bisa menghadapi masalah yang sama: imapsync menyalin tanggal yang dimiliki server sumber untuk setiap pesan, jadi tanggal yang salah di sumber menjadi tanggal yang salah di tujuan. (Omong-omong, jika Anda pernah membaca log imapsync baris demi baris pada pukul 2 pagi untuk mencari satu kesalahan sinkronisasi, Anda tahu betul ini alat yang kuat tapi tidak terlalu ramah untuk kasus-kasus tepi.)

Mengapa Outlook Menampilkan Tanggal yang Salah

Outlook tidak hanya menggunakan header Date: untuk menampilkan tanggal email. Dalam sebagian besar tampilan, INTERNALDATE yang disediakan server IMAP/Exchange-lah yang digunakan, terutama untuk pengurutan kotak masuk. Header Date: asli memang ada di dalam pesan, utuh, tapi diabaikan demi INTERNALDATE.

Itulah mengapa opsi "Urutkan berdasarkan Tanggal Pengiriman" di Outlook tidak benar-benar menyelesaikan masalah. Memang menampilkan tanggal yang berbeda, tapi perilaku pengurutan tetap tidak stabil tergantung versi Outlook dan mode tampilan (percakapan dikelompokkan atau tidak). Pengurutan berdasarkan tanggal pengiriman bukan solusi. Itu hanya plester yang akan lepas begitu klien diperbarui.

Seberapa Luas Masalah Ini Sebenarnya

Pada migrasi Zoho ke Microsoft 365 berukuran menengah, mudah sekali ada 50.000 hingga 500.000 pesan yang terdampak, tergantung usia kotak surat dan ukuran organisasi. Setiap email yang dipindahkan selama jendela migrasi membawa tanggal yang rusak, sehingga masalah ini langsung terlihat oleh pengguna begitu pertama kali membuka Outlook.

Folder Terkirim sering menjadi yang paling bermasalah. Seorang sales yang mencari penawaran yang dikirim Maret 2022 harus menyisir ratusan email yang semuanya menampilkan tanggal migrasi. Dampak operasionalnya nyata, bukan sekadar tampilan.

Dan berbeda dari yang mungkin Anda bayangkan, masalah ini tidak hilang seiring waktu. INTERNALDATE ditetapkan pada saat penyisipan. Nilainya tidak memperbaiki dirinya sendiri. Tanpa tindakan aktif, email-email tersebut akan mempertahankan tanggal yang rusak selamanya.

Mengapa Memperbaiki Sendiri Lebih Berisiko dari yang Terlihat

Godaannya dapat dipahami: karena header Date: asli masih ada di dalam pesan, tinggal... perbaiki metadatanya. Secara teori masuk akal. Dalam praktiknya, pada kotak produksi dengan 80.000 email, ini adalah operasi yang bisa berjalan sangat buruk.

Berikut beberapa kasus tepi yang kemungkinan besar tidak akan ditangani dengan baik oleh skrip buatan sendiri:

• Email bertanda tangan S/MIME, di mana tanda tangan mencakup seluruh header. Mengubah apa pun pada struktur pesan akan membatalkan tanda tangan kriptografis.
• Pesan terenkripsi PGP, di mana isinya bersifat buram dan setiap manipulasi pada amplop MIME dapat merusak pesan.
• Header non-ASCII yang dienkode dengan RFC 2047 (nama pengirim dengan karakter khusus), yang rusak jika skrip tidak menangani encoding dengan benar.
• Lampiran yang dienkode base64 dengan baris yang tidak diakhiri dengan benar, batas MIME yang tidak standar, atau struktur multipart bertingkat.
• Email tanpa header Date: yang valid (ini ada, terutama dalam ekspor Zoho yang lama), di mana skrip harus memutuskan apa yang harus dilakukan.

Skrip yang berjalan baik pada 50 email pengujian tidak akan berjalan baik pada kotak produksi Zoho yang diekspor dengan bertahun-tahun histori. Dan bagaimana cara memverifikasi, pesan per pesan, bahwa setiap koreksi utuh dan lampiran tidak terpotong? Proses verifikasi setidaknya sama rumitnya dengan koreksi itu sendiri.

Ada juga soal kuota. API Exchange Online melalui Microsoft Graph menerapkan batas laju yang ketat (error 429 Too Many Requests yang sudah tidak asing lagi). Batch yang tidak dibatasi kecepatannya pada 100.000 pesan bisa memicu pemblokiran sementara atau error diam-diam yang sulit didiagnosis setelahnya. Tanpa mekanisme pemulihan dari kegagalan, Anda harus mulai dari awal lagi.

Cara Redate.io Memperbaiki Tanggal Setelah Migrasi Zoho

Setiap pengguna masuk dengan akun Microsoft miliknya sendiri, dan Redate.io membuka kotak surat itu dengan akses yang diberikan oleh proses masuk tersebut, tanpa portal dan tanpa aplikasi yang perlu didaftarkan. Pemindaian awal gratis: Redate.io mengidentifikasi kotak surat yang terdampak dan memperkirakan volume email dengan tanggal yang salah, dengan membandingkan INTERNALDATE terhadap nilai-nilai yang ada di rantai header pesan.

Koreksi menggunakan mesin proprietary yang menganalisis rantai header lengkap setiap pesan, tanpa perlu mengetahui alat mana yang melakukan migrasi (Zoho Migration Wizard, imapsync, atau lainnya), dan merekonstruksi metadata tanggal melalui pipeline validasi multi-tahap. Setiap email yang dikoreksi diverifikasi satu per satu: integritas konten, pelestarian lampiran, kepatuhan RFC. File asli tidak pernah dihapus oleh Redate.io: tetap berada dalam folder cadangan yang terlihat di kotak surat Anda sendiri, sampai Anda menghapusnya sendiri.

Tidak ada migrasi ulang. Tidak ada downtime. Pengguna tetap bisa menggunakan Outlook sementara koreksi berjalan di latar belakang.

Harga berupa pembayaran satu kali berdasarkan volume, tanpa langganan. Detail tersedia langsung di situs web.

Skenario Terkait yang Perlu Diketahui

Jika Anda mengelola beberapa migrasi sekaligus, atau jika Anda adalah MSP yang mengadministrasi klien yang meninggalkan Zoho, perlu diketahui bahwa masalah yang sama terjadi pada migrasi dari platform lain ke Exchange Online. Mekanismenya identik: salinan mendapatkan tanggal yang diteruskan oleh alat migrasi, apa pun sumbernya.

Untuk migrasi dari Google Workspace, dari Exchange on-premises, atau melalui alat seperti BitTitan MigrationWiz atau CloudM, artikel-artikel khusus di blog Redate.io menjelaskan perilaku spesifik setiap alat. Lihat artikel Tanggal Email Rusak Setelah Migrasi ke Exchange Online untuk gambaran umum semua skenario yang berakhir di tenant ini.

Jika migrasi Anda melibatkan kotak surat bersama atau resource Exchange (ruang rapat, peralatan), masalahnya sama, dan alat koreksi yang sama berlaku. Panduan perbaikan tanggal migrasi Exchange IMAP di Outlook di situs Redate.io menjelaskan langkah-langkah koneksi ke tenant Anda.

Untuk tim yang menggunakan imapsync khusus untuk keluar dari Zoho, halaman imapsync Tidak Menyimpan Tanggal? mendokumentasikan opsi konfigurasi imapsync dan dari mana sebenarnya tanggal yang salah itu berasal.

Tanggal migrasi Zoho Anda masih muncul di Outlook? Pindai kotak surat Anda secara gratis di Redate.io untuk mengukur seberapa luas masalahnya sebelum memutuskan tindakan apa yang perlu diambil.