Semua Email Lama Punya Tanggal Sama: Ada Apa?

Gejalanya: semua email lama menumpuk di tanggal yang sama

Anda membuka Outlook, Gmail, atau Apple Mail suatu pagi. Ada yang janggal. Ratusan, bahkan ribuan email lama semuanya menampilkan tanggal yang sama: beberapa hari lalu, atau beberapa minggu yang lalu. Pesan dari 2021, dari 2019, dari 2016 muncul seolah-olah baru diterima kemarin. Urutan berdasarkan tanggal jadi tidak bermakna lagi. Anda mencari email penting dari tahun lalu, dan email itu tenggelam dalam ribuan pesan yang semuanya tampak berasal dari hari yang sama.

Email baru tetap menampilkan tanggal yang benar. Hanya pesan-pesan lama yang terdampak.

Apa yang sebenarnya terjadi?

Reaksi pertama: menyalahkan aplikasinya

Wajar kalau Anda langsung curiga ada bug. Outlook crash. Pembaruan yang gagal. File yang rusak. Dan dari sini biasanya dimulai pencarian panjang: Anda ketik "bug tanggal Outlook", lalu bertemulah dengan forum-forum yang membahas file OST, SCANPST.exe, membuat ulang profil Outlook dari awal...

Dua jam berlalu. Masalah tidak hilang.

Sebenarnya, SCANPST adalah alat perbaikan untuk file data Outlook lokal. Ia bisa memperbaiki kerusakan file tertentu, tapi tidak menyentuh data yang tersimpan di server email. Artinya, meski file OST Anda diperbaiki dengan sempurna, tanggal-tanggal itu tetap salah, karena masalahnya bukan ada di komputer Anda.

Masalahnya ada di dalam email itu sendiri, di server.

Yang benar-benar terjadi: sebuah migrasi

Dalam hampir semua kasus, gejala ini muncul setelah migrasi email. Perusahaan Anda berpindah dari sistem lama ke Google Workspace, Microsoft 365, atau server baru. Seseorang, di suatu tempat, menggunakan alat untuk memindahkan semua email Anda dari satu tempat ke tempat lain.

Mungkin Anda tidak diberi tahu. Atau Anda tahu, tapi tidak menghubungkannya dengan masalah tanggal ini. Itu hal yang sangat wajar.

Alat migrasi melakukan pekerjaan besar: menyalin ribuan pesan, seluruh folder, lampiran-lampiran. Tapi mereka punya efek samping yang cukup licik. Ketika sebuah email dipindahkan dari satu server ke server lain, alat tersebut menambahkan baris teknis kecil ke dalam email, yang disebut header "Received:", yang mencatat kapan pesan itu tiba di server baru. Artinya: tanggal migrasi.

Di situlah akar permasalahannya.

Bagaimana aplikasi email memilih tanggal yang ditampilkan

Sebuah email sebenarnya menyimpan beberapa tanggal berbeda, tersembunyi dalam data teknisnya. Ada tanggal pengiriman asli (yang biasanya Anda lihat), tapi juga ada header "Received:" yang mencatat setiap tahap perjalanan pesan di internet.

(Kalau Anda pernah mengklik "Tampilkan sumber" atau "Lihat header lengkap" pada sebuah email, mungkin Anda pernah melihat baris-baris misterius yang terlihat seperti blok teks yang tidak bisa dipahami. Ya, itu memang itu.)

Dalam kondisi normal, aplikasi email Anda membaca header "Received:" yang paling baru untuk menentukan kapan email itu ditampilkan. Logika ini bekerja sempurna: "Received:" terakhir selalu sesuai dengan saat pesan tiba di kotak masuk Anda, beberapa detik setelah dikirim.

Tapi setelah migrasi, logika ini berbalik melawan Anda. Alat migrasi menambahkan header "Received:" baru di posisi paling atas, dengan tanggal transfer. Aplikasi email Anda membaca header ini duluan, melihat tanggal migrasi, dan menampilkannya. Tanggal pengiriman asli masih ada, utuh, terkubur lebih dalam di data email. Tapi aplikasi Anda tidak melihatnya, karena ia berhenti di header pertama.

Hasilnya: 8.000 email yang semuanya tampak datang dari hari Selasa yang sama di bulan November.

Alat apa yang menyebabkan masalah ini?

Alat migrasi yang paling umum semuanya memiliki perilaku ini. BitTitan MigrationWiz, CloudM, imapsync, GSMMO (alat gratis Google untuk migrasi dari Outlook), dan banyak lainnya. Ini bukan benar-benar kekurangan dari pihak mereka: ini adalah konsekuensi dari cara kerja teknis protokol email. Alat-alat ini menambahkan header tersebut karena memang itulah yang diatur protokol ketika pesan dipindahkan dari satu server ke server lain.

Masalahnya, tidak ada yang memberitahu pengguna bahwa ini akan terjadi.

Jika perusahaan Anda baru-baru ini mengganti sistem email, atau tim IT Anda melakukan "migrasi ke cloud", kemungkinan besar itulah sumber masalahnya. Anda bisa memverifikasinya dengan melihat tanggal-tanggal yang terdampak: apakah semuanya berada di sekitar periode yang sama? Jika ya, periode itu adalah waktu migrasi berlangsung.

Untuk detail lebih lanjut tentang alat-alat spesifik, lihat artikel kami tentang memperbaiki tanggal setelah migrasi BitTitan dan CloudM dan tanggal email yang salah.

