Migrasi cPanel: Email Salah Tanggal

Senin pagi yang menyakitkan

Anda baru saja menyelesaikan migrasi dari hosting bersama cPanel ke Google Workspace atau Microsoft 365. Prosesnya berjalan lancar, kotak surat sudah bisa diakses, para pengguna sudah bisa masuk. Lalu, sekitar pukul 09.15, tiket pertama masuk: "Email lama saya semua menampilkan tanggal yang sama, tanggal akhir pekan kemarin." Lalu tiket kedua. Lalu sepuluh tiket sekaligus.

Ini bukan bug terisolasi. Ini adalah akibat langsung dari cara migrasi cPanel menangani (atau lebih tepatnya, tidak menangani) metadata tanggal pada email.

cPanel, Roundcube, Horde: konteks IMAP yang unik

Hosting bersama cPanel pada dasarnya adalah server Linux yang menjalankan server IMAP (umumnya Dovecot) dengan Roundcube atau Horde sebagai antarmuka webmail. Tidak ada yang aneh di sini. Namun konteks ini memiliki beberapa kekhasan yang membuat migrasi ke platform enterprise lebih rumit dari yang terlihat.

Pertama, kotak surat cPanel sering menyimpan email selama bertahun-tahun, bahkan bisa sampai satu dekade. Klien yang menghosting domainnya di layanan hosting bersama sejak 2013 bisa memiliki arsip yang sangat dalam. Volume ini, dikombinasikan dengan cara migrasi dilakukan, menciptakan kondisi yang rawan untuk masalah tanggal.

Selain itu, alat yang digunakan untuk migrasi ini biasanya adalah alat bawaan cPanel (fitur "Migrations" di WHM), atau imapsync yang dijalankan via command line oleh penyedia hosting atau mitra IT, atau solusi umum seperti GSMMO untuk migrasi ke Google Workspace.

Mengapa tanggal rusak setelah migrasi cPanel

Untuk memahami masalahnya, Anda perlu memahami dua konsep berbeda: header Date: pada email dan INTERNALDATE IMAP.

Header Date: ditulis ke dalam isi mentah pesan saat pengiriman, sesuai RFC 2822. Header ini menunjukkan kapan email ditulis dan dikirim. Nilai ini tidak pernah berubah, kecuali ada manipulasi sengaja terhadap pesan tersebut.

INTERNALDATE, di sisi lain, adalah metadata yang diasosiasikan server IMAP dengan setiap pesan yang tersimpan. Nilainya terpisah dari konten pesan. Ketika email tiba secara normal di sebuah server, INTERNALDATE diatur berdasarkan header Received: pesan, atau berdasarkan tanggal pengiriman jika pesan dikirim langsung. Inilah nilai yang digunakan Outlook, Thunderbird, dan sebagian besar klien email untuk mengurutkan pesan.

Saat migrasi IMAP dilakukan, pesan disalin dari satu server ke server lain. Masalahnya: alat migrasi harus membuat ulang setiap pesan di server tujuan. Dan untuk banyak alat, INTERNALDATE pesan yang baru dibuat menggunakan tanggal migrasi, bukan tanggal asli pesan. Bersamaan dengan itu, header Received: yang dicap dengan tanggal migrasi ditambahkan di bagian atas rantai header, yang semakin membingungkan klien email yang menggunakannya untuk menentukan tanggal tampilan.

Hasilnya: email dari tahun 2019 tiba di Google Workspace dengan INTERNALDATE yang diatur ke hari migrasi, dan header Received: bertanggal kemarin. Outlook menampilkannya di kotak masuk seolah email itu baru saja datang. Seluruh kronologi arsip hancur.

Alat migrasi WHM / cPanel

Alat bawaan WHM untuk memigrasikan akun cPanel ke platform lain menghasilkan masalah ini hampir selalu ketika tujuan adalah server IMAP eksternal (Google Workspace, Microsoft 365). Alat ini menyalin konten Maildir ke server baru via IMAP APPEND tanpa mempertahankan INTERNALDATE asli. Akibatnya, setiap pesan mendapatkan timestamp dari saat operasi berlangsung.

imapsync dan migrasi manual dari cPanel

imapsync adalah alat yang andal, tetapi perilaku defaultnya tidak selalu mempertahankan tanggal. Tanpa parameter yang tepat (dan versi yang sesuai), alat ini bisa saja menyalin 40.000 pesan dengan memberikan semua pesan itu tanggal saat skrip dijalankan. (Omong-omong, jika Anda pernah membaca log imapsync baris per baris untuk mendiagnosis masalah tanggal di kotak surat dengan 25.000 pesan, Anda tahu itu pengalaman yang tidak ingin Anda ulangi.)

Tepatnya, imapsync memiliki opsi untuk mencoba mempertahankan tanggal, tetapi opsi-opsi ini berinteraksi secara berbeda tergantung server sumber dan tujuan, dan efektivitasnya tidak terjamin untuk semua konfigurasi cPanel / Dovecot.

GSMMO dan alat migrasi umum

Google Workspace Migration for Microsoft Outlook (GSMMO) dirancang untuk migrasi dari Outlook, bukan dari server IMAP langsung. Ketika digunakan untuk migrasi dari cPanel (melalui akun IMAP yang dikonfigurasi di Outlook), tanggal mengalami perlakuan yang sama: INTERNALDATE di Google Workspace diatur ke tanggal migrasi. Masalah GSMMO dan tanggal email bahkan didokumentasikan secara terpisah, begitu sering terjadi.

Klien email mana yang terpengaruh?

Kerusakan tanggal tidak termanifestasi dengan cara yang sama tergantung klien yang digunakan.

