CloudM Migrate: Cara Memperbaiki Tanggal Email Salah

Masalah Tanggal CloudM Migrate yang Tidak Diperingatkan Siapa pun

CloudM Migrate menyelesaikan tugasnya. Dashboard menampilkan 100% selesai, semua pengguna berhasil dimigrasi, nol kesalahan. Anda menutup tiket proyek dan beralih ke klien berikutnya.

Lalu seminggu kemudian, direktur IT menelepon. "Kenapa setiap email di kotak masuk saya menampilkan tanggal 2 April?"

Bukan sebagian email. Semuanya. Lima tahun korespondensi klien, dokumen hukum, catatan HR, pesanan pembelian dari 2020, semuanya menampilkan tanggal ketika CloudM menjalankan migrasi. Pesan ada di sana, konten utuh, lampiran baik-baik saja. Tapi tanggal salah di setiap email.

Ini bukan bug CloudM. Dokumentasi dukungan CloudM sendiri mengakui hal ini secara terbuka. Masalahnya terletak di persimpangan antara cara alat migrasi mentransfer pesan dan cara server email tujuan memproses metadata email masuk. Tapi mengetahui hal itu tidak membantu klien Anda yang kotak masuknya sekarang tidak bisa diurutkan.

Bagaimana CloudM Sebenarnya Mentransfer Pesan Email

CloudM Migrate terhubung ke platform sumber dan tujuan melalui API masing-masing. Untuk Google Workspace, itu berarti akun layanan dengan delegasi tingkat domain (dikonfigurasi di Google Admin Console di bawah Keamanan > Kontrol API). Untuk Microsoft 365, menggunakan Exchange Web Services atau Microsoft Graph API, tergantung jalur migrasi.

Ketika CloudM membaca pesan dari sumber, ia mendapatkan konten RFC 2822 lengkap, termasuk semua header asli dan isi pesan. Header Date: asli (yang dicap oleh server email pengirim saat email pertama kali dikirim) datang tanpa diubah. Begitu juga semua header Received: asli yang melacak jalur pengiriman pesan.

Masalah terjadi saat salinan ditulis. Tujuan mempertahankan tanggal yang diberikan kepadanya: Microsoft 365 dan Gmail mempertahankan tanggal asli jika salinan membawanya. Jika tidak, salinan itu mendapatkan momen penyisipan sebagai tanggalnya. Dan di Google Workspace, setiap pesan yang ditulis melalui Gmail API juga mendapatkan header Received: baru yang bertanggal momen penyisipan.

Begini isi header salah satu email tersebut yang masih tersisa setelah migrasi CloudM ke Microsoft 365:

Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

Header Date: asli dari 2019 masih ada, begitu juga rantai header Received: asli. Tapi di Microsoft 365, tanggal yang ditampilkan Outlook sebagai tanggal diterima adalah catatan kotak surat itu sendiri tentang kapan setiap email tiba: jika CloudM tidak meneruskan tanggal asli, catatan itu menunjukkan 2 April 2026.

Pengaturan "Strip Received Headers" di CloudM

CloudM menawarkan pengaturan untuk mengatasi masalah ini. Di Pengaturan Lanjutan platform tujuan, di bawah Opsi Pesan, ada tombol "Strip Received Headers". Ketika diaktifkan, CloudM menghapus header received sebelum menyisipkan pesan dan menggantinya dengan satu header yang cocok dengan header Date: email.

Kedengarannya seperti menyelesaikan semuanya, kan? Tidak juga.

Pertama, Anda harus tahu tentang pengaturan ini sebelum menjalankan migrasi. Kebanyakan admin menemukan masalah tanggal setelah migrasi selesai. Pada titik itu, pesan sudah berada di tujuan dengan tanggal yang salah. Menjalankan ulang CloudM dengan pengaturan diaktifkan hanya membuat duplikat, tidak memperbaiki yang sudah ada.

Kedua, pengaturan ini memiliki keterbatasan serius ketika tujuannya adalah Google Workspace. Dokumentasi Google sendiri mengonfirmasi: Gmail selalu menulis ulang header Received: pada pesan yang disisipkan melalui API, mencapnya dengan cap waktu penyisipan. Ini adalah batasan tingkat platform yang tidak bisa ditimpa oleh CloudM. Bahkan dengan "Strip Received Headers" diaktifkan, Google Workspace menambahkan header Received: sendiri dengan tanggal migrasi.