Solusi yang tidak akan berhasil

Beberapa solusi yang sering muncul di forum, dan tidak akan menyelesaikan masalah ini:

Memperbaiki file data dengan SCANPST

Seperti disebutkan di atas: SCANPST memperbaiki file lokal Outlook (file .pst atau .ost yang tersimpan di komputer Anda). Ia tidak memodifikasi email di server. Setelah perbaikan, email Anda tetap akan memiliki tanggal yang salah, karena tanggal-tanggal itu ada di dalam email itu sendiri, bukan di file lokal.

Membuat ulang profil Outlook

Logika yang sama. Membuat ulang profil Outlook berarti mulai dari awal secara lokal, lalu mengunduh ulang semua email dari server. Email yang diunduh ulang akan memiliki tanggal yang persis sama seperti sebelumnya. Anda hanya membuang waktu untuk konfigurasi ulang.

Mengurutkan berdasarkan "tanggal kirim" bukan "tanggal terima"

Beberapa forum menyarankan mengubah kriteria pengurutan di Outlook, beralih dari tanggal penerimaan ke tanggal pengiriman. Ini mungkin membantu dalam beberapa kasus... tapi tidak selalu. Dan ini tidak menyelesaikan apa pun untuk aplikasi lain, perangkat lain, atau orang lain yang mengakses kotak surat Anda. Akar masalahnya tetap ada. Mengurutkan berdasarkan tanggal kirim bukan solusi, itu hanya plester.

Menginstal ulang aplikasi email

Tidak. Email ada di server, bukan di aplikasi. Menginstal ulang Outlook, Gmail, Apple Mail, atau Thunderbird tidak mengubah apa pun pada data yang tersimpan secara online.

Kabar baiknya: tanggal asli masih ada

Ini hal penting yang perlu dipahami, dan yang membuat perbaikan menjadi mungkin: tanggal pengiriman asli setiap email tidak dihapus. Tanggal itu masih ada, di dalam email, dalam header yang disebut "Date:" yang sesuai dengan tanggal pengiriman yang dipilih pengirim. Ini adalah standar email (yang didefinisikan oleh spesifikasi teknis bernama RFC 2822) yang dihormati semua alat migrasi, karena mengubahnya akan menjadi pelanggaran serius terhadap standar tersebut.

Dengan kata lain, jika Anda menerima email pada 14 Maret 2022, email tersebut masih menyimpan tanggal itu di suatu tempat dalam datanya. Tanggal itu hanya bukan lagi yang pertama ditampilkan oleh aplikasi Anda.

Inilah yang membuat perbaikan bisa dilakukan. Masalahnya bukan kehilangan data. Ini soal pembacaan metadata: aplikasi email Anda membaca tanggal yang salah, sementara tanggal yang benar masih ada di sana.

Mengapa tidak coba memperbaiki sendiri?

Mungkin Anda bertanya-tanya apakah seorang teknisi IT bisa menulis skrip untuk memperbaiki masalah ini. Memahami apa yang terjadi adalah satu hal. Memperbaikinya dengan benar pada ribuan email tanpa kehilangan satu pun adalah hal yang lain.

Sebuah email bukan sekadar file teks biasa. Email bisa berisi lampiran, tanda tangan digital, konten yang dienkode dalam format-format kompleks. Memodifikasi metadata pesan seperti itu tanpa merusaknya memerlukan penanganan puluhan kasus khusus: pesan yang ditandatangani secara elektronik (S/MIME), email terenkripsi (PGP), enkoding non-standar, struktur multi-bagian... Skrip buatan sendiri yang bekerja pada 20 email percobaan kemungkinan besar tidak akan berfungsi dengan benar pada kotak surat produksi berisi 15.000 pesan. Dan kalau ada yang salah, bagaimana memastikan tidak ada email yang rusak atau hilang? Dengan skrip buatan sendiri: tidak bisa.

Tanpa mekanisme pencadangan dan verifikasi individual untuk setiap email, risiko kerusakan yang tidak disengaja sangat nyata.

Apa yang dilakukan Redate.io

Redate.io adalah layanan yang dirancang khusus untuk masalah ini. Redate.io terhubung ke kotak surat Anda (Google Workspace, Microsoft 365, atau server IMAP), mengidentifikasi email yang tanggalnya telah berubah akibat migrasi, dan memperbaikinya melalui mesin koreksi proprietary yang menganalisis rantai header secara lengkap dan merekonstruksi metadata tanggal untuk setiap pesan.

Setiap email yang diperbaiki diverifikasi satu per satu. Email asli disimpan dalam folder cadangan yang terlihat selama 30 hari. Jika ada yang tidak beres, Anda bisa kembali ke kondisi semula.

Pemindaian awal gratis: Redate.io menganalisis kotak surat Anda dan menunjukkan dengan tepat berapa banyak email yang terdampak sebelum Anda memutuskan apa pun. Tidak ada kejutan.

Harga berupa pembayaran satu kali, berdasarkan volume email yang perlu diperbaiki. Tidak ada langganan. Bayar sekali, masalah beres.

Ingin tahu seberapa besar dampaknya sebelum memutuskan? Jalankan pemindaian gratis kotak surat Anda di Redate.io dan temukan dalam beberapa menit berapa banyak email yang terdampak.