Memalsukan Tanggal Email: Mungkin, tapi Terdeteksi

Memalsukan tanggal email: apa sebenarnya yang dimaksud?

Pertanyaan ini sering muncul di forum administrasi sistem dan grup Slack para MSP: apakah mungkin mengubah tanggal email setelah terkirim? Jawaban singkatnya adalah ya, secara teknis. Tapi jawaban lengkapnya jauh kurang menyenangkan bagi siapa pun yang ingin melakukannya untuk tujuan yang meragukan.

Email bukan file tunggal yang monolitik. Email adalah kumpulan header teks yang diikuti oleh isi pesan. Di antara header-header tersebut, beberapa menyimpan informasi tanggal. Dan beberapa lebih mudah dimodifikasi dibandingkan yang lain.

Ada tiga lapisan informasi tanggal yang ada di setiap email:

• Header Date: (RFC 2822), ditulis oleh klien email saat pengiriman
• Header Received:, ditambahkan oleh setiap server yang meneruskan pesan
• INTERNALDATE IMAP, sebuah metadata yang disimpan di sisi server, terpisah dari isi pesan

Setiap lapisan ini bisa dimodifikasi. Tidak satu pun yang bisa diubah tanpa meninggalkan jejak.

Mengubah header Date:: manipulasi yang paling mencolok

Header Date: adalah teks biasa dalam file .eml. Secara teknis, editor hex maupun skrip Python apa pun bisa menimpanya dalam hitungan detik. Jika Anda pernah membuka header mentah sebuah email di Gmail (menu kecil "Tampilkan asli"), Anda tahu bahwa siapa pun bisa membacanya.

Masalahnya? Sejak tahun 2004, sebagian besar server email menandatangani email keluar dengan DKIM (DomainKeys Identified Mail). Tanda tangan kriptografis ini secara eksplisit mencakup beberapa header, termasuk Date:, From:, Subject:, dan isi pesan. Tanda tangan ini tersimpan di header DKIM-Signature:.

Mengubah Date: setelah penandatanganan secara otomatis membatalkan verifikasi DKIM. Server penerima mana pun dapat memverifikasi tanda tangan dengan mengambil kunci publik dari DNS domain pengirim. Jika tanda tangan tidak cocok, pesan ditandai sebagai telah diubah. Gmail, Outlook.com, dan semua penyedia besar melakukan verifikasi ini secara otomatis.

(Omong-omong, jika Anda ingin melihat tanda tangan DKIM secara nyata, buka header mentah email yang diterima dari Gmail atau Office 365: Anda akan menemukan baris DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=... yang terlihat seperti deretan karakter acak, padahal sebenarnya itu adalah hash kriptografis dari seluruh pesan.)

Hasilnya: mengubah Date: pada email yang sudah ditandatangani DKIM sama dengan memecahkan segel. Modifikasi tersebut bisa dilihat oleh administrator mana pun yang tahu cara mencarinya.

Menulis ulang header Received:: rantai yang sulit dipalsukan

Header Received: melacak jalur yang ditempuh email dari pengirim ke penerima. Setiap server SMTP yang menyentuh pesan menambahkan satu header baru, lengkap dengan nama server, alamat IP, dan timestamp. Email yang melewati dua atau tiga relay akan mengandung dua atau tiga header Received: yang tersusun bertumpuk.

Bisakah header-header ini dimodifikasi? Secara teknis, ya, pada salinan pesan milik Anda sendiri. Tapi ada jebakannya: penerima juga memiliki salinannya sendiri. Dan server penerima menambahkan header Received:-nya sendiri di bagian terakhir. Header ini berada di bawah kendali penerima, bukan pengirim. Tidak mungkin dipalsukan dari luar.

Konsistensi rantai header ini dapat diperiksa. Jika timestamp pada serangkaian Received: tidak konsisten (misalnya, relay perantara sepertinya menerima pesan sebelum pengirim mengirimkannya), itu langsung mencurigakan. Alat analisis forensik email seperti MXToolbox atau alat internal tim keamanan memeriksa hal ini secara khusus.

