Buat Ulang Profil Outlook: Mengapa Tanggal Berubah

Langkah troubleshooting yang merusak tanggal

Seorang pengguna mengeluh Outlook tidak lagi tersinkronisasi. Email tidak masuk, folder Terkirim tidak diperbarui, ikon loading berputar terus. Teknisi mendiagnosis profil yang rusak, menghapus file OST, membuat ulang profil Outlook dari awal. Hasilnya: Outlook terhubung kembali, email muncul lagi, semuanya tampak berfungsi.

Sampai keesokan paginya, ketika pengguna membuka kotak masuknya dan menyadari bahwa 8 tahun korespondensi menampilkan tanggal yang sama: hari ini.

Ini persis gejala yang sama seperti migrasi IMAP yang gagal. Dan karena alasan yang sama persis.

Apa yang terjadi secara teknis

Untuk memahami mengapa membuat ulang profil menghasilkan ini, kita perlu kembali ke perbedaan yang kurang dipahami oleh sebagian besar teknisi: perbedaan antara header Date: sebuah email dan INTERNALDATE IMAP-nya.

Setiap email memiliki field Date: dalam header RFC 2822 yang menunjukkan kapan pesan dikirim. Field ini ditulis oleh klien email pengirim pada saat pengiriman, lalu dibawa apa adanya melalui semua server hingga ke kotak masuk Anda. Field ini tidak pernah berubah. Email yang dikirim pada 14 Maret 2019 pukul 09.32 akan selalu memiliki field Date: yang utuh, tidak peduli apa yang terjadi sesudahnya.

INTERNALDATE IMAP adalah hal yang berbeda. Ini adalah metadata yang dikelola oleh server email, terpisah dari konten pesan. Metadata ini menunjukkan kapan pesan "ditempatkan" ke dalam kotak masuk. Dalam kondisi normal, ketika email tiba melalui SMTP, server mencatat waktu penerimaan sebagai INTERNALDATE. Email yang diterima pada 14 Maret 2019 akan memiliki INTERNALDATE yang sesuai dengan tanggal pengirimnya.

Outlook, secara default, mengurutkan dan menampilkan email berdasarkan INTERNALDATE yang dikirimkan oleh server IMAP, bukan berdasarkan field Date: dari pesan itu sendiri. (Omong-omong, jika Anda pernah membuka properti lengkap sebuah email di Outlook untuk melihat header mentahnya, Anda tahu itu bukan bacaan yang menyenangkan.)

Apa yang dipicu oleh penghapusan file OST

Ketika Outlook menggunakan akun IMAP, ia mempertahankan database lokal: file OST (Offline Storage Table). File ini adalah salinan lokal dari email yang tersimpan di server, lengkap dengan metadata, status baca, kategori, dan sebagainya.

Menghapus file OST sama saja dengan menghapus salinan lokal tersebut. Outlook harus mengunduh ulang semuanya dari server IMAP.

Masalahnya? Ketika Outlook mengunduh ulang pesan melalui IMAP, ia menggunakan perintah FETCH untuk mengambil konten. Namun ia tidak selalu menggunakan perintah FETCH INTERNALDATE untuk mengambil dan mempertahankan tanggal IMAP asli. Dalam konfigurasi dan versi Outlook tertentu, klien membangun ulang indeks lokalnya menggunakan tanggal saat ia mengunduh ulang pesan, bukan INTERNALDATE yang tersimpan di server.

Dan dengan begitu, semua email di kotak masuk bertanggal sesuai hari pengunduhan ulang.

Tidak semua versi Outlook berperilaku sama

Sebenarnya, perilaku ini tidak memengaruhi semua versi Outlook secara identik, dan di sinilah diagnosa menjadi rumit.

Outlook 2016 dan 2019 dalam mode IMAP memiliki perilaku rekonstruksi indeks yang salah setelah penghapusan cache yang sudah terdokumentasi. Outlook baru (berbasis web, yang diluncurkan secara bertahap sejak akhir 2023) mengelola cache secara berbeda dan dapat menghasilkan hasil yang bervariasi. Outlook via Exchange/Microsoft 365 dengan akun yang dikonfigurasi dalam mode Exchange lebih sedikit terpapar masalah spesifik ini, karena protokol MAPI/Exchange menangani sinkronisasi secara berbeda dari IMAP.

