Outlook Baru: Tanggal Salah Setelah Migrasi, Penyebab Nyata

Dua Outlook, dua perilaku berbeda untuk email yang sama

Jika Anda baru saja memigrasikan kotak surat ke Microsoft 365 dan sebagian pengguna mengeluhkan bahwa semua email lama mereka menampilkan tanggal yang sama (tanggal migrasi), Anda mungkin memperhatikan sesuatu yang aneh: pengguna dengan Outlook klasik kadang melihat tanggal yang benar di panel baca, sementara mereka yang menggunakan Outlook baru untuk Windows secara konsisten melihat tanggal migrasi. Kotak surat yang sama. Email yang sama. Hasil yang berbeda.

Ini bukan bug dalam arti sempit. Ini adalah keputusan arsitektur yang berdampak langsung pada cara tanggal ditampilkan setelah migrasi IMAP. Untuk memahami apa yang terjadi, kita perlu masuk ke detail header email dan protokol IMAP, yang memang bukan bacaan santai, tapi menjelaskan mengapa tidak ada manipulasi di sisi klien yang cukup untuk menyelesaikan masalah ini.

INTERNALDATE IMAP: pelaku sebenarnya

Ketika sebuah email disimpan di server IMAP, email tersebut memiliki dua jenis tanggal yang berdampingan dan tidak saling tercampur.

Yang pertama adalah header Date:, yang didefinisikan oleh RFC 2822. Ini adalah tanggal yang tertulis di dalam pesan itu sendiri, tanggal yang dimasukkan pengirim saat mengirim email. Header ini merupakan bagian dari isi pesan dan tidak pernah berubah, apapun jalur yang ditempuh email tersebut selanjutnya.

Yang kedua adalah INTERNALDATE, sebuah metadata yang dikelola oleh server IMAP, di luar pesan itu sendiri. Ini adalah tanggal saat server merekam pesan tersebut. Dalam migrasi normal, alat yang baik akan mempertahankan INTERNALDATE asli. Namun dalam migrasi yang salah dikonfigurasi, atau dengan alat tertentu yang tidak mengelola metadata ini dengan benar, INTERNALDATE direset ke tanggal hari migrasi. Hasilnya: semua email yang dimigrasikan membawa tanggal penerimaan yang sama di mata server.

(Omong-omong, jika Anda pernah membaca log imapsync atau MigrationWiz, Anda tahu ada opsi khusus untuk mencoba mempertahankan INTERNALDATE. Opsi tersebut tidak selalu berhasil, dan beberapa server tujuan menolak untuk menggunakannya.)

Outlook klasik: cara membaca tanggal

Outlook klasik, yaitu versi COM yang diinstal secara lokal (Outlook 2016, 2019, 2021, dan klien desktop Microsoft 365 Apps), menggunakan mekanisme yang sedikit lebih kompleks untuk menentukan tanggal mana yang ditampilkan dalam daftar pesan.

Untuk email di folder Terkirim, Outlook klasik mengandalkan header Date:. Untuk email yang diterima, ia menggunakan INTERNALDATE dari server sebagai prioritas utama, tetapi dalam konteks tertentu (terutama ketika cache OST terlibat atau saat pertama kali ditampilkan di panel baca), ia juga dapat membaca rantai header Received: untuk merekonstruksi tanggal asal secara perkiraan.

Inilah sebabnya kita melihat perilaku yang tidak konsisten: Outlook klasik kadang bisa menampilkan tanggal yang benar di panel baca, karena ia membaca header Date: asli pesan untuk pratinjau detail, meskipun daftar email itu sendiri menggunakan INTERNALDATE yang rusak. Tapi perlu diingat, ini tidak dapat diandalkan, dan tidak memperbaiki apa pun. Pengurutan tetap rusak, pencarian berdasarkan tanggal tetap tidak akurat.

Outlook baru: arsitektur yang benar-benar berbeda

Outlook baru untuk Windows, yang diluncurkan secara bertahap sejak akhir 2023, bukan lagi aplikasi COM. Pada dasarnya ini adalah Progressive Web App (PWA) yang berbasis kode yang sama dengan Outlook di web (OWA). Perombakan ini memiliki implikasi yang mendalam.

