Perbaiki Tanggal Migrasi imapsync di Microsoft 365

Memigrasikan ke Microsoft 365 dengan imapsync terdengar masuk akal. Alat ini gratis, dapat discrip, dan menangani transfer IMAP-ke-IMAP dengan baik di kebanyakan skenario. Tetapi Exchange Online bukan "kebanyakan skenario."

Gateway IMAP Exchange Online adalah lapisan kompatibilitas yang dipasang pada sistem yang dirancang di seputar EWS dan MAPI. Ketika imapsync mendorong pesan melalui gateway ini melalui protokol transfer email standar, pesan memasuki jalur transportasi penuh Exchange Online, jalur yang sama yang memproses email masuk dari internet. Jalur tersebut menambahkan header transportasi, menjalankan pemeriksaan Data Loss Prevention, menerapkan aturan kepatuhan, dan menambahkan header Received baru dengan momen tepat pesan mengenai server. Flag --syncinternaldates? Jalur transportasi Exchange Online tidak peduli. INTERNALDATE ditimpa agar sesuai dengan stempel waktu pengiriman.

Ini bukan bug yang berencana diperbaiki Microsoft. Ini adalah cara arsitektur Exchange Online bekerja. Jalur transportasi memperlakukan setiap APPEND sebagai pengiriman pesan baru, titik. Baik Anda memigrasikan 500 email atau 500.000, setiap satu pesan mendapatkan tanggal migrasi yang sama dicap ke header dan metadata-nya.

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. Pencocokan pola terhadap tanda tangan migrasi spesifik imapsync mengidentifikasi header Received mana yang ditambahkan selama migrasi versus mana yang termasuk rantai pengiriman asli. Setiap pesan dikoreksi dan diverifikasi secara individual, dengan pesan asli dipertahankan di folder cadangan. Paket Enterprise menangani kotak surat hingga 100.000 email, dan administrator dapat memproses beberapa kotak surat dari satu dasbor.