Hosting Bersama ke Microsoft 365: Masalah Tanggal Tersembunyi

Masalah yang tidak pernah ada yang beritahu Anda

Anda baru saja menyelesaikan migrasi email dari OVH, Infomaniak, Ionos, atau o2switch ke Microsoft 365. Alat migrasi di EAC (Exchange Admin Center) berjalan semalaman, semua lampu hijau, kotak surat sudah terisi penuh. Senin pagi, tiket pertama masuk: "Semua email lama saya bertanggal hari ini." Lalu tiket kedua. Lalu sepuluh tiket.

Ini bukan bug Microsoft 365. Bukan kebetulan juga. Ini adalah hasil mekanis dari migrasi IMAP, dan untuk kasus hosting bersama, masalahnya sering kali dua kali lebih parah dibanding migrasi biasa. Berikut penjelasannya.

Bagaimana IMAP mengelola tanggal (dan di mana semuanya berantakan)

Setiap email yang tersimpan di server IMAP memiliki dua jenis penanggalan yang berbeda. Di satu sisi, ada header Date: (didefinisikan oleh RFC 2822), yang ada di dalam isi pesan itu sendiri, menunjukkan kapan pesan tersebut dikirim atau diterima. Di sisi lain, ada INTERNALDATE, sebuah metadata di level server yang menunjukkan kapan pesan itu disimpan ke dalam kotak surat. Nilai inilah yang digunakan klien email seperti Outlook secara default untuk mengurutkan dan menampilkan email.

(Omong-omong, kalau Anda pernah mencoba membaca header mentah sebuah email di EAC, Anda tahu bahwa itu bukan bacaan yang menyenangkan. Ada mudah dua puluh sampai tiga puluh baris header sebelum sampai ke konten pesan.)

Ketika alat migrasi IMAP memindahkan pesan dari satu kotak ke kotak lain, alat tersebut harus membuat ulang INTERNALDATE di tujuan. Beberapa alat melakukannya dengan benar. Banyak yang tidak, atau melakukannya dengan keterbatasan tertentu. Dan server penerima punya andil tersendiri: Exchange Online, misalnya, akan tetap menyimpan tanggal aslinya jika alat migrasi mengirimkan tanggal itu, sehingga ketika tanggal yang tampil di Outlook salah, alat migrasinyalah yang patut dicurigai, bukan Microsoft 365.

Hasilnya: setiap email yang dimigrasikan terlihat seolah "diterima" pada hari migrasi dilakukan. Tidak peduli email itu aslinya dari tahun 2019.

Skenario dua tahap: mengapa hosting bersama memperburuk segalanya

Di sinilah situasinya menjadi benar-benar bermasalah untuk migrasi dari hosting bersama seperti OVH, Infomaniak, Gandi, Ionos, atau o2switch.

Hosting-hosting ini umumnya menggunakan server bersama berbasis Postfix, Dovecot, atau cPanel dengan konfigurasi IMAP standar. Banyak UKM yang sudah menumpuk email bertahun-tahun di sana, kadang sejak 2010 atau 2012. Ketika mereka memutuskan beralih ke Microsoft 365, prosesnya sering terjadi dalam dua tahap.

Tahap 1: kerusakan pertama (bahkan sebelum masuk Microsoft 365)

Dalam banyak kasus, email-email tersebut sudah mengalami migrasi pertama sebelumnya. Perusahaan pernah berganti hosting satu atau dua kali selama bertahun-tahun: dari Gandi ke OVH di 2018, lalu dari OVH ke Infomaniak di 2022, misalnya. Setiap transfer IMAP bisa saja mengganti INTERNALDATE asli dengan tanggal transfer itu, jika alat yang dipakai tidak meneruskan tanggal asli, dan beberapa alat juga meninggalkan header migrasi tersendiri yang dicap dengan tanggal itu.

