Migrasi iCloud ke Office 365: Tanggal Email Salah

Skenario migrasi yang selalu merusak tanggal email

Anda baru saja selesai memindahkan mailbox iCloud ke Office 365. Email sudah ada, folder sudah tertata, semuanya terlihat beres. Senin pagi, keluhan pertama masuk: "Semua email lama saya menampilkan tanggal hari ini." Lalu keluhan kedua. Lalu sepuluh.

Ini bukan bug yang terjadi secara kebetulan. Migrasi dari iCloud Mail ke Office 365 adalah salah satu skenario yang paling banyak didokumentasikan sebagai penyebab kerusakan tanggal email, karena alasan teknis yang sangat spesifik, berkaitan dengan perilaku Apple Mail, protokol IMAP, dan cara Microsoft 365 memproses pesan yang masuk.

Mengapa migrasi iCloud ke Office 365 merusak tanggal

Untuk memahami masalahnya, kita perlu membedakan tiga hal yang sering dikacaukan, bahkan oleh admin IT berpengalaman sekalipun: header Date:, INTERNALDATE IMAP, dan tanggal pembuatan file.

Header Date: (RFC 2822)

Setiap email memiliki header Date: yang menunjukkan kapan pesan dikirim. Header ini tertanam di dalam isi mentah pesan dan, secara teori, tidak pernah berubah. Inilah tanggal "asli" dalam arti paling harfiah.

INTERNALDATE IMAP

Protokol IMAP (didefinisikan dalam RFC 3501) mengaitkan setiap pesan dengan metadata tersendiri yang disebut INTERNALDATE. Nilai inilah yang digunakan sebagian besar klien email untuk mengurutkan dan menampilkan pesan di kotak masuk, bukan header Date:. Outlook, khususnya, sangat bergantung pada INTERNALDATE untuk tampilan dan pengurutan.

Masalahnya? Ketika alat migrasi menyalin email dari satu server IMAP ke server lain, idealnya INTERNALDATE ini harus dipertahankan. Dalam praktiknya, hal itu tidak selalu terjadi.

Perilaku khusus Apple Mail

Apple Mail, saat menyinkronkan pesan dari iCloud, terkadang menggunakan tanggal pembuatan file di sisi server sebagai referensi untuk INTERNALDATE. Ini bukan bug dalam arti ketat, melainkan interpretasi spesifikasi IMAP yang berbeda dari klien lain. (Omong-omong, jika Anda pernah mencoba men-debug masalah INTERNALDATE dengan membaca RFC IMAP mentah, Anda tahu bahwa spesifikasinya memang memberi cukup banyak ruang interpretasi di bagian ini.)

Hasilnya: saat Anda mengekspor atau memigrasikan dari iCloud melalui Apple Mail, INTERNALDATE pesan bisa jadi sudah salah bahkan sebelum tiba di Office 365.

Tiga metode migrasi iCloud dan jebakannya

Migrasi IMAP langsung

Metode paling umum adalah mengonfigurasi iCloud sebagai sumber IMAP dan Office 365 sebagai tujuan, lalu menggunakan alat migrasi seperti imapsync, MigrationWiz, atau alat buatan sendiri. Alat tersebut terhubung ke kedua server dan menyalin pesan-pesan.

Masalahnya ada dua. Pertama, server IMAP Apple memiliki batas kecepatan yang memaksa alat untuk berhenti sejenak, menciptakan jeda waktu di mana koneksi terputus dan disambungkan kembali, yang bisa menghasilkan INTERNALDATE yang tidak diharapkan. Kedua, setiap pesan yang disalin melalui IMAP APPEND ke Exchange Online secara default mendapat tanggal penyisipan yang sesuai dengan momen migrasi, kecuali jika alat tersebut secara eksplisit meneruskan INTERNALDATE asli dalam perintah penyisipannya.

Beberapa alat melakukan ini dengan benar. Yang lain tidak secara konsisten. Dan pada mailbox dengan 40.000 pesan, bahkan tingkat kesalahan 2% saja berarti 800 email dengan tanggal yang salah.