Sebenarnya, tidak sepenuhnya benar untuk mengatakan bahwa header Received: tidak bisa dipalsukan sepenuhnya: penyerang yang mengendalikan infrastruktur mail-nya sendiri dapat membuat header yang terlihat kredibel untuk relay yang ia kuasai. Tapi ia tidak pernah mengendalikan mata rantai terakhir: server milik penerima.

INTERNALDATE IMAP: kasus yang paling teknis

INTERNALDATE adalah metadata IMAP yang disimpan di sisi server. Ini bukan header di dalam pesan itu sendiri, melainkan nilai yang diasosiasikan server dengan pesan dalam basis data internalnya. Nilai inilah yang digunakan sebagian besar klien email untuk mengurutkan pesan di kotak masuk.

Perintah IMAP APPEND memungkinkan penempatan pesan ke server dengan menentukan INTERNALDATE secara eksplisit. Ini adalah fitur protokol yang sah, didokumentasikan dalam RFC 3501. Alat migrasi menggunakannya secara konstan: imapsync, BitTitan MigrationWiz, CloudM, GSMMO... semuanya menempatkan email ke server tujuan dengan INTERNALDATE yang telah ditentukan.

Secara teori, seseorang dengan akses IMAP ke kotak mailnya sendiri bisa menempatkan email dengan INTERNALDATE apa pun. Tapi manipulasi ini tidak mengubah header pesan. Date: asli tetap utuh, header Received: tetap utuh, tanda tangan DKIM tetap utuh. Hanya metadata pengurutan di sisi server yang berubah.

Bagi seorang ahli yang memeriksa pesan mentah, perbedaan antara INTERNALDATE dan Date: langsung terlihat. Dan jika pesan ditandatangani dengan DKIM, tanggal aslinya terbukti secara kriptografis.

Message-ID: sidik jari yang sulit dipalsukan

Setiap email menghasilkan identifikasi unik, yaitu header Message-ID:. Identifikasi ini dibuat oleh server SMTP pengirim saat pengiriman, biasanya dengan menggabungkan timestamp, identifikasi acak, dan nama domain server.

Message-ID yang khas terlihat seperti ini: <CABc123xyz-2025-01-15T09:32:11@mail.gmail.com>. Timestamp sering kali dikodekan langsung ke dalam identifikasi tersebut. Mengubah tanggal pesan tetapi membiarkan Message-ID dengan timestamp yang tidak sesuai menciptakan inkonsistensi yang langsung dapat dikenali.

Selain itu, Message-ID diindeks oleh sistem pesan besar. Google, Microsoft, dan penyedia lain menyimpan log yang memungkinkan penelusuran kapan suatu pesan benar-benar beredar di infrastruktur mereka. Dalam konteks hukum atau forensik, log ini dapat diakses melalui prosedur peradilan.

Dalam praktiknya: siapa yang bisa mendeteksi upaya manipulasi?

Mari kita ajukan pertanyaan ini secara konkret. Anda menerima email yang Anda curigai telah diubah tanggalnya. Apa yang bisa dilakukan administrator IT atau pengacara dengan sedikit pengetahuan teknis?

• Verifikasi DKIM: di Gmail, menu "Tampilkan asli" langsung menampilkan hasil verifikasi DKIM di bagian atas halaman. "PASS" mengonfirmasi integritas pesan sejak pengiriman. "FAIL" atau "SOFTFAIL" menandakan adanya perubahan.
• Analisis header: alat seperti MXToolbox Header Analyzer atau Google Admin Toolbox secara otomatis mem-parsing rantai Received: dan menandai inkonsistensi temporal.
• Konsistensi Message-ID / Date: seorang analis dapat membandingkan timestamp yang dikodekan dalam Message-ID dengan nilai Date: yang dideklarasikan.
• Log server: jika email melewati server yang Anda administrasikan, log SMTP menyimpan tanggal dan waktu sebenarnya saat pesan diterima, terlepas dari header apa pun.