Ketika email-email itu tiba di Microsoft 365, mereka sudah membawa "luka" tersendiri. Header Date: asli tetap utuh (karena ada di dalam isi pesan, tidak ada yang mengubahnya), tapi metadata tanggal sudah terganggu sejak tahap pertama.

Tahap 2: kerusakan kedua saat pindah ke Exchange Online

Alat migrasi IMAP dari EAC, atau alat pihak ketiga seperti BitTitan MigrationWiz yang dikonfigurasi dalam mode IMAP, lalu memproses email-email yang sudah rusak tadi. Jika alat itu juga tidak meneruskan tanggal asli setiap email, Exchange Online akan mencatat email itu dengan tanggal transfer, dan itulah "tanggal terima" yang akhirnya ditampilkan Outlook.

Sebuah email yang dikirim pada Maret 2017 bisa membawa dua lapisan tanggal yang salah: header migrasi yang ditinggalkan oleh perpindahan di 2022, dan tanggal terima dari migrasi ke Microsoft 365 di 2024. Outlook menampilkan 2024. Pengguna melihat 2024. Padahal itu salah di dua level sekaligus.

Sebenarnya, untuk lebih tepatnya, tidak selalu header Received: terbaru yang digunakan. Outlook menentukan tanggal tampilan dari kombinasi antara INTERNALDATE yang dicatat Exchange Online dan header yang ada. Tapi setiap kali alat migrasi tidak meneruskan tanggal asli, perpindahan ke Exchange Online menambahkan lapisan kesalahan baru di atas yang lama.

Alat migrasi dan hosting: kombinasi yang berisiko

Beberapa kombinasi yang sering muncul dalam migrasi dari hosting bersama:

• OVH / Infomaniak / Ionos + alat IMAP dari EAC: alat bawaan Microsoft memang praktis, tapi sudah dikenal tidak mempertahankan tanggal dengan benar saat migrasi IMAP dalam volume besar.
• cPanel (o2switch, LWS, dll.) + BitTitan MigrationWiz mode IMAP: MigrationWiz dalam mode IMAP menambahkan header migrasinya sendiri. Hasilnya sudah terdokumentasi, antara lain di halaman perbaiki tanggal migrasi BitTitan di Microsoft 365.
• Gandi / Mailcow + imapsync: imapsync adalah alat yang andal, tapi penanganan INTERNALDATE-nya bergantung pada konfigurasi. Tanpa opsi yang tepat, tanggal tidak dipertahankan. Lihat juga imapsync tidak menyimpan tanggal.
• Semua migrasi manual dengan drag-and-drop di Outlook: jika seseorang menyalin seluruh folder dengan cara drag-and-drop antara dua akun yang dikonfigurasi di Outlook, INTERNALDATE setiap email akan ditimpa dengan tanggal penyalinan. Tanpa pengecualian.

Kesamaan dari semua metode ini: semuanya menghasilkan email di Exchange Online dengan tanggal yang ditampilkan di Outlook tidak lagi mencerminkan kenyataan.

Mengapa "memperbaiki sendiri" adalah ide buruk dalam skala besar

Memahami masalahnya adalah satu hal. Memperbaiki 8.000 email yang tersebar di 40 kotak Exchange Online, dengan struktur folder yang kompleks, email bertanda tangan S/MIME, lampiran berukuran besar, dan thread percakapan yang bersarang, itu hal yang sama sekali berbeda.

Skrip PowerShell yang tampak bekerja pada sepuluh email percobaan bisa saja gagal secara diam-diam pada email nomor 4.237 karena batas MIME yang rusak atau header yang diencode dengan RFC 2047 (format =?UTF-8?B?...?= untuk karakter non-ASCII dalam nama pengirim). Tanpa mekanisme verifikasi per pesan, Anda tidak akan tahu. Anda hanya akan kehilangan satu email begitu saja.

Risiko nyata dari pendekatan DIY pada jenis migrasi ini:

• Pesan duplikat jika logika penyisipan gagal di tengah jalan
• Lampiran hilang jika struktur multipart direkonstruksi dengan keliru
• Thread percakapan rusak di Outlook (percakapan bergantung pada header References: dan In-Reply-To: yang bisa ikut berubah)
• Error 429 (Too Many Requests) dari API Microsoft Graph pada jam 3 pagi, yang menghentikan proses tanpa rollback
• Tidak ada cara mudah untuk memverifikasi bahwa semua 8.000 koreksi berhasil diterapkan dengan benar

Dan dalam kasus khusus migrasi dari hosting bersama, ada kesulitan tambahan: email membawa beberapa lapisan header Received: parasit, bukan hanya satu. Skrip sederhana yang menghapus "header Received: terakhir" tidak cukup. Dibutuhkan analisis rantai header secara menyeluruh untuk mengidentifikasi header mana yang berasal dari migrasi mana, dan mana yang benar-benar mewakili tanggal penerimaan asli.

Apa yang Redate.io lakukan secara berbeda

Setiap pengguna masuk dengan akun Microsoft miliknya sendiri, dan Redate.io membuka kotak surat itu dengan izin yang diberikan lewat proses masuk tersebut. Tidak ada portal, tidak ada aplikasi yang perlu didaftarkan. Pemindaian awal gratis: Redate.io mengidentifikasi semua email yang tanggal tampilannya tidak sesuai dengan tanggal sebenarnya, dan memberikan estimasi yang akurat per kotak surat.

Proses koreksi menggunakan mesin proprietary yang menganalisis rantai header lengkap setiap pesan, apa pun alat migrasi yang digunakan, dan merekonstruksi metadata tanggal dengan benar, bahkan ketika beberapa lapisan kerusakan saling tumpang tindih. Setiap email yang dikoreksi diverifikasi satu per satu. Email asli tidak pernah dihapus. Semuanya tetap di folder cadangan yang terlihat di kotak surat Anda sendiri, sampai Anda menghapusnya sendiri.

Untuk migrasi dari hosting bersama, pipeline analisis multi-tahap Redate.io secara eksplisit menangani skenario kerusakan ganda: alat ini tidak hanya melihat header Received: terakhir, melainkan menelusuri seluruh riwayat untuk menemukan tanggal penerimaan yang sebenarnya. Lihat juga cara memperbaiki tanggal setelah migrasi Microsoft 365 secara umum, dan panduan khusus tentang INTERNALDATE yang rusak di IMAP untuk memahami mekanisme dasarnya.

Sebelum atau sesudah migrasi: dua momen untuk bertindak

Dua situasi, dua pendekatan.

Anda belum migrasi. Kabar baiknya: ada cara untuk meminimalkan kerusakan. Beberapa alat migrasi (MigrationWiz dalam mode Exchange, CloudM dengan opsi yang tepat) lebih baik dalam mempertahankan tanggal dibanding yang lain. Tapi bahkan dalam skenario terbaik pun, migrasi dari hosting bersama tanpa riwayat yang bersih kemungkinan besar akan meninggalkan jejak. Rencanakan penggunaan Redate.io setelah migrasi, sebelum menyerahkan kotak surat kepada pengguna.

Anda sudah migrasi dan tiket sudah berdatangan. Redate.io memperbaiki kotak surat yang sudah ada di Microsoft 365, tidak peduli sudah berapa lama migrasinya dilakukan. Pemindaian akan memberikan gambaran akurat tentang kondisi nyata setiap kotak surat sebelum ada intervensi apapun. Baca juga checklist migrasi email untuk menghindari masalah yang sama di masa mendatang.

Anda sudah migrasi dari OVH, Infomaniak, Ionos, atau o2switch ke Microsoft 365 dan tanggalnya salah? Buat akun Redate.io untuk memindai kotak surat Anda secara gratis dan melihat persis seberapa besar dampaknya sebelum memutuskan langkah selanjutnya.