Untuk tujuan Microsoft 365, pengaturan ini kurang berpengaruh: Microsoft 365 mempertahankan tanggal yang diberikan kepadanya, sehingga yang menentukan tanggal yang ditampilkan adalah apakah CloudM meneruskan tanggal asli setiap email.

Migrasi CloudM Mana yang Merusak Tanggal (dan Mana yang Tidak)

Tidak setiap migrasi CloudM menghasilkan tanggal yang salah. Hasilnya tergantung pada kombinasi sumber-tujuan dan jalur API spesifik yang digunakan CloudM:

• Google Workspace ke Microsoft 365: Tanggal rusak. CloudM membaca melalui Gmail API dan menulis ke Exchange, dan setiap email mendapatkan tanggal salinan tersebut.
• Microsoft 365 ke Google Workspace: Tanggal rusak. Bahkan dengan Strip Received Headers, API Google menulis ulang header Received dengan tanggal penyisipan. Dokumentasi dukungan CloudM menyebutnya "batasan platform yang ketat".
• Google Workspace ke Google Workspace: Tanggal rusak. Pergantian domain, konsolidasi tenant, merger akuisisi: setiap pesan yang ditulis melalui Gmail API mendapatkan header Received: bertanggal migrasi.
• Exchange on-premises ke Microsoft 365: Semuanya bergantung pada tanggal yang diteruskan CloudM, baik salinan itu melalui IMAP maupun EWS.
• Sumber IMAP generik ke tujuan apa pun: Aturan yang sama berlaku: ketika CloudM terhubung ke server IMAP generik sebagai sumber, salinan menunjukkan tanggal migrasi setiap kali tanggal asli tidak diteruskan ke tujuan.

Bagian yang rumit? Dashboard migrasi CloudM tidak menandai semua ini. Bar progres terisi, kolom status bertuliskan "Selesai", jumlah item cocok. Dari perspektif CloudM, migrasi berhasil. Dan secara teknis memang berhasil. Pesan ditransfer. Hanya tanggalnya yang tidak selamat dari perjalanan.

CloudM Terkelola dan Self-Service: Masalah Tanggal yang Sama

CloudM menawarkan dua model deployment. Versi SaaS (CloudM Migrate yang di-host) berjalan sepenuhnya di infrastruktur CloudM. Versi self-hosted memungkinkan Anda men-deploy server migrasi primer dan sekunder di jaringan Anda sendiri, Google Cloud, Azure, atau AWS.

Beberapa MSP berasumsi opsi self-hosted memberikan kontrol lebih atas penanganan tanggal karena Anda mengelola server migrasi secara langsung. Tidak. Yang menentukan tanggal adalah apa yang diteruskan mesin migrasi bersama setiap pesan, dan mesin itu sama di mana pun ia berjalan. Entah farm migrasi Anda berjalan di cloud CloudM atau di Azure VM Anda sendiri, hasilnya untuk tanggal tetap sama.

CloudM juga menawarkan "Serviced Migration" yang dikelola penuh di mana tim mereka menangani proyek dari awal sampai akhir. Hasil yang sama untuk tanggal. Rekayasanya identik, hanya tangan di keyboard yang berbeda.

Komplikasi Header Date yang Tidak Valid

Ada perilaku lain yang spesifik CloudM yang membuat keadaan lebih buruk. Ketika CloudM menemukan email sumber dengan header Date: yang tidak sesuai RFC 822 (zona waktu dengan format salah, hari dalam seminggu hilang, format tidak standar), CloudM memodifikasi header untuk memastikan pesan bisa dimigrasi.

Ini berarti beberapa email kehilangan bahkan referensi tanggal asli mereka. Header Date: yang dimodifikasi mungkin sama sekali tidak cocok dengan tanggal pengiriman yang sebenarnya. Dokumentasi dukungan CloudM menyebutkan ini sebagai perilaku yang diketahui di bawah "Kemungkinan Perubahan pada Item yang Dimigrasi" tapi tidak menentukan apa yang menjadi tanggal yang dimodifikasi.

Untuk kotak surat dengan 12.000 pesan yang terakumulasi selama delapan tahun, Anda mungkin memiliki ratusan email dengan header Date yang sedikit tidak standar (terutama pesan dari server email yang lebih tua, sistem otomatis, atau pengirim internasional dengan perbedaan format zona waktu). Setelah modifikasi CloudM, ditambah salinan yang tidak membawa tanggal asli, pesan-pesan ini berakhir dengan tanggal yang tidak ada hubungannya dengan kenyataan.

