Import PST di Outlook: Mengapa Semua Tanggal Berubah

Gejalanya: semua email Anda bertanggal hari ini

Anda baru saja selesai melakukan import PST di Outlook. Progress bar sudah mencapai 100%, semuanya berjalan lancar. Lalu Anda membuka kotak masuk... dan setiap email yang diimpor menampilkan tanggal hari ini. Pesan dari tahun 2019, satu lagi dari 2021, arsip berusia lima tahun: semuanya membawa tanggal yang sama. Tanggal hari import dilakukan.

Ini bukan bug tampilan. Bukan juga masalah zona waktu. Ini adalah perilaku yang sudah terdokumentasi dengan baik, sesuai dengan cara IMAP mengelola metadata tanggal. Tapi tetap saja ini bencana bagi siapa pun yang perlu menemukan email lama berdasarkan tanggal.

PST lokal dan IMAP: dua dunia yang sangat berbeda

Sebelum menjelaskan mengapa tanggal bisa rusak, perlu dipahami dulu apa itu file PST dari sudut pandang pengelolaan tanggal.

File PST (Personal Storage Table) adalah format proprietary Microsoft. Format ini menyimpan email beserta metadata lengkapnya: tanggal pengiriman, tanggal penerimaan, lampiran, kategori, dan tanda baca. Metadata ini dikelola langsung oleh Outlook, terlepas dari protokol email apa pun. Saat Anda membuka PST di Outlook tanpa koneksi ke server, tanggal yang ditampilkan berasal langsung dari field internal file PST. Sampai sini, tidak ada masalah.

Masalah muncul ketika Anda mencoba memindahkan konten tersebut ke kotak surat yang dihosting di server IMAP, baik itu Microsoft 365, Google Workspace, maupun hosting biasa lainnya. Di sinilah Anda meninggalkan dunia PST dan memasuki dunia IMAP, dan aturannya berubah drastis.

IMAP APPEND dan INTERNALDATE: inti masalahnya

Dalam IMAP, setiap pesan yang tersimpan di server memiliki dua jenis data tanggal:

• Header Date: (RFC 2822), yang merupakan bagian dari konten pesan itu sendiri. Ini adalah tanggal yang ditulis dalam pesan oleh pengirim.
• INTERNALDATE, yaitu metadata yang dikelola oleh server IMAP. Nilainya mewakili saat pesan ditempatkan di server. Inilah nilai yang digunakan Outlook untuk mengurutkan pesan di tampilan "Tanggal Terima".

(Kalau Anda pernah mencoba membaca raw header email, Anda tahu itu bukan bacaan santai. Tapi di situlah semua ini terjadi.)

Ketika email tiba secara normal di server Anda, server email otomatis menetapkan INTERNALDATE tepat pada saat penerimaan. Hasilnya: tanggal yang ditampilkan di Outlook sesuai dengan kapan Anda menerima pesan tersebut.

Ketika Outlook mengimpor file PST ke kotak surat IMAP, Outlook menggunakan perintah IMAP APPEND untuk mengirim setiap pesan ke server. Standar IMAP memungkinkan pengiriman INTERNALDATE secara eksplisit saat melakukan APPEND. Tapi Outlook tidak melakukannya. Outlook mengirim pesan-pesan tersebut tanpa menentukan INTERNALDATE. Server IMAP, tanpa instruksi apa pun, lalu menerapkan aturan defaultnya: INTERNALDATE diset ke waktu saat ini, yaitu waktu import.

Hasilnya: 8.000 email diimpor, 8.000 email bertanggal hari ini.

Mengapa Outlook berperilaku seperti ini

Ini bukan kelalaian Microsoft. Ini adalah pilihan implementasi yang mungkin terasa masuk akal pada zamannya: dalam use case awal import PST, pengguna mengarsipkan pesan secara lokal lalu "mengimpornya" ke kotak surat aktif. Tanggal yang relevan untuk pengurutan seharusnya adalah tanggal penerimaan asli... tapi Microsoft memilih untuk tidak meneruskan INTERNALDATE saat operasi import.

