Ketika kita berbicara tentang "Autentikasi Email", kita merujuk pada teknik yang bertujuan untuk memberikan kepada penerima pesan tingkat kepastian bahwa pesan tersebut benar-benar berasal dari sumber yang diklaim.
Business in a box.
Temukan solusi kami.
Bicaralah kepada tim penjualan kami
Ketika kita berbicara tentang “Email Authentication”, kita merujuk pada teknik yang dimaksudkan untuk memberikan kepada penerima pesan tingkat kepastian bahwa pesan tersebut benar-benar berasal dari sumber pesan yang diklaim. Idenya adalah untuk mencapai beberapa tingkat pertahanan terhadap email penipuan, seperti phishing dan spoofing, yang dapat mengikis kepercayaan penerima dalam menerima email. Yang dikatakan, tindakan mengirim email yang terautentikasi tidak, dengan sendirinya, menyatakan bahwa email tersebut baik atau diinginkan; itu hanya berarti bahwa email tersebut sedemikian rupa sehingga reputasi untuk pihak yang terautentikasi dapat dipercayai dan digunakan dalam keputusan penerimaan dan penempatan email.
Ada dua bentuk utama autentikasi email yang digunakan saat ini—Sender Policy Framework (SPF) dan DomainKeys Identifed Mail (DKIM). Dalam posting blog ini, saya akan menjelaskan apa itu SPF, dan bagaimana cara kerjanya.
Gambaran Umum SPF
Sender Policy Framework (SPF), untuk mengutip RFC 7208, adalah sebuah protokol yang tidak hanya memungkinkan sebuah organisasi untuk mengotorisasi host dan jaringan menggunakan nama domainnya saat mengirim email, tetapi juga menyediakan cara bagi host penerima untuk memeriksa otorisasi tersebut.
Setelah Anda selesai membaca posting ini, saya harap Anda telah mempelajari hal-hal berikut:
SPF adalah sistem otentikasi “berbasis jalur”.
Kebijakan SPF dinyatakan dalam catatan DNS TXT.
Validasi diikatkan ke domain Return-Path (yang di sini di SparkPost kami sebut sebagai “domain bounce”) atau domain HELO.
Validasi dapat dilakukan lebih awal dalam transaksi SMTP, jadi ini adalah pemeriksaan yang baik untuk digunakan guna menolak email yang tidak terautentikasi dengan cepat.
Ini rentan terhadap persentase false negatives yang relatif tinggi.
“Path-Based” Authentication
Mendeklarasikan Kebijakan SPF
Catatan kebijakan SPF dari sebuah domain hanyalah sebuah catatan DNS TXT yang diformat secara spesifik, biasanya berisi satu atau lebih dari “mekanisme” berikut:
v=spf1 – Token pertama yang diperlukan untuk menunjukkan bahwa catatan TXT adalah catatan SPF (suatu domain dapat memiliki beberapa catatan TXT)
ipv4, ipv6 – Digunakan untuk menentukan alamat IP dan jaringan yang diperbolehkan mengirim email untuk domain tersebut
a – Jika domain pengirim memiliki catatan DNS “A” yang mengarah ke IP pengirim, IP tersebut diperbolehkan
mx – Jika IP pengirim juga merupakan salah satu catatan MX untuk domain pengirim, IP tersebut diperbolehkan
all – Token terakhir yang diperlukan, selalu dimodifikasi:
-all – Hanya yang terdaftar di sini yang dapat melewati; tolak kegagalan.
~all – Barang yang tidak ada di sini seharusnya softfail; terima tetapi catat.
?all – Tidak yakin apakah barang yang tidak ada di sini seharusnya lolos.
+all – Kami pikir SPF tidak berguna; loloskan semuanya.
Mekanisme lain yang kurang umum namun masih banyak digunakan adalah:
include – Digunakan ketika sebuah domain tidak hanya memiliki servernya sendiri, tetapi juga menggunakan server milik orang lain. Harus digunakan dengan bijak. Setiap include adalah permintaan DNS lain, dan catatan SPF tidak boleh memerlukan lebih dari sepuluh permintaan DNS untuk diselesaikan.
redirect – Ketika domain A dan domain B dimiliki oleh entitas yang sama dan menggunakan infrastruktur yang sama. Pemilik biasanya ingin memelihara hanya satu salinan catatan SPF untuk keduanya, dan mengonfigurasi B untuk mengarahkan permintaan ke A.
exists – Jika sebuah domain memiliki banyak blok jaringan kecil yang terpisah, mekanisme ini dapat digunakan untuk menentukan catatan SPF, alih-alih mencantumkannya satu per satu. Berguna untuk tetap dalam batas ukuran (512 byte) untuk respons DNS.
Sebuah catatan tentang Mekanisme “ptr”
Sebuah mekanisme terakhir, “ptr” ada dalam spesifikasi asli untuk SPF, tetapi telah dinyatakan “jangan gunakan” dalam spesifikasi saat ini. Mekanisme ptr digunakan untuk menyatakan bahwa jika alamat IP pengirim memiliki catatan DNS PTR yang mengarah ke nama domain yang dimaksud, maka alamat IP tersebut diizinkan mengirim email untuk domain tersebut.
Status saat ini dari mekanisme ini adalah bahwa ia sebaiknya tidak digunakan. Namun, situs yang melakukan validasi SPF harus menerimanya sebagai sah.
Beberapa Contoh SPF Records
Berikut adalah beberapa contoh catatan, dan artinya. Contoh ini menunjukkan alamat RFC 1918, tetapi saya menyadari bahwa alamat tersebut tidak akan pernah muncul dalam catatan SPF yang sebenarnya.
Catatan MX, satu alamat IP, satu jaringan IP, gagal lunak pada yang lainnya:
“v=spf1 mx ipv4:10.0.0.1 ipv4:192.168.24.0/24 ~all”
Catatan A, dua jaringan IP, tolak yang 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 berpikir SPF itu bodoh:
“v=spf1 +all”
Catatan SPF untuk domain sparkpostmail.com (mekanisme pengalihan 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, saat ini kami menggunakan mekanisme ptr dalam catatan SPF kami. Kami telah menemukannya perlu karena kurangnya dukungan universal untuk memvalidasi mekanisme exists. Dan hingga saat ini, kami belum melihat kegagalan SPF akibat penggunaan mekanisme ptr kami.
Bagaimana Cara Kerja Otentikasi SPF?
Ini adalah seperti apa transaksi SMTP tipikal ketika SPF terlibat:
Server pengirim (klien) terhubung ke server penerima
Server penerima mencatat alamat IP klien yang terhubung
Mereka bertukar salam, termasuk nama host HELO klien
Klien mengeluarkan perintah SMTP MAIL FROM
Server penerima sekarang dapat melihat catatan SPF untuk domain MAIL FROM atau nama host HELO untuk menentukan apakah IP yang terhubung berwenang mengirim email untuk domain tersebut, dan memutuskan apakah akan menerima pesan tersebut.
MAIL FROM atau HELO – Mana yang Harus Diperiksa?
Spesifikasi SPF menetapkan 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 untuk saat-saat ketika alamat MAIL FROM adalah pengirim NULL (yaitu, “<>”), dalam hal ini nama host HELO adalah satu-satunya identitas yang tersedia.
SPF Bukanlah Solusi Sempurna
Meskipun tampaknya cara yang relatif sederhana untuk mengotentikasi email, SPF rentan terhadap kegagalan dalam bentuk negatif palsu. Kegagalan ini dapat terjadi lebih sering daripada yang banyak orang merasa nyaman.
Berikut adalah dua skenario umum di mana email yang sepenuhnya sah dapat gagal dalam validasi SPF dan jadi tampak palsu:
Penerusan otomatis, di mana pesan yang dikirim ke jsmith@alumni.university.edu, sebuah kotak surat yang diatur untuk meneruskan semua mail secara otomatis ke jsmith@isp.com
Daftar surat, di mana email yang dikirim ke talk-about-stuff@listserv.foo.com menjadi "terpecah" dan dikirim ke setiap pelanggan
Dalam kedua kasus ini, jika Return-Path tidak berubah dari yang asli, email mungkin gagal dalam pemeriksaan SPF (tergantung pada modifikasi yang digunakan dengan mekanisme ‘all’). Ini karena email tersebut tiba di tujuan akhirnya dari server perantara, bukan server asli, dan server perantara itu tidak mungkin terdaftar di SPF domain. Sebuah teknik yang disebut "Sender Rewriting Scheme" atau “SRS” dapat mengurangi risiko ini, dan beberapa situs yang lebih besar telah mengadopsinya, tetapi ini tidak bersifat universal.
Wrap Up
Jadi begitulah autentikasi SPF, bagaimana cara kerjanya, bagaimana mendeklarasikan kebijakan SPF, dan apa saja jebakan yang ada dalam penggunaan SPF. SPF adalah skema autentikasi email pertama yang mencapai adopsi luas, tetapi itu bukan satu-satunya yang ada di luar sana. Autentikasi SPF paling efektif ketika diterapkan dalam kombinasi dengan teknik anti-penipuan lainnya.
