Ketika kita berbicara tentang “Otentikasi Email”, kita merujuk pada teknik yang dimaksudkan untuk memberi penerima pesan tingkat kepastian bahwa pesan tersebut benar-benar berasal dari sumber yang diklaim. Idénya adalah untuk mencapai suatu tingkat pertahanan terhadap email palsu, seperti phishing dan spoofing, yang dapat mengikis kepercayaan penerima dalam menerima email. Dengan demikian, tindakan mengirim email yang terautentikasi tidak, dengan sendirinya, menyatakan bahwa email tersebut adalah email yang baik atau diinginkan; itu hanya berarti bahwa surat tersebut sedemikian rupa sehingga reputasi untuk pihak yang terautentikasi dapat secara andal dibangun dan digunakan dalam keputusan penerimaan dan penempatan email.
Ada dua bentuk utama otentikasi email yang digunakan saat ini—Sender Policy Framework (SPF) dan DomainKeys Identified Mail (DKIM). Dalam posting blog ini, saya akan menjelaskan apa itu SPF, dan bagaimana cara kerjanya.
Ikhtisar SPF
Sender Policy Framework (SPF), untuk memparafrase RFC 7208, adalah protokol yang tidak hanya memungkinkan suatu organisasi untuk mengotorisasi host dan jaringan untuk menggunakan nama domainnya saat mengirim email, tetapi juga menyediakan cara bagi host penerima untuk memeriksa otorisasi tersebut.
Ketika Anda selesai membaca posting ini, saya berharap Anda telah mempelajari hal-hal berikut:
SPF adalah sistem otentikasi berbasis jalur.
Kebijakan SPF dinyatakan dalam catatan DNS TXT.
Validasi terkait dengan domain Return-Path (apa yang kami sebut di SparkPost sebagai “domain bounce”) atau domain HELO.
Validasi dapat dilakukan lebih awal dalam transaksi SMTP, jadi ini adalah pemeriksaan yang baik untuk digunakan untuk menolak email yang tidak terautentikasi dengan cepat.
Ini rentan terhadap persentase negatif palsu yang relatif tinggi.
Otentikasi “Berbasis Jalur”
SPF dianggap sebagai sistem otentikasi berbasis jalur karena itu terikat hanya pada jalur yang ditempuh pesan untuk sampai dari asalnya ke tujuannya. Ketika server pengirim memulai transaksi SMTP dengan server penerima, server penerima akan menentukan apakah server pengirim diotorisasi untuk mengirim pesan tersebut berdasarkan kebijakan SPF domain. Itu sepenuhnya keputusan yang didasarkan pada dari mana pesan berasal, tanpa ada hubungannya dengan konten pesan tersebut.
Menyatakan Kebijakan SPF
Catatan kebijakan SPF suatu domain adalah hanya catatan DNS TXT yang diformat secara khusus, biasanya berisi satu atau lebih “mekanisme” berikut:
v=spf1 – Token pertama yang diperlukan untuk menunjukkan bahwa catatan TXT adalah catatan SPF (sebuah domain dapat memiliki beberapa catatan TXT)
ipv4, ipv6 – Digunakan untuk menentukan alamat IP dan jaringan yang diizinkan untuk mengirim email untuk domain tersebut
a – Jika domain pengirim memiliki catatan DNS “A” yang mengarah ke IP pengirim, IP tersebut diizinkan
mx – Jika IP pengirim juga merupakan salah satu catatan MX untuk domain pengirim, IP tersebut diizinkan
all – Token terakhir yang diperlukan, selalu dimodifikasi:
-all – Hanya apa yang tercantum di sini yang dapat lulus; tolak kegagalan.
~all – Hal-hal yang tidak ada di sini harus softfail; terima tetapi catat.
?all – Tidak yakin apakah hal-hal yang tidak ada di sini harus lulus.
+all – Kami rasa SPF tidak berguna; lulus segala sesuatu.
Mekanisme lain yang kurang umum tetapi masih banyak digunakan adalah:
include – Digunakan ketika suatu domain tidak hanya memiliki servernya sendiri, tetapi juga menggunakan server orang lain. Harus digunakan dengan hati-hati. Setiap include adalah query DNS lain, dan catatan SPF tidak dapat memerlukan lebih dari sepuluh query DNS untuk menyelesaikan.
redirect – Ketika domain A dan domain B dimiliki oleh entitas yang sama dan menggunakan infrastruktur yang sama. Pemilik biasanya ingin mempertahankan satu salinan catatan SPF untuk keduanya, dan mengonfigurasi B untuk mengalihkan query ke A.
exists – Jika suatu domain memiliki banyak blok jaringan kecil dan tidak berurutan, ia dapat menggunakan mekanisme ini untuk menentukan catatan SPF-nya, alih-alih mencantumkan semuanya. Berguna untuk tetap dalam batas ukuran (512 byte) untuk respons DNS.
Catatan tentang Mekanisme “ptr”
Mekanisme terakhir, “ptr” ada dalam spesifikasi asli untuk SPF, tetapi telah dinyatakan “jangan digunakan” dalam spesifikasi saat ini. Mekanisme ptr digunakan untuk menyatakan bahwa jika alamat IP pengirim memiliki catatan DNS PTR yang mengarah ke nama domain yang dipertanyakan, maka alamat IP tersebut diizinkan untuk mengirim email untuk domain tersebut.
Status terkini dari mekanisme ini adalah bahwa itu tidak boleh digunakan. Namun, situs yang melakukan validasi SPF harus menerimanya sebagai sah.
Beberapa Contoh Catatan SPF
Berikut adalah beberapa contoh catatan, dan artinya. Contoh ini menunjukkan alamat RFC 1918, tetapi saya menyadari bahwa alamat semacam itu tidak akan pernah muncul dalam catatan SPF yang nyata.
Catatan MX, satu alamat IP, satu jaringan IP, softfail segala hal lainnya:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Catatan A, dua jaringan IP, tolak segala hal lainnya:
“v=spf1 a ipv4:10.0.3.0/23 ipv4:192.168.55.0/26 -all”
Kami tidak mengirim email:
“v=spf1 -all”
Kami rasa SPF itu bodoh:
“v=spf1 +all”
Catatan SPF untuk domain sparkpostmail.com (mekanisme redirect digunakan)
“v=spf1 redirect=_spf.sparkpostmail.com”
Catatan SPF untuk _spf.sparkpostmail.com (mekanisme exists dan ptr digunakan):
“v=spf1 exists:%{i}._spf.sparkpostmail.com ptr:sparkpostmail.com ptr:spmta.com ptr:flyingenvelope.com ~all”
Di SparkPost, kami saat ini menggunakan mekanisme ptr dalam catatan SPF kami. Kami telah menemukan bahwa itu perlu karena kurangnya dukungan universal untuk memvalidasi mekanisme exists. Dan sampai saat ini, kami belum melihat kegagalan SPF yang dihasilkan akibat penggunaan mekanisme ptr.
Bagaimana Cara Kerja Otentikasi SPF?
Berikut adalah apa yang terlihat seperti transaksi SMTP tipikal ketika SPF terlibat:
Server pengirim (klien) terhubung ke server penerima
Server penerima mencatat alamat IP yang menghubungkan klien
Mereka bertukar sapaan, termasuk nama host HELO klien
Klien mengeluarkan perintah SMTP MAIL FROM
Server penerima sekarang dapat mencari catatan SPF untuk domain MAIL FROM atau nama host HELO untuk menentukan apakah IP yang terhubung diizinkan untuk mengirim email untuk domain tersebut, dan memutuskan apakah akan menerima pesan tersebut atau tidak.
MAIL FROM atau HELO – Mana yang Harus Diperiksa?
Spesifikasi SPF mengatur bahwa situs penerima HARUS memeriksa SPF untuk domain MAIL FROM, dan MEREKOMENDASIKAN memeriksanya untuk nama host HELO. Dalam praktiknya, pemeriksaan hanya terjadi pada domain MAIL FROM, kecuali mungkin pada saat ketika alamat MAIL FROM adalah pengirim NULL (yaitu, “<>”), dalam hal ini nama host HELO adalah satu-satunya identitas yang tersedia.
SPF Tidak Kebal
Sementara tampaknya cara yang relatif sederhana untuk mengotentikasi email, SPF rentan terhadap kegagalan dalam bentuk negatif palsu. Kegagalan ini dapat terjadi lebih sering daripada yang nyaman bagi banyak orang.
Berikut adalah dua skenario umum di mana email yang sepenuhnya sah dapat gagal validasi SPF dan tampak seperti penipuan:
Penerusan otomatis, di mana pesan yang dikirim ke jsmith@alumni.university.edu, kotak surat yang diatur untuk secara otomatis meneruskan semua email ke jsmith@isp.com
Daftar surat, di mana email yang dikirim ke talk-about-stuff@listserv.foo.com di “exploded” dan dikirim ke setiap pelanggan
Dalam kedua kasus ini, jika Return-Path tidak berubah dari aslinya, email dapat gagal pemeriksaan SPF (tergantung pada modifikasi yang digunakan dengan mekanisme ‘all’). Ini karena ia tiba di tujuan akhirnya dari server perantara, bukan yang asli, dan server perantara itu kemungkinan tidak ada dalam catatan SPF domain. Teknik yang disebut “Skema Penulisan Pengirim” atau “SRS” dapat mengurangi risiko ini, dan beberapa situs besar telah mengadopsinya, tetapi itu tidak universal.
Penutup
Jadi itulah otentikasi SPF, cara kerjanya, cara menyatakan kebijakan SPF, dan apa saja jebakan yang ada dalam menggunakan SPF. SPF adalah skema otentikasi email pertama yang mencapai adopsi yang luas, tetapi itu bukan satu-satunya yang ada. Otentikasi SPF paling efektif ketika diterapkan bersama dengan teknik anti-penipuan lainnya.