Mengapa Perbaikan Manual Tidak Berskala Setelah CloudM

Bisakah Anda memperbaikinya sendiri? Secara teknis, header Date: asli masih tertanam di sebagian besar pesan (kecuali yang dimodifikasi CloudM untuk kepatuhan RFC). Beberapa admin telah mencoba menulis skrip untuk memperbaiki tanggal setelah migrasi CloudM.

Realitas pendekatan itu adalah sebagai berikut. Anda perlu terhubung ke ribuan kotak surat potensial, masing-masing dengan ribuan pesan. Untuk setiap email, Anda perlu mengurai rantai header lengkap, mengidentifikasi header Received: mana yang ditambahkan CloudM atau server tujuan, menangani kasus tepi (pesan bertanda tangan S/MIME di mana modifikasi header merusak tanda tangan, konten terenkripsi PGP, struktur MIME multi-bagian dengan batas bersarang, header non-ASCII berkode RFC 2047 dari pengirim Jepang atau Korea), dan semua itu tanpa kehilangan satu lampiran pun atau merusak utas email.

Skrip yang bekerja pada 50 email uji dari kotak surat bersih tidak akan bertahan menghadapi lingkungan produksi dengan 40.000 pesan selama satu dekade. Apa yang terjadi ketika Anda menemukan email 47 MB dengan enam lampiran bersarang? Bagaimana dengan batas kecepatan API (250 unit kuota Google per pengguna per detik, pembatasan Microsoft sekitar 10.000 permintaan per 10 menit)? Apa rencana rollback Anda ketika sesuatu berjalan salah di pesan nomor 8.347?

Dan pertanyaan sebenarnya yang tidak ditanyakan kebanyakan admin sampai terlambat: bagaimana Anda memverifikasi bahwa setiap pesan yang diperbaiki benar-benar utuh?

Memperbaiki Tanggal Migrasi CloudM dengan Redate.io

Redate.io terhubung langsung ke kotak surat yang terdampak (Google Workspace, Microsoft 365, atau IMAP) dan memindai email yang tanggal tampilannya tidak sesuai dengan tanggal aslinya. Pemindaian gratis dan memakan waktu beberapa menit per kotak surat, menampilkan jumlah pasti pesan yang terdampak sebelum komitmen apa pun.

Koreksi menggunakan mesin analisis rantai header proprietary, dan mesin ini tidak perlu mengetahui alat mana yang melakukan migrasi. Redate.io melakukan koreksi metadata yang ditargetkan tanpa mengubah konten pesan, melestarikan lampiran, utas, label, folder, dan tanda tangan digital. Setiap pesan yang dikoreksi melalui verifikasi individual, memeriksa integritas pesan terhadap aslinya sebelum proses berlanjut.

Email asli disimpan di folder cadangan Redate.io - Originals yang tetap terlihat sampai Anda menghapusnya sendiri. Jika ada yang perlu di-rollback, aslinya ada di sana dalam kotak surat, bukan terkubur di arsip eksternal.

Untuk MSP yang menggunakan CloudM di lingkungan klien, Redate.io menangani koreksi multi-kotak surat dengan verifikasi per pesan yang sama baik Anda memperbaiki 1 kotak surat maupun 500. Masalah tanggal yang ditinggalkan CloudM tidak harus menjadi fitur permanen lingkungan email klien Anda.

Panduan Khusus Platform untuk Migrasi CloudM

Proses koreksi beradaptasi dengan platform tujuan. Redate.io menangani spesifik setiap platform secara otomatis, tapi untuk detail tentang pengaturan Anda:

• Perbaiki tanggal migrasi CloudM di Gmail
• Perbaiki tanggal migrasi CloudM di Outlook
• Perbaiki tanggal migrasi CloudM di Google Workspace
• Perbaiki tanggal migrasi CloudM di Microsoft 365

Untuk penjelasan lebih mendalam tentang mengapa ini terjadi di semua alat migrasi, bukan hanya CloudM, lihat mengapa email menampilkan tanggal salah setelah migrasi.

Bermigrasi dengan CloudM dan terjebak dengan tanggal salah di setiap email? Jalankan pemindaian gratis untuk melihat persis berapa banyak pesan yang terdampak dan berapa biaya perbaikannya.