English
Francais
Deutsch
Espanol
Portugues
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Turkce
Ellinika
Russkij
Polski
Cestina
Ukrajinska
Magyar
Romana
Bulgarski
Hrvatski
Srpski
Slovencina
Slovenscina
Lietuviu
Latviesu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
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 tanggal mana yang ditampilkan, adalah kunci untuk memahami mengapa migrasi merusak tanggal. Artikel ini merupakan analisis teknis mendalam tentang sistem tanggal IMAP, ditujukan bagi 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 (Internet Message Format). Header ini ditetapkan oleh klien email pengirim pada saat pesan disusun dan dikirim. Header ini merupakan bagian dari isi pesan email itu sendiri, ikut berpindah bersama pesan, dan tidak pernah diubah oleh server email di sepanjang jalur pengiriman. Header Date yang umum terlihat seperti ini:
Date: Mon, 15 Jan 2024 09:32:17 +0100
Header Date mewakili "tanggal kirim" pesan. Ini adalah tanggal paling andal karena ditetapkan sekali dan tidak pernah diubah. Namun, header ini mencerminkan jam pada perangkat pengirim, yang bisa saja salah diatur. Dalam kasus yang jarang terjadi, header Date bisa hilang sama sekali (terutama pada notifikasi sistem otomatis atau pesan yang cacat format).
2. IMAP INTERNALDATE
INTERNALDATE didefinisikan dalam RFC 3501 (protokol IMAP4rev1). Ini adalah nilai metadata sisi server yang mewakili tanggal dan waktu saat pesan dikirimkan ke server. Berbeda dari header Date, INTERNALDATE bukan bagian dari pesan email itu sendiri. Nilai ini disimpan secara terpisah oleh server IMAP sebagai metadata.
Saat email dikirimkan secara normal (bukan hasil migrasi), server IMAP menetapkan INTERNALDATE ke waktu saat itu, tepat pada momen pengiriman. Nilai ini biasanya hampir sama dengan header Date, umumnya hanya berbeda beberapa detik atau menit. Klien email sering menggunakan INTERNALDATE sebagai "tanggal diterima" karena nilai ini mencerminkan kapan server benar-benar menerima pesan.
Di sinilah bagian yang menarik. Ketika sebuah pesan disisipkan melalui perintah IMAP APPEND (yang digunakan oleh alat migrasi), perintah APPEND memungkinkan klien untuk menentukan INTERNALDATE secara eksplisit. Alat migrasi yang dirancang dengan baik menggunakan fitur ini untuk mempertahankan INTERNALDATE asli dari server sumber. Namun, meski INTERNALDATE ditetapkan dengan benar, masalah header "Received" (dijelaskan di bawah) masih dapat menimpa tanggal yang ditampilkan pada banyak klien email.
3. Rangkaian Header "Received"
Setiap kali sebuah email melewati server email, server tersebut menambahkan header "Received" di bagian paling atas pesan. Ini menciptakan rangkaian header Received yang mencatat jalur yang dilalui email dari pengirim ke penerima. Header Received yang paling baru (di posisi teratas) menunjukkan server terakhir yang menangani pesan, sedangkan yang paling lama (di posisi terbawah) menunjukkan server pertama.
Email yang normal biasanya memiliki 3 hingga 6 header Received, yang mendokumentasikan perjalanan pesan dari server pengirim, melalui server relay (jika ada), hingga server penerima. Setiap header Received menyertakan cap waktu. Berikut contoh sederhananya:
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Bagaimana Klien Email Memilih Tanggal yang Ditampilkan
Outlook (Desktop, Web, Mobile)
Microsoft Outlook menggunakan kombinasi INTERNALDATE dan header "Received" paling atas untuk menentukan tanggal "Diterima" yang ditampilkan di kotak masuk. Dalam praktiknya, Outlook cenderung memprioritaskan cap waktu dari header Received yang paling baru untuk kolom "Diterima". Kolom "Terkirim" menggunakan header Date. Karena Outlook secara default mengurutkan berdasarkan kolom "Diterima", cap waktu dari header Received inilah yang pertama kali dilihat pengguna.
Apple Mail
Apple Mail di macOS dan iOS terutama menggunakan IMAP INTERNALDATE untuk menampilkan tanggal. Jika INTERNALDATE dipertahankan dengan benar selama migrasi, Apple Mail dapat menampilkan tanggal yang tepat, tetapi hanya jika INTERNALDATE ditetapkan secara eksplisit saat operasi APPEND dilakukan. Jika alat migrasi tidak menetapkan INTERNALDATE, server akan menggunakan waktu penyisipan sebagai default (yaitu tanggal migrasi). Untuk detail tentang dampaknya bagi pengguna Apple Mail, lihat Apple Mail wrong date after migration.
Thunderbird
Mozilla Thunderbird menawarkan fleksibilitas paling besar. Thunderbird dapat menampilkan baik "Date" (dari header Date) maupun "Received" (dari header Received). Secara default, Thunderbird menampilkan nilai header Date, yang berarti tanggal bisa terlihat benar di Thunderbird meskipun salah di Outlook. Namun, kolom "Received" di Thunderbird tetap menampilkan tanggal migrasi. Lihat Thunderbird wrong date after migration untuk detail lebih lanjut.
Antarmuka Web Gmail
Klien web Gmail menggunakan header Date sebagai tampilan tanggal utama. Ini berarti Gmail web sering menampilkan tanggal yang benar meskipun setelah migrasi. Namun, IMAP INTERNALDATE di server Gmail tetap salah, yang mempengaruhi setiap klien IMAP yang terhubung ke akun Gmail tersebut. Perbedaan antara Gmail web dan Outlook atau Apple Mail sering menjadi sumber kebingungan, dan ini menghabiskan banyak waktu troubleshooting administrator.
Mengapa IMAP APPEND Merusak Tanggal
Apa yang Terjadi Selama Migrasi
Ketika alat migrasi memindahkan email dari Server A ke Server B, alat tersebut terhubung ke Server A melalui IMAP dan mengunduh pesan mentah, lalu terhubung ke Server B dan menggunakan perintah APPEND untuk menyisipkannya. Selama proses penyisipan tersebut, Server B memproses pesan yang masuk dan menambahkan header Received baru dengan cap waktu saat itu, yaitu tanggal migrasi. Ini adalah perilaku yang umum terjadi pada server IMAP saat menerima pesan baru. Server memperlakukan setiap APPEND sebagai pengiriman pesan baru.
Hasilnya: Rantai Header yang Tercampur
Setelah migrasi, header Received pada email akan terlihat seperti ini:
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
Header Received dari alat migrasi kini menjadi entri paling atas. Klien email mana pun yang menggunakan header Received paling atas untuk menentukan tanggal yang ditampilkan (Outlook, khususnya) akan menampilkan "11 April 2025" bukan "15 Januari 2024". Header Date asli dan header Received asli masih utuh di bawahnya, tetapi keduanya tidak lagi berada di posisi yang diprioritaskan oleh klien email.
Bahkan Penanganan INTERNALDATE yang Baik Tidak Mencegah Ini
Beberapa alat migrasi menetapkan INTERNALDATE dengan benar selama proses APPEND. Sebagai contoh, imapsync secara eksplisit mempertahankan INTERNALDATE dari server sumber. Namun, header Received ditambahkan oleh server tujuan, bukan oleh alat migrasi. Alat migrasi tidak memiliki kendali atas perilaku ini. Bahkan dengan pelestarian INTERNALDATE yang sempurna, header Received paling atas tetap mengandung tanggal migrasi, dan klien seperti Outlook tetap menampilkan tanggal yang salah.
Jadi, apa yang sebenarnya dapat dilakukan untuk mengatasinya?
Alat Migrasi Mana yang Menambahkan Header Received
Setiap alat migrasi IMAP menyebabkan masalah ini karena header Received ditambahkan oleh server tujuan, bukan oleh alat migrasi itu sendiri. Namun, isi header yang ditambahkan berbeda-beda menurut alat dan server yang digunakan.
BitTitan MigrationWiz menambahkan header Received yang mengandung "mx.migrationwiz.com." CloudM Migrate menambahkan header yang mereferensikan "cloudm.io." imapsync memicu header Received generik dari server tujuan. GSMMO menambahkan header dengan referensi "gmailapi.google.com."
Solusinya: Memulihkan Tanggal yang Benar
Kabar baiknya, informasi tanggal yang benar tetap ada di dalam setiap email. Header Date asli masih utuh. Header Received asli juga masih utuh. Masalahnya adalah adanya header yang mencemari yang berada di atas keduanya.
Mesin koreksi milik Redate.io menganalisis seluruh rantai header pada setiap email yang terpengaruh, mendeteksi anomali tanggal untuk mengidentifikasi secara tepat header mana yang perlu dikoreksi. Pendekatan ini bekerja terlepas dari alat migrasi apa pun yang digunakan, karena deteksi didasarkan pada anomali tanggal itu sendiri, bukan pada alat tertentu. Alur analisis bertahap ini menangani kasus khusus yang sering menyulitkan pendekatan yang lebih sederhana: pesan bertanda tangan S/MIME, konten terenkripsi PGP, struktur multipart/alternative, masalah Content-Transfer-Encoding, header non-ASCII (RFC 2047), lampiran berukuran besar, dan batas MIME yang rusak.
Setelah dikoreksi, setiap email melalui proses verifikasi integritas untuk memastikan struktur pesan, konten, dan lampiran tetap terjaga secara utuh. Email asli dipindahkan ke folder cadangan yang terlihat di kotak surat dan tetap berada di sana hingga klien menghapusnya sendiri.
Bisakah Anda menulis skrip sendiri untuk mencoba ini? Secara teknis, bisa. Namun, perbedaan antara "berhasil pada 95% email" dan "berhasil pada 100% email tanpa merusak satu pun" adalah hasil dari kerja rekayasa selama berbulan-bulan. Dan ketika yang dibicarakan adalah seluruh kotak surat seseorang, tingkat kegagalan 5% itu berarti ratusan pesan yang rusak secara diam-diam tanpa cara untuk mengetahui apa yang salah.
Ingin tahu berapa banyak email di kotak surat Anda yang memiliki tanggal rusak? Jalankan analisis gratis dengan Redate.io untuk mendapatkan hitungan instan email yang terpengaruh, tanpa perlu pembayaran.