Ketika kita berbicara tentang "Otentikasi Email", kita mengacu pada teknik yang memberikan kepada penerima pesan suatu tingkat kepastian bahwa pesan tersebut benar-benar berasal dari sumber pesan yang diklaim. Ide di balik teknik tersebut adalah untuk mencapai tingkat pertahanan tertentu terhadap email palsu, seperti phishing dan spoofing, email yang dapat mengikis kepercayaan penerima dalam menerima email. Meskipun demikian, tindakan mengirim email yang diautentikasi tidak menyatakan bahwa email tersebut adalah email yang baik atau email yang dicari; ini hanya berarti bahwa email tersebut sedemikian rupa sehingga reputasi pihak yang diautentikasi dapat dibangun dengan andal dan digunakan dalam keputusan penerimaan dan penempatan email.

Ada dua bentuk autentikasi email yang digunakan saat ini:

• Sender Policy Framework (SPF)

• Domain Keys Identified Mail (DKIM)

Dalam tulisan hari ini, saya akan membahas apa itu DKIM dan bagaimana cara kerjanya.

Ikhtisar DKIM

Unlike its authentication counterpart SPF, which provides a way for a domain to authorize a host to send mail on its behalf, DKIM provides a way for an entity (domain, organization, person, etc.) to take responsibility for a message, independent of the entity that actually sent the message. While in many cases the responsible entity and the sending entity will be the same, or at least closely related, with DKIM there’s no requirement that this be so.

Tujuan saya untuk Anda melalui artikel ini adalah agar Anda mempelajari dan memahami konsep-konsep berikut tentang DKIM:

• DKIM adalah otentikasi "berbasis konten", tidak seperti SPF "berbasis jalur".

• Entitas yang bertanggung jawab menegaskan tanggung jawabnya dengan "menandatangani" pesan dengan sepasang hash kriptografi yang disisipkan 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 dikirimkan oleh server pengirim.

• Kegagalan validasi bisa jadi sulit dipecahkan.

• 
  

Autentikasi "Berbasis Konten"

DKIM disebut sebagai otentikasi "berbasis konten", dan bukan "berbasis jalur", karena apakah sebuah pesan lolos validasi DKIM atau tidak hanya didasarkan pada apakah kontennya telah berubah atau tidak antara saat ditandatangani dan saat validasi dicoba.

Penandatanganan dan Validasi DKIM

Organisasi yang ingin menandatangani email dengan DKIM pertama-tama akan membuat dua kunci kriptografi. Salah satu kunci disimpan secara pribadi dan tersedia untuk server pengirim untuk penandatanganan email, dan kunci yang lain akan dipublikasikan di DNS untuk digunakan oleh domain penerima dalam upaya memvalidasi tanda tangan. Metode untuk menghasilkan kunci-kunci ini dan memasangnya bergantung pada platform dan di luar cakupan tulisan ini, meskipun nanti saya akan menjelaskan penerbitan di DNS untuk kunci DKIM publik.

Header Tanda Tangan DKIM

Untuk memulai pemahaman kita tentang DKIM, pertama-tama mari kita lihat tajuk DKIM-Signature:

DKIM-Signature: v=1; a = rsa-sha256; d=welcome.foo.com; s = pemberitahuan; c = santai / rileks; q=dns/txt; i=@welcome.foo.com; t=1454417737; h=Dari:Balas-Ke:Subject:Tanggal:Message-ID:Kepada:MIME-Version:Content-Type; bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfP vRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu 8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=;

Header DKIM-Signature adalah serangkaian pasangan nilai-kunci, beberapa di antaranya lebih menarik bagi pembaca daripada yang lain, tetapi saya akan menjelaskan semuanya di sini.

Pertama, kita akan melihat yang paling menarik bagi pembaca:

• v=1; – Specifies the DKIM version (1 is the only valid value)

• a=rsa-sha256; – The algorithm used to construct the cryptographic hashes

• c=relaxed/relaxed; – There are two sets of rules regarding removal of whitespace in the headers and body that can be applied when creating the hashes in a DKIM signature; these rules are called “canonicalization rules” (hence the key of c) and the rulesets are either “relaxed” or “strict”.

• t=1454417737; – The timestamp of when the signature was created.