Untuk migrasi via imapsync, lihat juga: perbaiki tanggal migrasi imapsync di Microsoft 365.

Ekspor .mbox atau .eml lalu impor

Sebagian pengguna mengekspor email iCloud mereka melalui Apple Mail dalam format .mbox, lalu mencoba mengimpornya ke Outlook. Ini metode manual yang menghasilkan hasil yang tidak konsisten.

Format .mbox mengodekan email sebagai urutan pesan teks. Tanggal memang ada dalam header Date: masing-masing pesan, tetapi baris pemisah antar pesan ("From ") menyertakan tanggal yang bisa diinterpretasikan sebagai tanggal pembuatan oleh beberapa alat impor. Outlook, saat mengimpor .mbox yang sudah dikonversi ke .pst, terkadang menggunakan tanggal pemisah tersebut daripada header Date: pesan itu sendiri.

Drag-and-drop via Outlook

Inilah metode yang paling banyak menimbulkan kerusakan. Pengguna mengonfigurasi kedua akun di Outlook (iCloud dan Office 365), lalu melakukan drag-and-drop pesan dari satu folder ke folder lain. Terlihat mudah. Hasilnya bisa jadi bencana untuk tanggal email.

Ketika Outlook memindahkan pesan melalui drag-and-drop antara dua akun IMAP, sebenarnya Outlook membuat file .EML baru, menyisipkannya ke akun tujuan, lalu menghapus yang asli. File baru ini mewarisi tanggal pembuatan file Windows, yaitu tepat saat drag-and-drop dilakukan. Header Date: asli masih ada di dalam isi pesan, tetapi INTERNALDATE yang tersimpan di server Exchange Online sesuai dengan tanggal proses pemindahan. Outlook kemudian menampilkan tanggal migrasi tersebut untuk semua pesan yang dipindahkan.

Tepatnya, perilaku ini bervariasi tergantung versi Outlook. Sejak pembaruan Outlook pada akhir 2023, perilakunya sedikit membaik untuk beberapa skenario, tetapi drag-and-drop antar akun tetap menjadi sumber kerusakan tanggal yang terdokumentasi.

Apa yang ditampilkan Office 365 dan Outlook

Exchange Online menyimpan email beserta INTERNALDATE-nya. Outlook Desktop membaca INTERNALDATE ini untuk menampilkan tanggal di kolom "Diterima" dan untuk mengurutkan kotak masuk. Jika INTERNALDATE sudah ditimpa selama migrasi, Outlook menampilkan tanggal migrasi, titik.

Outlook Web App (OWA) melakukan hal yang sama. Tidak ada "tampilan alternatif" yang menunjukkan tanggal asli dari header Date:. Apa yang terlihat di kolom tanggal adalah INTERNALDATE.

Header Date: asli masih ada, utuh, bisa dibaca jika Anda menampilkan header mentah sebuah pesan. Tapi tidak ada tampilan normal yang menunjukkannya. Inilah inti frustrasi dari masalah ini: informasi yang benar memang ada, hanya saja tidak bisa diakses tanpa koreksi teknis.

Apa yang tidak bisa diselesaikan oleh dukungan Microsoft

Jika Anda membuka tiket ke Microsoft Support untuk masalah ini, kemungkinan besar Anda akan mendapat: konfirmasi bahwa tanggal yang ditampilkan sesuai dengan INTERNALDATE yang tersimpan, saran untuk memeriksa pengaturan pengurutan di Outlook, dan mungkin pengalihan ke alat migrasi yang Anda gunakan.

Ini bukan niat buruk. Microsoft memang tidak memiliki alat bawaan untuk memperbaiki INTERNALDATE ribuan pesan yang sudah masuk ke Exchange Online secara retroaktif. Proses koreksi membutuhkan akses ke setiap pesan secara individual, analisis header-nya, dan rekonstruksi metadata tanggal, yang berada di luar cakupan dukungan standar.

Dukungan iCloud, di sisi lain, menganggap pesan sudah diekspor dengan benar dan masalahnya ada di sisi tujuan. Kedua pihak saling lempar tanggung jawab, sementara pengguna berhadapan dengan 12.000 email bertanggal hari migrasi.

