Outlook: Tanggal Terima IMAP vs Tanggal Kirim Setelah Migrasi

Gejala yang sudah terlalu familiar

Anda baru saja selesai migrasi IMAP ke Microsoft 365 atau Google Workspace. Senin pagi, tiket dukungan mulai berdatangan: "Semua email saya punya tanggal yang sama", "Riwayat email saya berantakan", "Saya tidak bisa menemukan apa pun di kotak masuk". Anda membuka Outlook, dan memang benar, ribuan email menampilkan tanggal akhir pekan kemarin. Bukan tanggal saat email itu dikirim. Melainkan tanggal saat migrasi berlangsung.

Ini bukan bug Outlook. Ini adalah konsekuensi langsung dari cara kerja protokol IMAP dan alat migrasi. Tapi untuk memahami alasannya, kita perlu membuka kap mesinnya.

Tiga tanggal dalam satu email

Sebuah email lebih kompleks dari yang terlihat. Ada header, isi pesan, lampiran... dan beberapa cap waktu yang berbeda yang hidup berdampingan. (Omong-omong, kalau Anda pernah mencoba membaca header mentah sebuah email, Anda tahu itu bukan bacaan santai.)

Header Date: (RFC 2822)

Ini adalah tanggal yang dimasukkan pengirim ke dalam pesannya saat email dikirim. Didefinisikan oleh RFC 2822, bentuknya seperti ini:

Date: Tue, 14 Mar 2023 09:42:17 +0100

Header ini terpahat ke dalam isi pesan. Tidak pernah berubah, kecuali seseorang memodifikasi konten mentah pesan tersebut. Inilah "tanggal kirim" dalam arti yang sesungguhnya.

Header Received: (ditambahkan di setiap lompatan jaringan)

Setiap server yang menyentuh email dalam perjalanannya menambahkan header Received: di bagian atas pesan, lengkap dengan tanggalnya sendiri. Email yang melewati tiga server akan mengumpulkan tiga header Received:. Yang paling baru selalu ada di urutan pertama. Hasilnya kira-kira seperti ini:

Received: from mail.example.com ([93.184.216.34])
        by mx.google.com with ESMTPS
        id x1234abcd.2024.06.15.08.31.02;
        Sat, 15 Jun 2024 08:31:02 +0000 (UTC)

Akibatnya, ketika alat migrasi seperti BitTitan MigrationWiz, CloudM, imapsync, atau GSMMO memindahkan email dari server sumber ke server tujuan, alat tersebut juga berperilaku seperti "lompatan jaringan". Ia menyuntikkan header Received: baru di bagian paling atas tumpukan, dengan tanggal dan waktu migrasi.

INTERNALDATE IMAP

Ini adalah tanggal ketiga, dan inilah yang menjadi sumber masalah. INTERNALDATE adalah metadata yang tersimpan di sisi server IMAP, terpisah dari konten pesan. Ia merepresentasikan tanggal saat email dikirimkan (atau dimasukkan) ke dalam kotak surat. Ketika alat migrasi menyisipkan email lewat perintah IMAP APPEND, alat itulah yang menentukan nilai INTERNALDATE. Dan dalam banyak kasus, alat tersebut menggunakan tanggal saat migrasi berlangsung. Bukan tanggal aslinya.

Di sinilah semua hal mulai kacau.

Kenapa Outlook menampilkan tanggal migrasi

Outlook menggunakan INTERNALDATE untuk menampilkan kolom "Diterima". Ini adalah perilaku default-nya, dan konsisten dengan spesifikasi IMAP: INTERNALDATE memang seharusnya merepresentasikan tanggal penerimaan di kotak surat. Dalam alur normal (email sungguhan yang masuk), INTERNALDATE mendekati tanggal di header Date:. Keduanya konsisten.

Setelah migrasi yang bermasalah, INTERNALDATE semua email yang diimpor menunjuk ke malam 14-15 Juni 2024 (atau tanggal migrasi apa pun yang berlaku). Outlook membaca nilai ini, menampilkannya di kolom "Diterima", dan hasilnya bencana: 45.000 email seolah-olah diterima pada malam yang sama.