Singkatnya, alat deteksi tersedia, gratis, dan tidak memerlukan keahlian forensik tingkat lanjut. Seorang admin IT yang cukup penasaran dapat memeriksa integritas sebuah email dalam waktu kurang dari dua menit.

Satu-satunya kasus sah perubahan tanggal massal: migrasi IMAP

Ada satu skenario di mana ratusan ribu email berakhir dengan tanggal yang salah tanpa niat jahat apa pun: migrasi IMAP.

Bayangkan Anda baru saja menyelesaikan migrasi 150 kotak Exchange ke Google Workspace. Senin pagi, tiket mulai berdatangan. Para pengguna melaporkan bahwa semua email lama mereka menampilkan tanggal yang sama, yaitu tanggal akhir pekan migrasi. Kotak masuk mereka tidak bisa digunakan.

Yang terjadi sudah terdokumentasi dan dapat diprediksi: alat migrasi (BitTitan, CloudM, imapsync, apa pun itu) menempatkan email ke Google Workspace melalui IMAP APPEND. Alat tersebut menentukan INTERNALDATE yang sesuai dengan tanggal migrasi, bukan tanggal asli email. Akibatnya: Outlook, yang secara default mengurutkan berdasarkan INTERNALDATE, menampilkan tanggal migrasi untuk semua pesan. Artikel Mengapa Email Menampilkan Tanggal Salah Setelah Migrasi menjelaskan mekanisme ini secara terperinci.

Header Date: asli tetap utuh di setiap pesan. Tanda tangan DKIM tetap utuh. Isi pesan tidak berubah sama sekali. Hanya INTERNALDATE di sisi server yang salah.

Masalah ini memengaruhi BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO, dan semua alat yang menggunakan IMAP APPEND tanpa menjaga INTERNALDATE dengan benar. Artikel BitTitan MigrationWiz: Perbaiki Tanggal Email membahas kekhasan alat tersebut. Checklist Migrasi Email mencantumkan poin-poin yang perlu diperiksa sebelum dan sesudah migrasi untuk menghindari jenis masalah ini.

Perbedaan antara memperbaiki dan memalsukan

Koreksi yang dilakukan Redate.io adalah kebalikan dari upaya pemalsuan. Engine koreksi proprietary menganalisis rantai header setiap pesan, mengidentifikasi tanggal asli yang dikodekan dalam header Date: (RFC 2822) yang tidak pernah berubah, lalu memperbaiki metadata tanggal agar selaras dengan informasi autentik yang sudah ada dalam pesan tersebut.

Header Date: adalah sumber kebenaran. Header itu ditulis oleh klien email pengirim saat pengiriman. Header itu dicakup oleh tanda tangan DKIM. Header itu tidak dimodifikasi oleh Redate.io. Yang diperbaiki adalah ketidaksesuaian yang diperkenalkan oleh alat migrasi, bukan tanggal aslinya.

Memperbaiki 47.000 email setelah migrasi yang gagal tanpa kehilangan satu pun, tanpa merusak utas percakapan, tanpa merusak lampiran, tanpa memicu error 429 pada pukul 3 pagi di API Google: itu adalah pipeline analisis multi-tahap dengan penanganan kasus tepi (S/MIME, PGP, encoding non-ASCII dalam RFC 2047, struktur multipart yang kompleks). Skrip Python lima baris tidak akan bertahan pada kotak produksi pertama yang ditemuinya. Artikel Bisakah Tanggal Email Diperbaiki Setelah Migrasi? menjelaskan mengapa pendekatan DIY berisiko pada volume nyata.

Redate.io memindai kotak mail secara gratis, mengidentifikasi email dengan tanggal yang salah, dan melakukan koreksi melalui pipeline validasi yang memeriksa setiap pesan secara individual. File asli disimpan dalam folder backup yang terlihat selama 30 hari. Jika ada yang tidak beres, rollback dimungkinkan.

Migrasi Anda menggeser tanggal email? Jalankan scan gratis di Redate.io untuk mengukur sejauh mana masalahnya sebelum memutuskan langkah selanjutnya.