Lebih tepatnya, perilaku ini berlaku untuk import PST melalui wizard bawaan Outlook (File > Buka dan Ekspor > Impor/Ekspor). Metode import lain, seperti beberapa alat pihak ketiga atau migrasi melalui Exchange Admin Center, bisa berperilaku berbeda tergantung implementasi IMAP APPEND mereka.

Perilaku ini sudah dikenal dan terdokumentasi di forum Microsoft selama bertahun-tahun. Tidak berubah di Outlook 2016, tidak berubah di Outlook 2019, tidak berubah di versi Microsoft 365 saat ini. Pengguna yang mengimpor PST hari ini akan menghadapi masalah yang persis sama seperti di tahun 2015.

Bedanya dengan migrasi IMAP biasa

Ini bagian yang menarik, karena import PST menghasilkan masalah serupa dengan migrasi IMAP dengan tanggal rusak, tapi melalui mekanisme yang berbeda.

Dalam migrasi IMAP biasa, misalnya menggunakan BitTitan MigrationWiz atau imapsync, email berpindah dari server IMAP sumber ke server IMAP tujuan. Alat migrasi mengambil pesan dan menyuntikkannya kembali via IMAP APPEND. Beberapa alat menjaga INTERNALDATE dengan benar, yang lain tidak. Tapi dalam semua kasus, pesan-pesan tersebut sudah memiliki header Received: dengan tanggal migrasi yang ditambahkan di tengah jalan, yang bisa mengganggu tampilan di Outlook terlepas dari INTERNALDATE.

Dengan import PST, mekanismenya lebih sederhana: tidak ada header Received: migrasi yang ditambahkan (file PST tidak melewati server email perantara), tapi INTERNALDATE memang tidak pernah diset ke nilai yang benar. Hasil yang terlihat identik, penyebab dasarnya sedikit berbeda.

Perbedaan ini berdampak langsung pada koreksi: pendekatan yang harus diambil tidak sepenuhnya sama antara migrasi IMAP dan import PST. Lihat juga mengapa INTERNALDATE menyebabkan tanggal rusak untuk penjelasan detail kedua kasus tersebut.

Mengapa opsi tampilan Outlook tidak membantu

Reaksi pertama saat menemukan masalah ini biasanya adalah menggali pengaturan Outlook. Dan memang ada satu pengaturan yang terlihat menjanjikan: kemampuan untuk mengurutkan email berdasarkan "Tanggal" daripada "Tanggal Terima".

Pengurutan berdasarkan tanggal kirim bukan solusi. Itu hanya plester luka.

Inilah alasannya: meskipun Anda mengubah pengurutan untuk menampilkan kolom "Tanggal" (yang merujuk ke header Date: pesan, yaitu tanggal asli), beberapa masalah tetap ada:

• Pencarian Outlook mengindeks berdasarkan INTERNALDATE. Pencarian "email dari Januari 2020" tidak akan menemukan email yang diimpor dari Januari 2020, karena INTERNALDATE mereka mengatakan email tersebut bertanggal hari import.
• Folder "Hari Ini", "Minggu Ini", "Bulan Ini" di antarmuka Outlook didasarkan pada INTERNALDATE, bukan header Date:.
• Di antarmuka web (Outlook Web App, Gmail) dan di klien mobile, tanggal yang ditampilkan dan perilaku pengurutan hampir selalu bergantung pada INTERNALDATE server.
• Aturan dan filter otomatis yang diterapkan pada tanggal penerimaan tidak akan berfungsi dengan benar.

Singkatnya, mengubah tampilan hanya menyelesaikan masalah tampilan untuk satu pengguna tertentu, di satu klien tertentu, dalam satu konfigurasi tertentu. Ini tidak memperbaiki masalah dari akarnya.

Re-sinkronisasi OST juga tidak berguna

Upaya klasik lainnya: mengosongkan cache OST dan memaksa re-sinkronisasi penuh dari server. Idenya adalah bahwa masalah mungkin berasal dari cache lokal Outlook, bukan dari server.

