Masalahnya - semua email menampilkan tanggal yang sama
Setelah migrasi IMAP, pengguna membuka kotak masuk dan menemukan pemandangan yang mengkhawatirkan: setiap email menampilkan tanggal yang persis sama. Alih-alih tanggal pengiriman atau penerimaan asli, semua pesan membawa tanggal pelaksanaan migrasi. Bertahun-tahun korespondensi yang tampak tiba di hari yang sama.
Ini mimpi buruk bagi administrator IT. Tiket dukungan menumpuk, pengguna tidak bisa menemukan apa pun berdasarkan tanggal, dan urutan kronologis kotak masuk, sebenarnya, sudah hancur.
Seperti apa tampilannya di Outlook
Di Microsoft Outlook, kolom "Diterima" menampilkan tanggal migrasi untuk setiap email. Baik pesan dikirim tahun 2018 atau 2023, Outlook menampilkan tanggal yang sama, yaitu hari ketika alat migrasi memproses kotak surat. Kotak masuk, item terkirim, setiap folder terkena dampak. Pengguna yang bergantung pada pengurutan berdasarkan tanggal menemukan alur kerja mereka benar-benar rusak.
Seperti apa tampilannya di Apple Mail
Apple Mail di macOS dan iOS berperilaku serupa. Tanggal yang ditampilkan di samping setiap pesan mencerminkan cap waktu migrasi, bukan tanggal asli. Karena Apple Mail menggunakan metadata server IMAP untuk menentukan tanggal tampilan, masalah mendasar yang sama menghasilkan hasil visual yang sama. Saat menjelajahi kotak masuk, pengguna hanya melihat deretan tanggal yang identik.
Seperti apa tampilannya di Gmail (antarmuka web)
Antarmuka web Gmail menghadirkan situasi yang sedikit berbeda. Klien web Gmail biasanya menggunakan header "Date" dari email itu sendiri, jadi pesan mungkin muncul dengan tanggal yang benar di Gmail. Tapi INTERNALDATE IMAP tetap salah, yang berarti setiap klien IMAP yang terhubung ke akun Gmail tersebut (Outlook, Thunderbird, Apple Mail) akan menampilkan tanggal migrasi. Hasilnya? Kotak surat yang sama terlihat benar di satu klien tapi salah di klien lain.
Mengapa ini terjadi - penyebab teknis
Akar penyebabnya terletak pada cara alat migrasi IMAP menangani header email dan bagaimana klien email menentukan tanggal mana yang ditampilkan. Memahami ini memerlukan pandangan singkat ke protokol IMAP dan struktur header.
Cara alat migrasi IMAP menangani header
Ketika email dimigrasikan dari satu server ke server lain, alat migrasi mengunduh pesan mentah dari server sumber dan mengunggahnya ke server tujuan melalui perintah IMAP APPEND. Selama proses ini, protokol IMAP mewajibkan server tujuan untuk menambahkan header "Received" ke pesan. Header ini berisi cap waktu saat pesan dimasukkan ke server baru, yaitu tanggal migrasi.
Header "Received" yang merusak segalanya
Pesan email biasanya mengandung beberapa header "Received", masing-masing ditambahkan oleh server email yang menangani pesan selama pengiriman aslinya. Klien seperti Outlook menentukan "tanggal diterima" dengan membaca header "Received" terbaru, yang berada di bagian atas rantai. Ketika alat migrasi menambahkan header "Received" baru dengan cap waktu migrasi, header itu menjadi yang terbaru, dan klien email menampilkan tanggal tersebut alih-alih tanggal asli.
Ini bukan bug dari alat migrasi maupun klien email. Keduanya mengikuti standar IMAP dan email dengan benar. Masalahnya adalah standar-standar ini tidak pernah dirancang untuk migrasi massal, dan interaksi antara IMAP APPEND dan logika tampilan tanggal menghasilkan hasil yang tidak diinginkan ini.
INTERNALDATE vs header Date
Server IMAP menyimpan dua nilai tanggal berbeda untuk setiap pesan. Header "Date" adalah bagian dari pesan email itu sendiri, mencatat kapan pesan dibuat dan dikirim. INTERNALDATE adalah metadata yang disimpan oleh server IMAP, mewakili kapan pesan dikirimkan atau dimasukkan ke server tersebut.
Dalam praktiknya, beberapa alat migrasi mencoba mempertahankan INTERNALDATE asli dengan mengaturnya selama perintah APPEND. Tapi meskipun INTERNALDATE diatur dengan benar, header "Received" yang ditambahkan tetap menyebabkan masalah di klien yang memprioritaskan tanggal "Received" di atas INTERNALDATE.
Alat migrasi mana yang menyebabkan masalah ini?
Hampir semua alat migrasi IMAP dapat menyebabkan masalah ini. Persoalannya melekat pada protokol IMAP, bukan spesifik pada satu alat tertentu. Tapi beberapa alat lebih sering dikaitkan dengan masalah ini karena penggunaannya yang luas.
BitTitan MigrationWiz
BitTitan MigrationWiz adalah salah satu alat migrasi komersial paling populer yang digunakan oleh MSP dan konsultan IT. MigrationWiz menambahkan header "Received" yang mengandung "mx.migrationwiz.com" selama proses migrasi. Header ini menjadi yang terbaru dalam rantai, menyebabkan tanggal migrasi ditampilkan di Outlook dan klien IMAP lainnya. Lihat panduan terperinci untuk memperbaiki tanggal BitTitan di Outlook, Microsoft 365, Google Workspace, dan Exchange Online.
CloudM Migrate
CloudM Migrate (sebelumnya Cloud Migrator) banyak digunakan untuk migrasi Google Workspace. Seperti alat lainnya, CloudM menambahkan header "Received" sendiri saat penyisipan via IMAP. Email yang dimigrasikan dengan CloudM menampilkan tanggal migrasi di klien yang mengandalkan header "Received". Lihat panduan untuk memperbaiki tanggal CloudM di Gmail, Outlook, Google Workspace, dan Microsoft 365.
imapsync
imapsync adalah alat open source yang populer di kalangan administrator Linux dan penyedia hosting. Meskipun imapsync mencoba mempertahankan INTERNALDATE, server tujuan tetap menambahkan header "Received" selama operasi APPEND. FAQ imapsync mengakui keterbatasan ini tapi tidak menawarkan solusi bawaan untuk menghapus header yang ditambahkan setelah migrasi. Lihat panduan untuk memperbaiki tanggal imapsync di Outlook, Gmail, Microsoft 365, dan Google Workspace.
GSMMO (Migrasi Google Workspace)
Google Workspace Migration for Microsoft Outlook (GSMMO) adalah alat migrasi resmi Google untuk berpindah dari Exchange atau file PST Outlook ke Google Workspace. GSMMO dapat menghasilkan masalah tanggal yang sama, terutama ketika migrasi melibatkan tahap IMAP perantara. Lihat panduan untuk memperbaiki tanggal GSMMO di Outlook, Gmail, dan Apple Mail.
Exchange Admin Center (impor IMAP bawaan)
Exchange Admin Center dari Microsoft menyertakan fitur impor IMAP bawaan untuk migrasi ke Exchange Online (Microsoft 365). Alat migrasi bawaan ini menambahkan header "Received" selama impor, menyebabkan masalah tampilan tanggal yang sama. Lihat panduan untuk memperbaiki tanggal migrasi IMAP Exchange di Outlook dan OWA.
Salinan IMAP manual
Bahkan menyalin email secara manual antar server IMAP melalui klien seperti Thunderbird dapat menghasilkan masalah tanggal ini. Ketika klien email menyalin pesan via IMAP, server tujuan memperlakukannya sebagai penyisipan baru dan menambahkan header "Received" sendiri dengan cap waktu saat ini. Lihat panduan untuk memperbaiki tanggal salinan IMAP manual di Outlook, Gmail, Thunderbird, dan Apple Mail.
Mengapa solusi sementara yang umum tidak berhasil
Menghadapi masalah ini, pengguna dan administrator biasanya mencoba beberapa pendekatan sebelum menyadari bahwa tidak satu pun yang benar-benar menyelesaikan masalah.
"Urutkan berdasarkan tanggal kirim" - mengapa tidak cukup
Saran paling umum adalah beralih dari pengurutan berdasarkan tanggal "diterima" ke tanggal "kirim" di klien email. Ini memang mengubah urutan tampilan, tapi tidak memperbaiki data yang mendasarinya. Hasil pencarian tetap menampilkan tanggal yang salah. Integrasi kalender, alat kepatuhan, dan alur kerja otomatis yang bergantung pada tanggal penerimaan tetap bermasalah. Dan pengguna harus ingat mengubah pengaturan ini di setiap perangkat dan di setiap folder.
Migrasi ulang - mahal dan berisiko
Beberapa administrator mempertimbangkan menjalankan ulang migrasi, berharap menghindari masalah tanggal di percobaan kedua. Pendekatan ini mahal (500 hingga 5.000 EUR tergantung jumlah kotak surat), memakan waktu, dan berisiko. Migrasi kedua memperkenalkan masalah header "Received" yang sama, menggandakan risiko kehilangan data, dan memerlukan downtime signifikan. Migrasi ulang tidak menyelesaikan masalah tanggal kecuali alat migrasi dimodifikasi secara fundamental.
Pengeditan header manual - memerlukan akses server
Secara teknis, perbaikan melibatkan penghapusan header "Received" migrasi dari setiap email. Tapi melakukannya secara manual memerlukan akses langsung ke server, pengetahuan tentang struktur header email, dan scripting khusus. Untuk kotak surat dengan 10.000 email, pengeditan manual tidak praktis dan sangat rawan kesalahan. Email bertanda tangan S/MIME, pesan terenkripsi PGP, struktur multipart dengan batas MIME bersarang, masalah Content-Transfer-Encoding, header non-ASCII (RFC 2047), lampiran berukuran besar: masing-masing kasus ini dapat menyebabkan kerusakan data yang tidak dapat dibalik oleh skrip sederhana. Bagaimana Anda memastikan 10.000 email yang diperbaiki semuanya utuh? Tidak bisa, kecuali dengan sistem verifikasi yang dirancang khusus untuk itu.
Perbaikan sesungguhnya - memulihkan tanggal asli
Pendekatan yang benar adalah mengidentifikasi artefak migrasi dalam rantai header setiap email dan menerapkan koreksi yang ditargetkan untuk memulihkan urutan kronologis asli di semua klien email. Ini bukan sekadar operasi pengeditan header. Prosesnya melibatkan validasi kepatuhan RFC, pelestarian struktur pesan, dan pencocokan tanda tangan migrasi dari basis data profil alat yang diketahui.
Cara Redate.io memperbaiki masalah ini
Redate.io terhubung ke kotak surat (Google Workspace, Microsoft 365, atau server IMAP apa pun) dan menganalisis setiap email untuk mengidentifikasi pesan yang terpengaruh oleh header migrasi. Analisis ini gratis dan menunjukkan dengan tepat berapa banyak email yang terpengaruh sebelum pembayaran apa pun.
Untuk setiap email yang terpengaruh, mesin koreksi milik Redate.io memproses pesan melalui pipeline analisis multi-tahap. Mesin ini menerapkan pencocokan tanda tangan pada ratusan profil alat migrasi yang diketahui, yang dibangun dari pemrosesan volume besar data email nyata. Mesin ini menangani masalah encoding, struktur multipart, lampiran inline, dan puluhan kasus khusus yang akan menyebabkan skrip buatan sendiri merusak data (bukan penemuan yang ingin Anda alami di pagi Senin). Setiap email yang dikoreksi melewati pemeriksaan integritas sebelum diselesaikan. Pesan asli dipindahkan ke folder yang terlihat bernama "Redate.io - Originals" (tidak dihapus) dan disimpan selama 30 hari.
Hasilnya? Email menampilkan tanggal asli yang benar di semua klien. Pengurutan berfungsi kembali. Riwayat kronologis kotak surat dipulihkan.
Pertanyaan yang sering diajukan
Bisakah tanggal diperbaiki berbulan-bulan setelah migrasi?
Bisa. Header "Date" asli tersimpan di dalam pesan email terlepas dari kapan migrasi dilakukan. Redate.io dapat memperbaiki tanggal email berminggu-minggu, berbulan-bulan, atau bahkan bertahun-tahun setelah migrasi. Perbaikan berfungsi selama header asli email masih utuh.
Apakah memperbaiki tanggal akan menghapus email saya?
Tidak. Redate.io tidak pernah menghapus email apa pun. Pesan asli dipindahkan ke folder yang terlihat bernama "Redate.io - Originals" di dalam kotak surat, di mana pesan-pesan tersebut tetap dapat diakses selama 30 hari. Setiap email yang dikoreksi diverifikasi terhadap aslinya sebelum proses diselesaikan. Jika verifikasi gagal untuk suatu pesan, pesan asli tetap utuh.
Apakah ini berfungsi dengan kotak surat bersama?
Ya. Redate.io berfungsi dengan kotak surat bersama di Google Workspace dan Microsoft 365. Untuk kotak surat bersama, diperlukan akses tingkat administrator untuk mengotorisasi koneksi. Prosesnya identik dengan kotak surat individual: analisis, koreksi, verifikasi.
Siap memulihkan tanggal yang benar? Jalankan analisis gratis untuk mengetahui berapa banyak email yang terpengaruh di setiap kotak surat.