Tapi jika pengguna Anda menggunakan akun IMAP yang dikonfigurasi di Outlook klasik, dan seorang teknisi telah menghapus file OST atau membuat ulang profil: risikonya nyata.

Cara membedakan kasus ini dari migrasi sebenarnya

Admin IT yang menerima tiket "tanggal email saya salah" setelah pembuatan ulang profil mungkin keliru mengira itu masalah migrasi. Berikut cara membedakan kedua kasus tersebut.

Kasus migrasi IMAP

Saat migrasi IMAP (BitTitan, CloudM, imapsync, dll.), alat migrasi menyalin email dari satu server ke server lain. Untuk setiap pesan yang disalin, alat tersebut membuat entri baru di server tujuan. Jika alat tidak secara eksplisit menentukan INTERNALDATE asli, server tujuan mencatat waktu saat itu sebagai INTERNALDATE. Selain itu, beberapa alat juga menambahkan header Received: dengan tanggal migrasi, yang memperburuk masalah di beberapa klien. Detail mekanisme ini tersedia di artikel kami tentang IMAP INTERNALDATE dan tanggal yang rusak.

Kasus pembuatan ulang profil

Di sini, email masih ada di server yang sama, dengan INTERNALDATE asli yang sama. Tidak ada yang berubah di sisi server. Hanya cache lokal Outlook yang dibangun ulang dengan tanggal yang salah. Gejala yang terlihat identik (semua email menampilkan tanggal terkini yang sama), tetapi asal-usulnya berbeda.

Untuk memastikan: masuk ke kotak masuk melalui webmail (Gmail, Outlook.com, atau antarmuka webmail penyedia hosting Anda). Jika tanggal yang ditampilkan di webmail sudah benar, masalahnya murni lokal di Outlook. Jika tanggal juga salah di webmail, masalahnya ada di sisi server (migrasi atau modifikasi INTERNALDATE di server itu sendiri).

Mengapa tanggal asli masih bisa dipulihkan

Kabar baiknya: dalam kedua kasus (migrasi atau pembuatan ulang profil), tanggal asli tidak hilang.

Header Date: RFC 2822 adalah bagian yang tidak terpisahkan dari pesan. Ia sama tidak berubahnya seperti isi teks atau lampiran. Email yang dikirim pada 2017 mengandung dalam teks mentahnya sesuatu seperti:

Date: Mon, 12 Jun 2017 14:23:41 +0200

Baris ini ada dalam pesan yang tersimpan di server. Baris ini tidak dimodifikasi. Yang ditampilkan Outlook (secara salah) adalah metadata eksternal dari konten pesan.

Inilah yang membuat koreksi menjadi mungkin. Engine Redate.io menganalisis rantai header setiap pesan untuk mengekstrak tanggal asli yang sebenarnya, lalu melakukan koreksi metadata yang ditargetkan tanpa mengubah konten pesan. INTERNALDATE yang terlihat oleh Outlook direkonstruksi dari informasi autentik ini, yang selalu ada di dalam pesan.

Jebakan pembuatan ulang yang "bersih"

Anda baru saja menyelesaikan masalah sinkronisasi untuk seorang pengguna. Outlook-nya berfungsi lagi, email baru masuk. Anda menutup tiket.

Tiga hari kemudian, pengguna menelepon kembali: ia mencari email dari vendor yang dikirim tahun lalu, tapi di Outlook semua emailnya dari 2023 muncul seolah diterima "kemarin". Ia tidak bisa menemukan apa pun. Pengarsipan otomatis mungkin sudah mengklasifikasikan email terbaru sebagai email lama. Dan atasannya meminta percakapan email dari September 2022 untuk keperluan sengketa.

Skenario ini terjadi cukup sering. Bukan karena teknisi melakukan kesalahan, tapi karena perilaku Outlook ini tidak terdokumentasi secara jelas dalam panduan troubleshooting standar.

Solusi semu yang tidak menyelesaikan apa pun