Outlook adalah klien yang paling terdampak. Outlook menggunakan INTERNALDATE (atau header Received: migrasi) sebagai kriteria pengurutan utama untuk folder. Setelah migrasi cPanel yang tidak tertangani dengan baik, kotak surat di Outlook bisa menampilkan ribuan email arsip dengan tanggal akhir pekan migrasi. Perbaikan tanggal imapsync di Outlook adalah salah satu koreksi yang paling sering diminta.

Gmail (Google Workspace) umumnya menampilkan tanggal dari header Date: di daftar email, tetapi pengurutan tetap bisa terpengaruh oleh INTERNALDATE dalam kasus tertentu. Pengguna melaporkan perilaku tidak konsisten dalam pencarian dan pengurutan berdasarkan tanggal.

Apple Mail dan Thunderbird memiliki perilaku yang lebih bervariasi, tetapi keduanya tidak kebal terhadap masalah ini, terutama ketika header Received: migrasi ada di bagian atas rantai header.

Kabar baik: tanggal asli masih ada

Inilah detail teknis yang mengubah segalanya. Header Date: asli pesan ditulis ke dalam isi mentah email. Migrasi tidak menyentuhnya. Ketika Anda membuka email yang terdampak dan melihat header mentahnya (di Gmail: "Tampilkan asli", di Outlook: File > Properti), Anda akan melihat Date: asli yang masih utuh, diikuti satu atau beberapa header Received: di mana yang pertama membawa tanggal migrasi.

Informasi ini selalu ada. Informasi ini bisa dimanfaatkan untuk memperbaiki metadata. Itulah tepatnya yang dilakukan mesin koreksi Redate.io.

Mengapa "memperbaiki sendiri" lebih berisiko dari yang terlihat

Godaannya memang besar. Masalahnya tampak sederhana: baca tanggal asli, perbaiki metadata, lanjut ke berikutnya. Tapi antara memahami mekanismenya dan memperbaiki 12.000 email di lingkungan produksi tanpa kehilangan satu pun, ada kesenjangan yang cukup besar.

Beberapa kenyataan yang biasanya tidak diantisipasi oleh skrip buatan sendiri:

Email bertanda tangan S/MIME atau terenkripsi PGP: perubahan apa pun pada struktur pesan akan membatalkan tanda tangan kriptografis. Email yang lolos verifikasi tanda tangan sebelum koreksi tidak akan lolos setelahnya. Pengguna di lingkungan yang membutuhkan kepatuhan regulasi (firma hukum, sektor keuangan, kesehatan) menemukan masalah ini di saat yang paling tidak tepat.
Header non-ASCII dan encoding RFC 2047: kotak surat cPanel mengumpulkan email selama bertahun-tahun dari berbagai klien email. Beberapa header berisi karakter yang dienkode sesuai RFC 2047. Skrip yang kurang tepat dalam merekonstruksi header bisa merusak encoding ini secara tidak terlihat.
Struktur MIME bersarang: email dengan tiga lampiran dan isi HTML alternatif memiliki struktur multipart yang kompleks. Kesalahan sekecil apapun pada batas MIME membuat pesan tidak bisa dibaca, atau lebih buruk: lampiran menghilang tanpa pesan error.
Kuota API dan rate limiting: Google Workspace dan Microsoft 365 memberlakukan batas ketat pada jumlah operasi IMAP per menit. Skrip yang tidak mengimplementasikan exponential backoff dengan benar akan memicu error 429 di jam 3 pagi, dan Anda bangun dengan migrasi yang setengah selesai tanpa tahu persis di mana prosesnya berhenti.
Tidak ada rollback: jika sesuatu berjalan salah di tengah proses, ke kondisi mana Anda akan kembali? Apakah email aslinya masih ada? Apakah ada duplikat? Redate.io menyimpan email asli di folder cadangan yang terlihat selama 30 hari, justru untuk menghindari situasi seperti ini.

Skrip yang bekerja pada 50 email uji di lingkungan pengembangan tidak akan tentu bekerja pada 18.000 pesan di kotak surat produksi yang diwarisi dari hosting cPanel sejak 2011.

Cara Redate.io memperbaiki tanggal setelah migrasi cPanel

Redate.io terhubung langsung ke kotak surat tujuan (Google Workspace via domain delegation, Microsoft 365 via Azure AD, atau server IMAP langsung) dan memulai dengan scan gratis untuk mengidentifikasi email yang metadata tanggalnya tidak konsisten dengan header Date: asli.

Pipeline analisis multi-tahap kemudian menerapkan pencocokan pola pada tanda tangan header Received: untuk mengidentifikasi mana yang diperkenalkan oleh alat migrasi (dan membedakannya dari header yang sah). Koreksi metadata yang ditargetkan dilakukan tanpa mengubah konten pesan: teks, lampiran, header asli, semuanya tetap utuh. Setiap email yang dikoreksi diverifikasi satu per satu sebelum operasi dikonfirmasi.

Untuk migrasi dari cPanel secara khusus, mesin mengenali tanda tangan khas dari migrasi Dovecot-ke-IMAP dan skrip imapsync, termasuk variasi konfigurasi yang umum digunakan oleh penyedia hosting bersama.

Panduan spesifik berdasarkan platform tujuan Anda

Tergantung platform tujuan migrasi cPanel Anda, panduan berikut menjelaskan langkah-langkah yang lebih rinci:

Anda sudah migrasi dari cPanel dan pengguna Anda melihat tanggal yang salah? Jalankan scan gratis di Redate.io untuk mengidentifikasi secara tepat berapa banyak email yang terdampak, tanpa perubahan apapun sebelum Anda menyetujuinya.

Email Salah Tanggal Setelah Migrasi cPanel