Mengubah Tanggal Email yang Diterima: Mungkinkah?

Pertanyaan yang selalu muncul (dan mengapa ada dua situasi yang sangat berbeda di baliknya)

Coba ketik "mengubah tanggal email yang diterima" di Google. Anda akan menemukan puluhan utas di forum Microsoft Q&A, thread Reddit, pertanyaan di Quora. Permintaannya jelas, tetapi alasan di baliknya bisa sangat berbeda tergantung siapa yang bertanya.

Ada yang ingin memalsukan tanggal secara retroaktif, dengan alasan yang lebih baik tidak dibayangkan. Dan ada administrator IT yang, setelah migrasi IMAP, melihat semua email mereka menampilkan tanggal yang sama, yaitu tanggal migrasi, dan hanya ingin mengembalikan tanggal aslinya. Kedua situasi ini tidak ada hubungannya satu sama lain, meski menggunakan kata kunci pencarian yang sama.

Artikel ini menjawab keduanya. Singkatnya: untuk kasus pertama, modifikasi tidak bisa dilakukan tanpa meninggalkan jejak. Untuk kasus kedua, koreksi ini sepenuhnya sah dan itulah tepatnya yang dilakukan Redate.io.

Pertama: apa sebenarnya "tanggal" sebuah email?

Sebuah email tidak menyimpan satu tanggal saja. Ada beberapa tanggal, tersimpan di tempat berbeda, dikontrol oleh entitas yang berbeda pula.

Header Date: (RFC 2822)

Ini adalah tanggal yang dicatat oleh klien pengirim ke dalam pesan saat email dikirim. Tanggal ini terlihat di header mentah dalam format:

Date: Mon, 14 Oct 2024 09:32:11 +0200

Header ini merupakan bagian dari isi pesan. Secara teknis bisa diubah jika Anda mengakses file mentahnya. Tapi kata "secara teknis" di sini sangat penting.

Header Received:

Setiap server email yang dilalui sebuah pesan akan menambahkan header Received: tersendiri dengan timestamp. Header-header ini membentuk rantai kronologis, dari server pengirim hingga kotak masuk Anda. (Omong-omong, jika Anda pernah mencoba membaca header mentah sebuah email, Anda tahu itu bukan bacaan santai. Puluhan baris metadata teknis, dengan urutan dari yang paling baru ke yang paling lama.)

INTERNALDATE IMAP

Ini adalah metadata yang paling penting untuk memahami mengapa beberapa modifikasi tidak memberikan efek tampilan apa pun. INTERNALDATE adalah atribut yang tersimpan di sisi server IMAP, terpisah dari isi pesan. Inilah yang digunakan sebagian besar klien email untuk mengurutkan pesan di dalam folder. Outlook menggunakannya. Gmail juga. Apple Mail, dalam sebagian besar kasus, begitu pula.

INTERNALDATE tidak ada di dalam pesan. Ia tersimpan di database server. Anda tidak bisa mengubahnya dengan mengedit file .eml di komputer Anda.

Apa yang sebenarnya terjadi saat Anda mengedit secara lokal

Mengedit file .eml

Secara teknis, file .eml adalah file teks biasa. Anda bisa membukanya di editor teks, mengubah baris Date:, lalu menyimpannya. Jika Anda mengimpor ulang file ini ke klien email lokal, tanggal yang ditampilkan mungkin berubah, tergantung kliennya.

Tetapi inilah yang tidak berubah:

• INTERNALDATE di server IMAP (tetap utuh)
• Header Received: yang ditambahkan oleh server perantara
• Log pengiriman di Google, Microsoft, atau penyedia layanan Anda
• Tanda tangan DKIM, jika pesan memilikinya

Hasilnya: di mesin lokal Anda, tanggalnya mungkin berbeda. Tapi dari Outlook yang terhubung ke Exchange Online, atau Gmail di browser, tidak ada yang berubah.

Mengubah jam sistem

Beberapa forum menyarankan untuk mengubah jam di komputer Anda agar "mengelabui" klien email. Ini tidak berhasil. Outlook dan Gmail tidak membaca jam sistem untuk menampilkan tanggal email yang diterima. Mereka membaca INTERNALDATE dari server, atau header pesan. Jam lokal sama sekali tidak terlibat dalam proses ini.

Manipulasi melalui Thunderbird

Thunderbird menawarkan lebih banyak fleksibilitas dibanding sebagian besar klien email. Dengan ekstensi tertentu atau dengan memanipulasi langsung profil (file mbox, file .msf), beberapa orang mencoba mengubah tampilan tanggal. Ini bisa berhasil di Thunderbird itu sendiri, untuk email yang tersimpan secara lokal dalam mode POP3. Tapi begitu Thunderbird terhubung via IMAP, ia akan melakukan sinkronisasi ulang dengan server. "Koreksi" tersebut akan hilang pada sinkronisasi berikutnya.

DKIM: penghalang tak terlihat yang jarang disebutkan siapa pun

Sebagian besar email yang dikirim sejak 2018 ditandatangani dengan DKIM (DomainKeys Identified Mail). Tanda tangan DKIM terlihat seperti ini di header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
  d=example.com; s=default;
  h=Date:From:To:Subject:Message-ID;
  bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
  b=ABC123...

Field h= mencantumkan header yang dicakup oleh tanda tangan. Dalam contoh di atas, Date ikut ditandatangani. Jika Anda mengubah header Date: dari pesan tersebut, verifikasi DKIM akan gagal. Server email mana pun, alat forensik apa pun, bisa mendeteksi modifikasi ini dengan menghitung ulang tanda tangannya.

