Perbaiki Tanggal Migrasi imapsync di Microsoft 365

Memigrasikan ke Microsoft 365 dengan imapsync terdengar masuk akal. Alat ini gratis, dapat digunakan lewat skrip, dan menangani transfer IMAP-ke-IMAP dengan baik di kebanyakan skenario. Tetapi di Microsoft 365, satu detail menentukan tanggal yang akhirnya melekat pada setiap email.

Exchange Online tetap menyimpan tanggal yang diberikan kepadanya: ketika imapsync menulis pesan melalui IMAP, ia meneruskan tanggal internal setiap email bersamanya (--syncinternaldates aktif secara default), dan salinan tersebut mempertahankan tanggal itu. Namun, yang diteruskan imapsync adalah tanggal yang disimpan server ASAL untuk setiap pesan, bukan tanggal email tersebut dikirim. Pada kotak surat yang sehat, kedua tanggal itu cocok. Pada kotak surat yang sudah pernah dimigrasikan sebelumnya atau dipulihkan dari cadangan, server asal bisa jadi menyimpan tanggal dari operasi sebelumnya itu, dan imapsync menyalinnya begitu saja.

Ini bukan bug di Microsoft 365 maupun di imapsync. Setiap salinan membawa dengan setia tanggal yang diberikan kepadanya. Jika tanggal itu sudah salah di sumbernya, baik Anda memigrasikan 500 email atau 500.000, setiap email yang terpengaruh menampilkan tanggal operasi sebelumnya itu, bukan tanggal saat email diterima.

Bayangkan Anda memberitahu direktur IT bahwa migrasi yang Anda jalankan selama akhir pekan baru saja meratakan 6 tahun riwayat email menjadi satu tanggal. Itulah kenyataan yang dihadapi administrator setelah migrasi imapsync ke Microsoft 365. Dan tidak seperti Google Workspace (di mana klien web Gmail dapat menyembunyikan masalah), Microsoft 365 menampilkan tanggal yang salah di mana-mana, baik Outlook desktop, OWA, maupun Outlook mobile. Tidak ada jalan keluar sisi klien.

Di Microsoft 365, kerusakannya total dan terlihat. Setiap klien, baik Outlook for Windows, Outlook for Mac, OWA, maupun Outlook mobile di iOS dan Android, menampilkan stempel waktu migrasi. Pengguna tidak dapat mengurutkan berdasarkan tanggal, tidak dapat menemukan email secara kronologis, tidak dapat memercayai hasil pencarian yang memfilter berdasarkan rentang tanggal. Kotak surat dengan 80.000 email yang semuanya menampilkan "12 November 2024" secara fungsional rusak untuk pekerjaan sehari-hari.

Implikasi kepatuhannya lebih buruk. Exchange Online Protection, Microsoft Purview, dan kebijakan retensi semuanya mengindeks stempel waktu pengiriman yang terkorupsi. Kebijakan retensi yang disetel untuk menghapus email lebih lama dari 7 tahun beroperasi pada tanggal yang salah, yang berarti email dari 2018 yang seharusnya mendekati penghapusan kini tampak berasal dari 2024. Organisasi yang tunduk pada regulasi GDPR, HIPAA, atau peraturan OJK di Indonesia menghadapi risiko regulasi nyata ketika retensi email mereka tidak dapat dipercaya. Dan jika permintaan penahanan hukum masuk untuk "semua email dari Q3 2023," tanggal yang terkorupsi berarti Purview tidak mengembalikan apa pun, karena menurut metadata, tidak ada email yang ada dari periode tersebut.

Redate.io terhubung ke Microsoft 365 dan menerapkan analisis rantai header serta proses rekonstruksi metadata tanggal pada setiap pesan yang terpengaruh. Redate tidak perlu mengetahui alat apa yang melakukan migrasi: Redate menemukan email yang tanggal tampilannya tidak sesuai dengan tanggal aslinya. Setiap pesan dikoreksi dan diverifikasi secara individual, dengan pesan asli dipertahankan di folder cadangan. Tidak ada batasan ukuran kotak surat: kotak surat dengan 100.000 email diperbaiki sama seperti kotak surat lainnya.