Untuk lebih tepatnya, header Received: pertama (yang paling baru dalam tumpukan) juga mempengaruhi tampilan dalam konfigurasi tertentu. Tapi INTERNALDATE tetap menjadi penentu utama untuk kolom "Diterima" Outlook dalam mode sinkronisasi IMAP.

Solusi sementara "Tambah kolom Terkirim" di Outlook

Hal pertama yang dilakukan sebagian besar admin IT saat menemukan masalah ini adalah mencari solusi di sisi klien. Dan memang ada solusinya.

Di Outlook, Anda bisa mengubah tampilan kolom suatu folder untuk mengganti (atau menambahkan) kolom "Diterima" dengan kolom "Tanggal" atau "Terkirim". Kolom "Tanggal" membaca langsung header Date: dari pesan, bukan INTERNALDATE. Karena header Date: tidak tersentuh oleh migrasi, tanggal asli kembali muncul.

Untuk melakukannya di Outlook (desktop, versi Microsoft 365): klik kanan pada header kolom di daftar pesan, pilih "Pengaturan Tampilan", lalu ubah kolom untuk menghapus "Diterima" dan menambahkan "Tanggal". Ini bisa dilakukan lewat GPO untuk penerapan massal.

Sekilas, ini tampak menyelesaikan masalah tampilan. Dalam praktiknya, ini hanya plester di atas luka yang dalam.

Batasan nyata dari solusi sementara ini

Klien mobile dan web

Outlook di iOS, Android, dan Outlook Web App (OWA) tidak memiliki opsi kustomisasi yang sama. Perubahan tampilan yang Anda terapkan di perangkat Windows tidak tersinkronisasi ke sana. Pengguna yang membaca email di ponsel mereka tetap melihat tanggal migrasi. Dan di perusahaan berukuran sedang, itu bisa berarti separuh dari total pengguna.

Fitur pencarian

Pencarian Outlook menggunakan indeks Windows Search (atau indeks Exchange/Microsoft 365 di sisi server). Indeks ini dibangun berdasarkan INTERNALDATE, bukan header Date:. Kalau pengguna mencari "email dari Januari 2022", pencarian mengembalikan email yang INTERNALDATE-nya berada di Januari 2022. Bukan yang header Date:-nya di Januari 2022. Hasilnya: email-email lama tidak muncul saat difilter berdasarkan tanggal. Mengubah kolom tampilan tidak mengubah hal ini sama sekali.

Aturan pesan

Aturan Outlook ("jika email diterima sebelum tanggal...", "jika email diterima setelah tanggal...") juga menggunakan INTERNALDATE. Aturan pengurutan atau pengarsipan yang berbasis rentang tanggal tidak akan berfungsi dengan benar setelah migrasi jika INTERNALDATE belum diperbaiki.

Kepatuhan dan eDiscovery

Ini mungkin masalah yang paling serius. Alat kepatuhan, pengarsipan hukum, dan eDiscovery (seperti Microsoft Purview) menggunakan INTERNALDATE sebagai referensi tanggal untuk permintaan hukum. Jika perusahaan Anda tunduk pada kewajiban retensi data atau harus merespons permintaan eDiscovery, INTERNALDATE yang rusak bisa menimbulkan masalah hukum yang nyata. Audit yang meminta "semua email antara tanggal ini dan itu" tidak akan menghasilkan data yang tepat.

Alat pihak ketiga

CRM, alat tiket, pengarsip... semua yang terhubung ke server mail Anda lewat IMAP atau API Microsoft 365/Google Workspace membaca INTERNALDATE. Mengubah tampilan Outlook tidak memperbaiki apa pun untuk sistem-sistem tersebut.

Satu-satunya solusi nyata: perbaikan di level server

Mengurutkan berdasarkan tanggal kirim di Outlook bukan solusi. Itu hanya plester. Perbaikan sesungguhnya harus dilakukan di level metadata server, bukan tampilan klien.