Outlook baru sepenuhnya mendelegasikan tampilan tanggal ke API Microsoft 365. Ia tidak membaca header Received:, tidak menggali rantai header untuk menemukan tanggal asal, dan tidak melakukan rekonstruksi apapun di sisi klien. Ia hanya menampilkan apa yang dikembalikan server: INTERNALDATE.

Hasilnya: jika INTERNALDATE rusak saat migrasi, Outlook baru tidak ragu-ragu. Ia menampilkan tanggal migrasi untuk setiap email yang terdampak, tanpa pengecualian, tanpa nuansa. Ini perilaku yang lebih konsisten dan lebih dapat diprediksi dibanding Outlook klasik, tetapi membuat masalah migrasi langsung terlihat dan tidak bisa diabaikan.

Seorang admin yang memigrasikan 300 kotak surat pada Jumat malam akan menemukan pada Senin pagi bahwa semua pengguna Outlook baru melihat seluruh arsip mereka bertanggal akhir pekan lalu. Tiket keluhan datang cepat.

Mengapa tidak ada solusi sisi klien yang berhasil

Banyak admin mencoba solusi di sisi klien sebelum menyadari bahwa masalahnya ada di data server. Berikut adalah upaya yang umum dilakukan, dan mengapa semuanya gagal.

Mengurutkan berdasarkan "Tanggal Kirim" bukan "Tanggal Terima"

Pengurutan berdasarkan tanggal kirim di Outlook mengandalkan header Date: pesan, yang masih utuh. Jadi ya, pengurutan ini bisa berhasil. Tapi ini hanya plester, bukan solusi. Pencarian berdasarkan tanggal tetap rusak. Aturan berbasis tanggal tetap tidak bisa digunakan. Dan yang terpenting, pengguna harus mengkonfigurasi ulang setiap folder secara manual, untuk setiap kotak surat. Pada 300 kotak surat, itu tidak realistis. Mengurutkan berdasarkan tanggal kirim bukan solusi yang tepat, dan pengguna akhir tidak mengerti mengapa mereka diminta mengubah kebiasaan mereka.

Menghapus cache Outlook atau membuat ulang profil

Ini tidak menyentuh INTERNALDATE di sisi server. Setelah profil dibuat ulang, Outlook menyinkronkan kembali email dari server dan mengambil metadata yang sama persis yang sudah rusak. Cache bukan masalahnya.

Menggunakan OWA sebagai pengganti

OWA dan Outlook baru berbagi basis data yang sama. Jika INTERNALDATE rusak di server Exchange Online, OWA menampilkan tanggal yang sama persis yang salah. Mengganti klien tidak mengubah data.

Masalahnya ada di server, dalam metadata setiap pesan. Tidak ada tindakan di sisi klien yang dapat memperbaiki data yang disimpan di sisi server.

Jebakan header Received: mengapa semuanya menjadi rumit

Ketika alat migrasi menyalin email dari satu server ke server lain melalui IMAP, server tujuan secara otomatis menambahkan header Received: di bagian atas rantai, dengan tanggal dan waktu penyisipan. Ini adalah perilaku normal server SMTP dan IMAP yang sesuai dengan RFC.

Header-header ini terakumulasi dalam urutan terbalik dari jalur yang ditempuh email. Yang terbaru berada di atas. Beberapa klien email membaca Received: pertama untuk memperkirakan tanggal penerimaan, yang menghasilkan tanggal migrasi alih-alih tanggal asli.

Perlu diklarifikasi: perilaku ini bukan khusus satu alat saja. BitTitan MigrationWiz, CloudM, imapsync, GSMMO, bahkan salinan IMAP manual antara dua klien Thunderbird, semuanya menghasilkan hasil yang sama. Header Date: asli tetap utuh di dalam pesan. Inilah tepatnya yang membuat koreksi secara teknis memungkinkan. Namun INTERNALDATE adalah metadata terpisah yang dikelola server dan tidak bisa diperbaiki hanya dengan memanipulasi header pesan di sisi klien.

Untuk memahami mekanisme ini lebih mendalam, artikel tentang IMAP INTERNALDATE dan tanggal yang rusak menjelaskan secara detail bagaimana metadata ini dikelola di berbagai server.