Ketiga bagian header ini berisi informasi tanda tangan yang sesungguhnya:

• bh=e+6RkdhJe69wcQKtRKw9rpDgkkPPbZ8Xwj/2Hi243Sc=; - This is the hash of the body of the message.

• h = Dari:Balas-Ke:Subjek:Tanggal:ID-Pesan:Kepada:MIME-Versi:Jenis-Konten; - This is a list of the headers that were used to create the signature data shown below.

• b=KhK4OjejS4QEBr1RwL/naZKBNLoFnR/3lmDOWZC3av4c2aH5Yg/D4vqhh1CpcyfPvRm7cp5EvrnPEsOA7r3E15jarzNFNHXtwjxCFn4g8StsXFOio9vHkO7bmp6t2aLu8bPkX6cNHgULYS6TdqYd65y5xCDMEaQ9a3mnhF2TQss=; - This is the acutal DKIM signature data

Ketiga bagian ini adalah yang paling menarik bagi server penerima yang akan memvalidasi tanda tangan:

• d=welcome.foo.com; - This identifies the domain that signed the message

• s = pemberitahuan; - The selector; domains can have multiple selectors that they use when signing messages.

• i=@welcome.foo.com; - This is the identity on whose behalf the message was signed. Syntactically, this will look like an email address, and might even be one; the localpart of the email address can be empty, as in this example, and the domain part must be the same as, or a subdomain of, the domain in the d= part of the signature.

Alasan mengapa bagian ini menarik bagi server penerima adalah karena bagian ini menyediakan informasi yang diperlukan untuk membantu penerima memvalidasi tanda tangan.

DKIM Validation

In addition ke requirement mentioned that the i= domain must be the same as or a sub-domain of the d= domain, the d= and s= bits are used by the validator to look up the signer’s public DKIM key in DNS. The key is a TXT record in DNS, and it’s always found di location selector._domainkey.domain. So, in our example here, with s=notices and d=welcome.foo.com, the public DKIM key would be found in DNS at pemberitahuan._domainkey.welcome.foo.com, and it might look something like this:

pemberitahuan._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 (p= bit) untuk menghasilkan kumpulan hash dari pesan; jika hash tersebut cocok, maka pesan tersebut tidak diubah dalam perjalanan, dan pesan tersebut dapat berkontribusi pada, dan mungkin mendapatkan keuntungan dari, reputasi apa pun yang dimiliki oleh penandatangan pesan tersebut.

Kegagalan Validasi dan Pemecahan Masalah

Saya sebutkan di atas bahwa kegagalan DKIM bisa jadi sulit dipecahkan, dan saya akan menjelaskan mengapa demikian di sini.

Beberapa kegagalan validasi DKIM memiliki penyebab yang jelas, seperti pesan tidak ditandatangani, atau kunci publik domain penandatanganan tidak ditemukan di DNS atau tidak benar secara sintaksis, atau mungkin pesan tersebut jelas-jelas diubah dalam perjalanan. Ketika kegagalan seperti itu terjadi, mudah untuk mengetahui masalahnya dan merekomendasikan solusinya. Namun, yang paling sulit, dan yang menyebabkan pengalaman dukungan yang paling membuat frustasi, adalah kasus-kasus di mana pesan ditandatangani, kunci publiknya ada di DNS, dan pesannya tidak diubah, tetapi validator melaporkan bahwa tanda tangan gagal divalidasi.

Alasan mengapa hal ini sulit untuk dipecahkan adalah karena tidak ada cara yang nyata bagi kedua belah pihak untuk mereproduksi kondisi di mana pesan tersebut ditandatangani dan divalidasi. Pesan tersebut memiliki header DKIM-Signature yang berisi hash yang dibuat oleh penanda tangan pada saat penandatanganan, tetapi validator tidak memiliki akses ke infrastruktur penanda tangan sehingga tidak dapat mencoba mereproduksi tanda tangan dalam kondisi penanda tangan. Demikian pula, penanda tangan kemungkinan tidak memiliki akses ke infrastruktur validator sehingga 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 sendiri biasanya tidak berdampak pada penempatan pengiriman. Menurut pengalaman saya, kegagalan seperti itu mendorong lebih banyak tiket dukungan daripada jenis masalah DKIM lainnya.