Secara konkret, ini berarti memperbaiki INTERNALDATE setiap email agar sesuai dengan tanggal asli dari header Date:. Header Date: asli selalu ada dalam pesan (tidak terhapus oleh migrasi), sehingga koreksi memang dimungkinkan. Di situlah informasi tanggal yang sebenarnya tersimpan.

Di Google Workspace, Gmail API mengekspos parameter internalDate yang memungkinkan tindakan langsung pada metadata ini. Di Microsoft 365, mekanismenya berbeda tapi hasil yang diharapkan sama. Di server IMAP standar, spesifikasi mengizinkan tanggal untuk ditentukan saat penyisipan pesan.

Dalam praktiknya, melakukan operasi ini pada puluhan ribu email di lingkungan produksi, tanpa kehilangan data, tanpa duplikat, tanpa merusak thread diskusi atau label, sambil menangani kasus-kasus tepi (pesan bertanda tangan S/MIME, struktur MIME kompleks, encoding non-ASCII sesuai RFC 2047, lampiran berukuran besar)... itu urusan yang sama sekali berbeda. Sebuah skrip yang bekerja pada 50 email uji coba tidak akan bertahan di kotak surat dengan 40.000 pesan. Penanganan error 429 (kuota API terlampaui), timeout jaringan pada pukul 2 pagi, pesan yang struktur MIME-nya sudah sebagian rusak setelah migrasi... semua itu memerlukan rekayasa yang serius.

Itulah tepatnya yang dikerjakan Redate.io. Mesin koreksi proprietary-nya menganalisis rantai header setiap email, mengidentifikasi tanggal asli yang dapat dipercaya, dan menerapkan koreksi metadata yang tertarget tanpa menyentuh konten pesan. Setiap email yang dikoreksi diverifikasi satu per satu. File asli disimpan dalam folder cadangan selama 30 hari, yang memungkinkan rollback kapan saja dibutuhkan. Sesuatu yang tidak pernah ditawarkan oleh skrip buatan sendiri.

Mengidentifikasi alat migrasi yang bertanggung jawab

Masalah ini muncul dengan cara yang sama terlepas dari asal migrasinya, tapi detailnya berbeda tergantung alat yang digunakan. BitTitan MigrationWiz, CloudM, imapsync, dan GSMMO masing-masing meninggalkan tanda tangan tersendiri di header Received: yang mereka suntikkan. Pipeline analisis Redate.io mempertahankan basis data yang mencakup ratusan tanda tangan alat migrasi yang dikenal, untuk membedakan header migrasi dari rantai transit jaringan yang sah.

Jika Anda tidak tahu alat apa yang digunakan untuk migrasi (ini bisa terjadi, terutama saat Anda mengambil alih infrastruktur dari MSP lain), pemindaian gratis Redate.io mengidentifikasi kotak surat yang terdampak dan memberikan estimasi volume yang perlu diperbaiki sebelum ada komitmen apa pun.

Untuk konteks yang lebih spesifik, panduan terperinci tersedia: memperbaiki tanggal imapsync di Outlook, memperbaiki tanggal BitTitan di Outlook, atau memperbaiki tanggal CloudM di Outlook.

Apa yang harus dilakukan sekarang

Jika Anda membaca artikel ini setelah selesai migrasi, kabar baiknya adalah header Date: asli masih utuh di setiap email Anda. Informasi tanggal yang sebenarnya ada di sana, tersimpan di dalam setiap pesan. Masalahnya ada di metadata, bukan di konten. Dan metadata bisa diperbaiki.

Anda juga bisa membaca artikel IMAP INTERNALDATE: mengapa tanggal bisa rusak untuk memahami lebih dalam mekanika masalah ini, atau panduan lengkap tentang tanggal yang salah di Outlook setelah migrasi jika Anda ingin gambaran menyeluruh dari berbagai skenario yang mungkin terjadi.

Siap memperbaiki tanggal di kotak surat Anda? Jalankan pemindaian gratis di Redate.io untuk mengidentifikasi email yang terdampak dan memperkirakan volumenya sebelum melakukan koreksi apa pun.