Jalan buntu. File OST adalah cache lokal yang mencerminkan keadaan server IMAP. Jika INTERNALDATE salah di server, ia akan tetap salah di OST setelah re-sinkronisasi. Menghapus OST tidak mengubah data yang tersimpan di server Exchange Online atau Google Workspace. Serverlah yang menjadi otoritas.

Satu-satunya cara untuk memperbaiki tanggal adalah dengan memperbaiki metadata langsung di sisi server, pesan per pesan. Dan di sinilah hal ini menjadi rumit jika dilakukan secara manual.

Masalah skala: 1 email itu sepele. 15.000 email ceritanya beda

Secara teknis, jika Anda memahami masalahnya, mungkin Anda berpikir untuk menulis skrip yang menelusuri kotak surat, membaca header Date: setiap pesan, lalu memperbaiki INTERNALDATE-nya. Memahami masalah adalah satu hal. Memperbaikinya pada 15.000 email tanpa kehilangan satu pun adalah hal yang berbeda sama sekali.

Beberapa kenyataan di lapangan:

• Microsoft Graph API dan Gmail memberlakukan rate limit. Skrip yang naif akan memicu error 429 Too Many Requests, menghentikan eksekusinya di tengah proses koreksi, dan meninggalkan Anda dengan kotak surat yang dikoreksi sebagian, tanpa tahu email mana yang sudah diproses dan mana yang belum.
• Beberapa email dalam PST bisa memiliki header Date: yang cacat atau tidak ada. Skrip tanpa penanganan edge case ini bisa merusak pesan-pesan tersebut atau melewatinya diam-diam.
• Email yang ditandatangani (S/MIME) atau dienkripsi (PGP) memiliki batasan integritas tambahan. Memodifikasi metadata mereka tanpa kehati-hatian bisa membatalkan tanda tangan kriptografis.
• Struktur multipart/alternative dengan batas MIME yang kompleks kadang bereaksi tidak terduga terhadap operasi modifikasi.
• Tidak ada mekanisme rollback. Jika ada yang salah di tengah proses, bagaimana cara kembali ke kondisi semula?

Skrip yang berfungsi pada 10 email uji coba tidak akan berfungsi pada kotak surat produksi berisi 50.000 pesan. Tahun lalu, seorang klien dengan arsip PST sebesar 40 GB mencoba memperbaikinya dengan skrip Python yang ditemukan di Stack Overflow. Hasilnya: 3.000 email duplikat, 200 pesan dengan lampiran yang tidak bisa diakses, dan dua minggu pembersihan manual.

Yang dilakukan Redate.io dalam kasus ini

Redate.io menganalisis metadata setiap pesan di kotak surat target, mengidentifikasi email dengan tanggal yang salah (termasuk yang berasal dari import PST), lalu menerapkan koreksi melalui mesin proprietary-nya. Pipeline analisis multi-tahap membandingkan rantai header setiap pesan, mengekstrak tanggal asli dengan validasi kesesuaian RFC, dan melakukan koreksi metadata yang ditargetkan tanpa mengubah konten pesan.

Setiap email yang dikoreksi diverifikasi satu per satu. Pesan asli disimpan dalam folder backup yang terlihat selama 30 hari sebelum perubahan definitif apa pun. Koreksi bekerja di tiga platform utama: Microsoft 365 (melalui Azure AD), Google Workspace (melalui delegasi domain), dan IMAP langsung untuk hosting biasa.

Pemindaian awal gratis. Ini memungkinkan Anda melihat persis berapa banyak email yang terpengaruh dan bagaimana distribusi tanggal yang salah, sebelum memutuskan apa pun.

Lihat juga:

• Memperbaiki Tanggal Email Setelah Migrasi Microsoft 365
• Outlook: Tanggal Terima IMAP vs Tanggal Kirim Setelah Migrasi
• Bisakah Tanggal Email Diperbaiki Setelah Migrasi?

Import PST Anda menimpa semua tanggal email? Pindai kotak surat Anda secara gratis di Redate.io untuk mengukur sejauh mana masalahnya sebelum mengambil tindakan.