Mengurutkan email berdasarkan "Tanggal Kirim" alih-alih "Tanggal Terima" di Outlook adalah hal pertama yang dicoba pengguna. Dan tampaknya berhasil... sampai mereka menyadari bahwa pengurutan berdasarkan tanggal kirim hanya tersedia di beberapa folder, menghilang ketika tampilan diubah, dan aplikasi lain (ponsel, webmail, aturan pengurutan otomatis) terus menggunakan INTERNALDATE yang salah.

Pengurutan berdasarkan tanggal kirim bukan solusi. Ini hanya plester yang menutupi gejala tanpa menyentuh masalah sebenarnya. Penjelasan lengkapnya ada di artikel Urutkan tanggal kirim bukan solusi yang tepat.

Membuat ulang profil untuk kedua kalinya? Tidak ada bedanya jika perilaku Outlook membangun ulang cache-nya dengan tanggal saat ini.

Ekspor lalu impor ulang sebagai PST? Hati-hati. Ekspor PST dari Outlook dengan tanggal yang rusak akan mengekspor metadata yang rusak juga. File PST akan berisi tanggal yang salah. Mengimpor ulang file tersebut tidak memperbaiki apa pun, dan bahkan bisa memperburuk situasi dengan membuat duplikat yang memiliki tanggal tidak konsisten. Topik ini dibahas secara terpisah dalam artikel tentang import PST di Outlook dan mengapa semua tanggal berubah.

Apa yang dilakukan Redate.io dalam kasus ini

Baik masalah berasal dari migrasi IMAP maupun pembuatan ulang profil Outlook, hasilnya di sisi server serupa: email yang metadata tanggalnya tidak konsisten dengan konten sebenarnya.

Redate.io terhubung langsung ke kotak surat (Google Workspace, Microsoft 365, atau IMAP langsung), memindai semua pesan untuk mengidentifikasi yang metadata-nya salah, lalu menerapkan pipeline analisis multi-tahap untuk memperbaiki setiap email secara individual. Setiap koreksi diverifikasi. Pesan asli tidak pernah dihapus oleh Redate.io: pesan tetap berada dalam folder backup yang terlihat di kotak surat Anda, sampai Anda menghapusnya sendiri.

Proses ini menangani kasus-kasus tepi yang secara konsisten gagal ditangani oleh skrip buatan sendiri: pesan yang ditandatangani S/MIME, email dengan encoding non-ASCII di header (RFC 2047), struktur multipart yang kompleks, header Date: dengan zona waktu non-standar atau yang cacat. Skrip yang berjalan dengan baik pada 50 email uji di kotak pengembangan bisa merusak secara permanen 2.000 pesan di lingkungan produksi. Tidak ada mekanisme rollback bawaan di IMAP setelah pesan diganti tanpa backup sebelumnya.

Untuk kasus yang berkaitan khusus dengan Outlook, halaman perbaikan perbaiki tanggal salinan IMAP manual di Outlook menjelaskan langkah-langkah untuk menghubungkan kotak masuk Anda dan memulai analisis.

Mencegah masalah pada intervensi berikutnya

Jika Anda adalah teknisi atau admin IT yang secara rutin menangani profil Outlook, beberapa kebiasaan sederhana dapat menghindari situasi ini.

Sebelum menghapus file OST atau membuat ulang profil, periksa tanggal yang ditampilkan di webmail. Jika sudah benar, catat hal tersebut di tiket Anda. Setelah pembuatan ulang, masuk kembali melalui webmail dan bandingkan tanggal yang ditampilkan dengan yang ada di Outlook. Jika ada perbedaan, masalah langsung teridentifikasi, sebelum pengguna mengeluh tiga hari kemudian.

Untuk migrasi yang direncanakan, checklist migrasi email mencantumkan verifikasi yang perlu dilakukan sebelum dan sesudah untuk mendeteksi jenis masalah ini segera setelah operasi selesai.

Anda sudah membuat ulang profil Outlook dan semua tanggal di kotak masuk kini salah? Jalankan scan gratis di Redate.io untuk mengidentifikasi email yang terpengaruh dan memperbaiki metadata tanpa menyentuh konten pesan Anda.