CUSTOMIZE Ketika kami berbicara tentang "Email Authentication", kami merujuk pada teknik yang memberikan kepada penerima pesan tingkat kepastian bahwa pesan tersebut benar-benar berasal dari sumber yang diakui dari pesan tersebut.
Ketika kita berbicara tentang "Email Authentication", kita mengacu pada teknik yang memberikan kepada penerima pesan beberapa tingkat kepastian bahwa pesan tersebut benar-benar berasal dari sumber yang diklaim. Ide di balik teknik tersebut adalah untuk mencapai beberapa tingkat pertahanan terhadap email penipuan, seperti phishing dan spoofing, email yang dapat mengikis kepercayaan penerima dalam menerima email. Namun, tindakan mengirim email yang terautentikasi tidak menyatakan bahwa email tersebut baik atau diinginkan; itu hanya berarti bahwa email tersebut sedemikian rupa sehingga reputasi untuk pihak yang terautentikasi dapat dibangun dengan andal dan digunakan dalam keputusan penerimaan dan penempatan email.
Ada dua bentuk otentikasi email yang digunakan saat ini:
Sender Policy Framework (SPF)
Domain Keys Identified Mail (DKIM)
Dalam postingan hari ini, saya membahas apa itu DKIM dan bagaimana cara kerjanya.
Ikhtisar DKIM
Berbeda dengan rekan autentikasinya, SPF, yang menyediakan cara bagi sebuah domain untuk mengotorisasi host guna mengirim email atas namanya, DKIM menyediakan cara bagi suatu entitas (domain, organisasi, individu, dll.) untuk mengambil tanggung jawab atas sebuah pesan, terlepas dari entitas yang sebenarnya mengirim pesan tersebut. Meskipun dalam banyak kasus entitas yang bertanggung jawab dan entitas yang mengirim akan sama, atau setidaknya terhubung erat, dengan DKIM tidak ada persyaratan bahwa hal ini harus demikian.
Tujuan saya untuk Anda dengan posting ini adalah Anda belajar dan memahami konsep-konsep berikut tentang DKIM:
DKIM adalah autentikasi berbasis konten, berbeda dengan SPF yang berbasis jalur.
Entitas yang bertanggung jawab menyatakan tanggung jawabnya dengan "menandatangani" pesan menggunakan sepasang hash kriptografi yang dimasukkan dalam header pesan.
Validasi DKIM dilakukan oleh domain penerima yang mencoba menghasilkan dua hash yang sama.
Validasi DKIM tidak dapat diselesaikan dalam banyak kasus hingga pesan lengkap telah ditransmisikan oleh server pengirim.
Kegagalan validasi dapat sulit untuk diatasi.
“Content-Based” Authentication
Penandatanganan dan Validasi DKIM
Organisasi yang ingin menandatangani email dengan DKIM akan terlebih dahulu menghasilkan dua kunci kriptografi. Salah satu kunci disimpan secara pribadi dan tersedia untuk server pengirim guna penandatanganan email, dan yang lainnya dibuat publik di DNS untuk digunakan oleh domain penerima dalam upaya memvalidasi tanda tangan tersebut. Metode untuk menghasilkan kunci-kunci ini dan menginstalnya bergantung pada platform dan di luar cakupan pos ini, meskipun nantinya saya akan menjelaskan penerbitan kunci DKIM publik di DNS.
Header DKIM-Signature
Untuk memulai pemahaman kita tentang DKIM, mari kita lihat dulu header DKIM-Signature:
DKIM-Signature: v=1; a=rsa-sha256; d=welcome.foo.com; s=notices; c=relaxed/relaxed; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;
Header DKIM-Signature adalah serangkaian pasangan kunci-nilai, beberapa lebih menarik bagi pembaca daripada yang lain, tetapi saya akan menjelaskan semuanya di sini.
Pertama, kita akan melihat yang kebanyakan hanya menarik bagi pembaca:
v=1; – Menentukan versi DKIM (1 adalah satu-satunya nilai yang valid)
a=rsa-sha256; – Algoritma yang digunakan untuk membangun hash kriptografi
c=relaxed/relaxed; – Ada dua set aturan mengenai penghapusan spasi di header dan body yang dapat diterapkan saat membuat hash dalam tanda tangan DKIM; aturan ini disebut “aturan kanonikalisasi” (oleh karena itu kunci c) dan set aturannya bisa “relaxed” atau “strict”.
t=1454417737; – Waktu saat tanda tangan dibuat.
Tiga bagian header ini berisi informasi tanda tangan yang sesungguhnya:
bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; – Ini adalah hash dari body pesan.
h=From:Reply-To:Subject:Date:Message-ID:To:MIME-Version:Content-Type; – Ini adalah daftar header yang digunakan untuk membuat data tanda tangan yang ditunjukkan di bawah ini.
b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; – Ini adalah data tanda tangan DKIM yang sebenarnya
Tiga bagian ini paling penting bagi server penerima yang akan memvalidasi tanda tangan:
d=welcome.foo.com; – Ini mengidentifikasi domain yang menandatangani pesan
s=notices; – Selector; domain dapat memiliki beberapa selector yang mereka gunakan saat menandatangani pesan.
i=@welcome.foo.com; – Ini adalah identitas atas nama siapa pesan tersebut ditandatangani. Secara sintaksis, ini akan terlihat seperti alamat email, dan mungkin juga benar; bagian lokal dari alamat email dapat kosong, seperti dalam contoh ini, dan bagian domain harus sama dengan, atau subdomain dari, domain di bagian d= pada tanda tangan.
Alasan bagian-bagian ini penting bagi server penerima adalah karena mereka menyediakan informasi yang diperlukan untuk membantu penerima memvalidasi tanda tangan.
DKIM Validation
Selain persyaratan yang disebutkan bahwa domain i= harus sama dengan atau sub-domain dari domain d=, bit d= dan s= digunakan oleh validator untuk mencari kunci publik DKIM penanda tangan di DNS. Kunci tersebut adalah catatan TXT di DNS, dan selalu ditemukan di lokasi selector._domainkey.domain. Jadi, dalam contoh kita di sini, dengan s=notices dan d=welcome.foo.com, kunci publik DKIM akan ditemukan di DNS di notices._domainkey.welcome.foo.com, dan mungkin terlihat seperti ini:
notices._domainkey.welcome.foo.com. teks deskriptif "v=DKIM1\; h=sha256\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDlXNDEHOstbxTkS0tjqy9qw2J 1mnjW5FBWQ4dyrYfrkr8/9VrtAY+eWcKMLUcR3mGFpk9QeHCXoILMJ22TmP1JfhzN NoCcMLffy39eWZKmtm4/Ry29qWBFvn2LKl5W3BBC3e4wQ14l+CQqY4C0QifIrPBwR pod8n+//qIpQIDAQAB\; s=email"
Validator menggunakan kunci tersebut (bit p=) untuk menghasilkan serangkaian hash dari pesan; jika hash tersebut cocok, maka pesan tidak diubah selama transit, dan pesan tersebut dapat berkontribusi pada, dan mungkin mendapatkan manfaat dari, reputasi yang ada untuk penanda tangan pesan.
Gagal Validasi dan Pemecahan Masalah
Saya menyebutkan sebelumnya bahwa kegagalan DKIM bisa sulit untuk ditangani, dan saya akan menjelaskan alasannya di sini.
Beberapa kegagalan validasi DKIM memiliki penyebab yang jelas, seperti pesan yang tidak ditandatangani, atau kunci publik domain penandatangan tidak ditemukan di DNS atau tidak benar secara sintaksis, atau mungkin pesan telah jelas diubah selama pengiriman. Ketika kegagalan semacam itu terjadi, mudah untuk mengetahui masalahnya dan merekomendasikan solusi. Namun, yang sulit, dan yang menyebabkan pengalaman dukungan paling membuat frustrasi, adalah kasus-kasus di mana pesan ditandatangani, kunci publik ada di DNS, dan pesan tidak jelas diubah, tetapi validator melaporkan bahwa tanda tangan gagal divalidasi.
Alasan mengapa hal ini sulit untuk ditangani adalah karena tidak ada cara nyata bagi kedua belah pihak untuk mereproduksi kondisi di mana pesan ditandatangani dan divalidasi. Pesan memiliki header DKIM-Signature yang memiliki hash yang dihasilkan oleh penandatangan pada saat penandatanganan, tetapi validator kemungkinan tidak memiliki akses ke infrastruktur penandatangan dan oleh karena itu tidak dapat mencoba mereproduksi tanda tangan di bawah kondisi penandatangan. Demikian pula, penandatangan mungkin tidak memiliki akses ke infrastruktur validator dan oleh karena itu tidak memiliki cara untuk mencoba memvalidasi pesan seperti yang dilakukan oleh validator.
Kegagalan seperti yang saya jelaskan di sini jarang terjadi, dan kegagalan validasi DKIM itu sendiri biasanya tidak berdampak pada penempatan pengiriman. Berdasarkan pengalaman saya, kegagalan semacam itu memicu lebih banyak tiket dukungan dibandingkan jenis masalah DKIM lainnya.