Masalah skala

Memahami mengapa tanggal rusak adalah satu hal. Memperbaikinya secara manual pada mailbox produksi adalah hal lain sama sekali.

Beberapa admin IT mencoba membuat skrip untuk koreksi ini. Konsep dasarnya tidak terlalu sulit dibayangkan, tetapi pelaksanaannya pada volume nyata menimbulkan masalah yang tidak ditangani dengan baik oleh skrip buatan sendiri:

• Email yang ditandatangani S/MIME atau dienkripsi dengan PGP tidak bisa dimodifikasi tanpa membatalkan tanda tangan kriptografisnya
• Pesan dengan struktur multipart/alternative yang kompleks (HTML + teks biasa + lampiran bersarang) sangat rapuh untuk dimanipulasi
• Header yang dikodekan non-ASCII (RFC 2047, khususnya untuk karakter Jepang, Arab, atau Sirilik) bisa rusak oleh alat yang tidak menangani encoding ini dengan benar
• Kuota API Microsoft Graph dan batas kecepatan Exchange Online (error 429 Too Many Requests) akan menghentikan skrip yang tidak dirancang untuk menangani exponential backoff
• Skrip yang berjalan lancar pada 500 email uji coba bisa berhenti di tengah malam pada pesan ke-8.000 dari mailbox nyata, tanpa mekanisme pemulihan

Dan pertanyaan yang paling kritis: bagaimana memverifikasi bahwa setiap email yang sudah dikoreksi tetap utuh setelah proses koreksi? Bahwa lampirannya masih ada? Bahwa thread diskusinya tidak rusak? Skrip buatan sendiri umumnya tidak melakukan verifikasi semacam itu.

Cara Redate.io menangani migrasi iCloud ke Office 365

Redate.io terhubung langsung ke Office 365 melalui izin Microsoft 365 (Azure AD), tanpa memerlukan akses ke server iCloud. Email sudah berada di Exchange Online pada saat Redate mulai bekerja.

Mesin koreksi Redate menganalisis rantai header setiap pesan untuk mengidentifikasi tanggal asli, dengan membedakan header Received: yang ditambahkan saat migrasi dari metadata tanggal yang sah. Analisis ini mencakup pencocokan pola terhadap tanda tangan alat migrasi yang dikenal, sehingga header yang tidak relevan dapat diidentifikasi bahkan ketika tidak langsung terlihat.

Setiap email yang dikoreksi diverifikasi satu per satu setelah diproses. Original disimpan dalam folder cadangan yang terlihat selama 30 hari, sesuatu yang tidak dilakukan skrip buatan sendiri secara default. Scan awal gratis dan memungkinkan Anda mengukur secara tepat berapa banyak email yang terpengaruh sebelum memutuskan untuk melakukan koreksi.

Redate juga mendukung koreksi setelah migrasi dari Google Workspace ke Microsoft 365 maupun dari cPanel. Lihat misalnya: perbaiki tanggal email setelah migrasi Microsoft 365 atau tanggal email rusak setelah migrasi ke Exchange Online.

Scan dulu, baru koreksi

Langkah awal yang disarankan untuk setiap migrasi iCloud ke Office 365 yang menghasilkan tanggal salah: jalankan scan gratis Redate.io pada mailbox yang terpengaruh. Scan ini mengidentifikasi secara tepat berapa banyak email yang memiliki INTERNALDATE mencurigakan dan di folder mana saja lokasinya.

Prosesnya memakan waktu antara 12 hingga 45 menit tergantung volume, dan memberikan gambaran jelas tentang seberapa luas masalahnya sebelum ada intervensi apa pun. Bagi MSP yang mengelola beberapa mailbox sekaligus setelah migrasi, scan massal ini mencegah koreksi dilakukan pada mailbox yang sebenarnya tidak membutuhkannya.

Jika tanggal email Anda salah setelah migrasi dari iCloud, mulai dengan scan gratis di Redate.io untuk mengukur skala masalah pada mailbox Office 365 Anda.