Ini bukan perlindungan yang sempurna (pengirim dengan niat jahat mengendalikan kunci DKIM-nya sendiri dan bisa menandatangani apa saja saat pengiriman). Tapi untuk email yang sudah diterima dan sudah ditandatangani, mengubah header Date: meninggalkan jejak yang bisa terdeteksi.

Log server: sumber kebenaran yang sesungguhnya

Bahkan jika Anda berhasil mengubah semua metadata yang terlihat dari sebuah email (header, INTERNALDATE, semuanya), penyedia layanan tetap menyimpan log mereka sendiri.

Google Workspace mencatat setiap pesan dalam log audit di Admin Console. Microsoft 365 melakukan hal yang sama di Compliance Center (Purview). Log ini menyertakan timestamp pengiriman, terlepas dari apa yang ditampilkan di klien email. Pengacara, tim hukum, atau tim keamanan IT bisa mengakses data ini. Tanggal yang terlihat di Outlook tidak berlaku sebagai bukti di pengadilan atau saat audit keamanan.

Untuk lebih tepatnya: bahkan administrator yang memiliki akses ke kotak surat melalui delegasi domain tidak bisa menulis ulang log-log tersebut secara retroaktif. Log itu berada di luar jangkauan pengguna mana pun, termasuk yang memiliki hak istimewa sekalipun.

Kasus yang sah: koreksi pasca-migrasi

Anda baru saja menyelesaikan migrasi 150 kotak surat dari Exchange on-premise ke Microsoft 365. Senin paginya, tiket mulai berdatangan: "semua email lama saya bertanggal Jumat kemarin". Tanggal migrasi.

Ini adalah masalah yang sudah terdokumentasi dengan baik dan sama sekali berbeda dari apa yang baru saja kita bahas. Di sini, tidak ada yang mencoba memalsukan apa pun. Tanggal asli yang sebenarnya masih ada, utuh, di dalam header Date: setiap pesan. Masalahnya berasal dari tempat lain: alat migrasi (BitTitan MigrationWiz, CloudM, imapsync, atau yang lainnya) menyisipkan header Received: dengan tanggal migrasi di awal rantai. Outlook, yang dalam konteks tertentu mengandalkan header Received: terbaru ketimbang INTERNALDATE, menampilkan tanggal itu sebagai gantinya.

Dalam kasus ini, "koreksi" berarti memulihkan konsistensi antara apa yang dikatakan pesan (header Date: asli, yang masih ada) dan apa yang diyakini server (INTERNALDATE, yang diatur saat migrasi). Ini bukan pemalsuan. Ini adalah pemulihan.

Inilah persis masalah yang ditimbulkan oleh migrasi yang tidak dikonfigurasi dengan benar pada ribuan kotak surat. Dan itulah yang diselesaikan oleh Redate.io.

Mengapa pendekatan "lakukan sendiri" gagal dalam skala besar

Memahami masalahnya adalah satu hal. Memperbaikinya pada 40.000 email yang tersebar di 150 kotak surat tanpa kehilangan satu pun adalah hal yang lain sama sekali.

Skrip yang ditemukan di GitHub atau Stack Overflow mungkin berfungsi pada 20 email percobaan. Tapi di lingkungan produksi, masalah mulai muncul karena hal-hal yang tidak diantisipasi oleh penulis skrip:

• Email yang ditandatangani S/MIME atau dienkripsi PGP memiliki struktur yang tidak bisa dimanipulasi seperti pesan biasa
• Pesan multipart dengan batas MIME yang tidak standar menyebabkan error saat parsing
• Header yang diencode dalam RFC 2047 (karakter non-ASCII di field From: atau Subject:) merusak parser yang sederhana
• API Google dan Microsoft menerapkan rate limiting: pukul 3 pagi saat batch 30.000 email sedang berjalan, error 429 Too Many Requests tidak tertangani, skrip berhenti, dan tidak ada yang tahu di mana tepatnya ia berhenti
• Tidak ada mekanisme rollback: jika sebuah pesan rusak selama proses, tidak ada cara untuk mengembalikannya

Redate.io menyimpan salinan setiap email asli dalam folder cadangan yang bisa dilihat selama 30 hari. Setiap koreksi diverifikasi satu per satu. Pipeline analisisnya menangani ratusan tanda tangan alat migrasi yang diketahui, termasuk semua kasus tepi yang tidak akan ditangani oleh skrip buatan sendiri.

Untuk detail lebih lanjut berdasarkan alat yang digunakan: BitTitan MigrationWiz dan tanggal email, atau CloudM Migrate: cara memperbaiki tanggal email yang salah.

Apa yang berubah, apa yang tidak pernah berubah

Perbedaannya jelas. Tiga baris pertama dalam tabel menggambarkan modifikasi yang bersifat dangkal atau bisa terdeteksi. Baris terakhir menggambarkan koreksi metadata yang sah, selaras dengan isi asli pesan, setelah migrasi yang menimbulkan inkonsistensi.

Jika Anda berada dalam situasi yang digambarkan di baris terakhir tabel, setelah migrasi dengan imapsync, BitTitan, CloudM, atau alat lainnya, Redate.io memang dibuat untuk itu.

Email Anda menampilkan tanggal migrasi, bukan tanggal aslinya? Pindai kotak surat Anda secara gratis dengan Redate.io dan lihat persis berapa banyak email yang terdampak sebelum mengambil keputusan.