Tiga tanggal di dalam setiap email
Setiap email yang disimpan di server IMAP membawa setidaknya tiga nilai tanggal yang berbeda. Memahami cara kerja tanggal-tanggal ini, dan cara klien email memilih mana yang ditampilkan, adalah kunci untuk memahami mengapa migrasi merusak tanggal. Artikel ini adalah analisis teknis mendalam tentang sistem tanggal IMAP, ditujukan untuk administrator IT dan siapa pun yang ingin memahami akar penyebab masalah tanggal pasca-migrasi.
1. Header "Date" RFC 2822
Header "Date" didefinisikan dalam RFC 2822 (format pesan Internet). Header ini ditentukan oleh klien email pengirim saat pesan dibuat dan dikirim. Header ini adalah bagian dari isi pesan itu sendiri, berpindah bersama pesan dan tidak pernah dimodifikasi oleh server email di sepanjang jalur pengiriman. Header Date khas terlihat seperti:
Date: Mon, 15 Jan 2024 09:32:17 +0100
Header Date mewakili "tanggal kirim" pesan. Ini tanggal paling andal karena ditentukan satu kali dan tidak pernah diubah. Namun, ini mencerminkan jam pengirim, yang mungkin tidak dikonfigurasi dengan benar. Dalam kasus yang jarang, header Date bisa hilang sama sekali (terutama di notifikasi sistem otomatis atau pesan yang salah format).
2. IMAP INTERNALDATE
INTERNALDATE didefinisikan dalam RFC 3501 (protokol IMAP4rev1). Ini adalah nilai metadata sisi server yang mewakili tanggal dan waktu pesan dikirimkan ke server. Berbeda dengan header Date, INTERNALDATE bukan bagian dari pesan email itu sendiri. Disimpan secara terpisah oleh server IMAP sebagai metadata.
Ketika pesan baru tiba via SMTP, server IMAP mengatur INTERNALDATE ke saat penerimaan. Ketika pesan disisipkan via IMAP APPEND (seperti yang terjadi selama migrasi), INTERNALDATE dapat ditentukan secara eksplisit dalam perintah APPEND. Jika tidak ditentukan, server menggunakan waktu saat ini.
3. Header "Received"
Header "Received" ditambahkan oleh setiap server email (MTA) yang menangani pesan di jalur pengirimannya. Setiap header "Received" mencatat dari mana pesan berasal, kapan, dan melalui server mana. Pesan khas membawa 3 hingga 8 header "Received" yang diurutkan secara kronologis terbalik (terbaru di atas).
Ini penting karena klien email seperti Outlook membaca header "Received" paling atas (terbaru) untuk menentukan kapan pesan "diterima".
Cara migrasi merusak rantai tanggal
Masalah IMAP APPEND
Ketika alat migrasi menyisipkan pesan ke server tujuan via IMAP APPEND, dua hal bisa terjadi yang mempengaruhi tanggal: server tujuan menambahkan header "Received" baru dengan cap waktu saat ini (ini perilaku wajib di banyak server IMAP), dan INTERNALDATE mungkin berubah jika alat migrasi tidak mentransfernya dengan benar.
Tanggal mana yang digunakan setiap klien
Di sinilah sumber kebingungan. Setiap klien email menggunakan sumber tanggal yang berbeda:
Outlook Desktop: terutama menggunakan header "Received" terbaru untuk kolom "Diterima". Antarmuka web Gmail: biasanya menggunakan header "Date". Apple Mail: menggunakan INTERNALDATE dan header "Received". Thunderbird: menampilkan "Date" dan "Received" di kolom terpisah. OWA: menggunakan header "Received" dan INTERNALDATE.
Variasi ini berarti kotak surat yang sama setelah migrasi bisa terlihat benar di satu klien dan salah di klien lain.
Mengapa mempertahankan INTERNALDATE tidak cukup
Beberapa alat migrasi (seperti imapsync dengan --syncinternaldates) mempertahankan INTERNALDATE asli. Ini membantu klien yang mengandalkan INTERNALDATE tapi tidak mencegah masalah header "Received" baru. Klien yang membaca header "Received" terbaru (dan ini termasuk Outlook, klien paling banyak digunakan di perusahaan) akan menampilkan tanggal migrasi terlepas dari nilai INTERNALDATE.
Perbaikan teknis
Perbaikan sesungguhnya memerlukan koreksi data di tingkat server sehingga semua sumber tanggal berfungsi secara konsisten. Redate.io mencapai ini melalui mesin koreksi miliknya yang memproses setiap email melalui pipeline analisis multi-tahap. Mesin ini menangani struktur MIME yang kompleks, email bertanda tangan S/MIME, pesan terenkripsi PGP, dan puluhan kasus khusus. Setiap koreksi diverifikasi sebelum diselesaikan.
Tapi melakukannya secara manual dengan skrip? Memahami masalahnya satu hal, tapi memproses 15.000 email tanpa merusak satu pun adalah hal yang sama sekali berbeda. Skrip yang berhasil pada 10 email pengujian tidak akan menangani kasus seperti batas MIME yang rusak, encoding Content-Transfer-Encoding khusus, atau header RFC 2047 non-ASCII. Dan yang lebih buruk: tanpa verifikasi otomatis, Anda tidak akan tahu ada yang gagal sampai sudah terlambat, tanpa cara mengetahui apa yang salah.
Ingin tahu berapa banyak email bertanggal salah di kotak surat Anda? Jalankan analisis gratis dengan Redate.io untuk mendapatkan hitungan instan email yang terpengaruh, tanpa pembayaran diperlukan.