Alat migrasi mana yang menyebabkan masalah ini di Microsoft 365

Pertanyaan ini sering muncul: apakah semua alat migrasi menyebabkan masalah ini?

Jawaban singkatnya, tergantung konfigurasi dan platform tujuan. Di Exchange Online / Microsoft 365, server sangat ketat dalam mengelola INTERNALDATE. Bahkan alat yang mencoba mempertahankannya pun kadang gagal, karena API Graph dan EWS (Exchange Web Services) memiliki perilaku berbeda tergantung jalur penyisipan yang digunakan.

BitTitan MigrationWiz adalah salah satu alat yang paling banyak digunakan untuk migrasi ke Microsoft 365, dan juga salah satu yang masalah tanggalnya paling terdokumentasi dengan baik. Halaman khusus memperbaiki tanggal BitTitan di Microsoft 365 mencakup konfigurasi spesifik yang perlu diperhatikan. CloudM dan imapsync memiliki keunikannya masing-masing, yang didokumentasikan masing-masing di memperbaiki tanggal CloudM di Microsoft 365 dan memperbaiki tanggal imapsync di Microsoft 365.

Yang sama untuk semua alat ini: header Date: asli tetap bertahan setelah migrasi. Itulah dasar yang memungkinkan koreksi dilakukan.

Mengapa skrip buatan sendiri berisiko di sini

Memahami masalah kadang menciptakan ilusi bahwa solusinya sederhana. Pada skala produksi, tidak ada yang sederhana di sini.

Memodifikasi metadata email yang tersimpan di Exchange Online bukanlah hal sepele. API Graph Microsoft memberlakukan batas laju yang ketat (error 429 Too Many Requests pada batch malam hari datang dengan cepat). Penanganan email bertanda tangan S/MIME atau terenkripsi PGP memerlukan perhatian khusus agar tanda tangan tidak menjadi tidak valid. Struktur multipart dengan lampiran berukuran besar menambah kendala pada timeout jaringan. Dan yang terpenting: bagaimana Anda memverifikasi, email per email, bahwa koreksi berhasil tanpa mengubah konten atau lampiran?

Skrip yang berjalan baik pada 50 email uji coba tidak akan berperilaku sama pada kotak surat dengan 40.000 pesan dan riwayat 8 tahun. Probabilitas suatu kasus edge merusak sesuatu meningkat seiring setiap ribuan pesan tambahan. Dan tanpa mekanisme rollback, kesalahan di tengah jalan akan meninggalkan kotak surat dalam keadaan tidak konsisten.

Lihat juga: memperbaiki tanggal email setelah migrasi Microsoft 365 untuk gambaran lengkap opsi yang tersedia.

Apa yang dilakukan Redate.io secara konkret

Setiap pengguna masuk dengan akun Microsoft-nya sendiri, dan Redate.io membuka kotak surat tersebut dengan akses yang diberikan saat masuk, tanpa portal dan tanpa aplikasi yang perlu didaftarkan. Redate.io memindai email dengan tanggal yang salah secara gratis, lalu menerapkan mesin koreksi proprietary pada pesan yang teridentifikasi. Pipeline analisis multi-tahap melakukan pencocokan pola pada ratusan tanda tangan alat migrasi yang diketahui, validasi kepatuhan RFC, dan analisis rantai header untuk merekonstruksi metadata tanggal yang benar.

Setiap email yang dikoreksi diverifikasi secara individual. Pesan asli tidak pernah dihapus oleh Redate.io. Pesan tersebut tetap ada dalam folder yang terlihat di kotak surat Anda sendiri sampai Anda menghapusnya. Model penetapan harga dihitung dari hasil pemindaian dan ditampilkan sebelum pembayaran.

Outlook baru kemudian menampilkan tanggal yang benar, karena data di server yang diperbaiki, bukan disembunyikan.

Anda memiliki kotak surat yang terdampak di Outlook baru? Jalankan pemindaian gratis di Redate.io untuk mengidentifikasi dengan tepat berapa banyak email yang terdampak sebelum memutuskan langkah selanjutnya.