MTA-STS Mewajibkan TLS Terautentikasi untuk Pengiriman SMTP

SMTP STARTTLS dapat mengenkripsi transport email, tetapi TLS oportunistik biasa mengizinkan pengiriman berlanjut saat enkripsi tidak tersedia. Perilaku kompatibilitas tersebut membuka ruang bagi perantara aktif untuk menekan STARTTLS atau mengalihkan pengiriman menuju server yang tidak semestinya.

SMTP MTA Strict Transport Security, yang ditetapkan dalam RFC 8461, memberi domain penerima kanal kebijakan untuk MTA pengirim yang kompatibel. Kebijakan itu menetapkan host MX yang dapat diterima dan apakah pengiriman harus memakai TLS dengan sertifikat PKIX yang valid. Dalam mode enforce, pengirim tidak melakukan downgrade secara diam-diam ketika pemeriksaan tersebut gagal.

Penemuan kebijakan membagi peran antara DNS dan HTTPS

Deployment MTA-STS memiliki indikator DNS dan dokumen kebijakan HTTPS. Untuk example.com, record DNS diterbitkan pada:

_mta-sts.example.com. IN TXT "v=STSv1; id=20260923a;"

Nilai id menandai revisi kebijakan. Pengirim yang melihat nilai berbeda dapat mengambil kebijakan terkini dari lokasi HTTPS tetap:

https://mta-sts.example.com/.well-known/mta-sts.txt

Host kebijakan harus menyajikan sertifikat yang valid untuk nama DNS mta-sts miliknya dan berantai ke CA yang dipercaya MTA pengirim. DNS mengumumkan keberadaan dan revisi kebijakan; HTTPS membawa isi kebijakan serta mengautentikasi host kebijakan melalui PKIX.

Pemisahan ini penting karena record TXT bukan kebijakan transport lengkap. Identifier revisinya berfungsi sebagai sinyal cache, bukan nomor versi berurutan dan bukan pengganti dokumen HTTPS.

Kebijakan membatasi tujuan SMTP yang dapat diterima

Sebuah kebijakan memuat versi, mode, satu atau beberapa entri mx, serta nilai max_age. Kebijakan ringkas dapat berbentuk seperti berikut:

version: STSv1
mode: enforce
mx: mail.example.com
mx: *.mail.example.net
max_age: 604800

Entri mx menetapkan pola host yang dapat menerima email di bawah kebijakan tersebut. Wildcard dibatasi pada label paling kiri secara utuh. Karena itu, *.mail.example.net dapat cocok dengan a.mail.example.net, tetapi tidak cocok dengan mail.example.net atau a.b.mail.example.net.

Agar kandidat MX lolos validasi kebijakan, nama host-nya harus cocok dengan pola yang diizinkan, server harus mendukung STARTTLS, dan sertifikat yang disajikan selama TLS handshake harus valid untuk host MX tersebut menurut pemeriksaan PKIX yang diwajibkan spesifikasi.

Sertifikat yang hanya valid untuk host kebijakan tidak memberikan otorisasi kepada MX SMTP. Pengambilan kebijakan dan pengiriman SMTP merupakan koneksi TLS berbeda dengan identitas host yang berbeda pula.

Mode enforce mengubah kegagalan transport menjadi penundaan pengiriman

Mode kebijakan mengatur perilaku pengirim setelah validasi gagal. Dalam mode enforce, pengirim yang kompatibel tidak boleh mengirim ke MX yang gagal memenuhi pemeriksaan host, STARTTLS, atau sertifikat. Pengirim dapat mencoba kandidat MX lain yang memenuhi kebijakan.

Jika pengiriman tetap tidak dapat berjalan, kegagalan diperlakukan sebagai kondisi sementara, bukan langsung mengubah masalah keamanan transport menjadi pengiriman plaintext. Sebelum menyatakan pesan gagal secara permanen, pengirim memeriksa DNS untuk revisi kebijakan agar perbaikan kebijakan dapat berlaku.

Mode testing berbeda. Mode ini mengizinkan pengiriman seolah kegagalan validasi MTA-STS tidak memblokir pesan, sedangkan implementasi yang juga mendukung TLS Reporting dapat melaporkan kegagalan kebijakan. Mode none menyatakan domain tidak memiliki kebijakan MTA-STS aktif dan juga menjadi bagian dari prosedur penghapusan kebijakan yang ditetapkan spesifikasi.

Ketiga mode tersebut membuat status deployment menjadi eksplisit. Beralih langsung ke enforce tanpa memverifikasi seluruh MX produksi, rantai sertifikat, dan jalur routing dapat mengubah kesalahan kebijakan menjadi email yang tertunda.

Kebijakan dalam cache mempertahankan state keamanan saat DNS terganggu

Pengirim dapat menyimpan kebijakan yang berhasil diambil selama max_age. Jika penemuan langsung kemudian gagal tetapi masih ada kebijakan cache yang valid dan belum kedaluwarsa, RFC 8461 mewajibkan pengirim tetap menerapkan kebijakan cache tersebut.

Cache itu merupakan bagian dari ketahanan terhadap downgrade. Penyerang yang mampu memblokir respons DNS tanpa autentikasi dapat menekan indikator TXT saat penemuan pertama. Setelah pengirim memiliki kebijakan cache yang valid, menekan respons TXT berikutnya tidak langsung menghapus state kebijakan.

Proteksi ini memiliki batas: kontak pertama masih dapat terkena gangguan sebelum kebijakan diperoleh. MTA-STS tidak mengautentikasi DNS dengan DNSSEC dan tidak menyatakan bahwa risiko penemuan awal tersebut hilang. Spesifikasi menyarankan refresh kebijakan cache sebelum kedaluwarsa agar gangguan singkat di sekitar batas expiry tidak mudah menghapus state kebijakan yang sudah terbentuk.

Secara operasional, max_age memengaruhi latensi perubahan sekaligus persistensi. Nilai panjang mempertahankan kebijakan yang sudah terbentuk selama kegagalan penemuan yang lebih lama, sedangkan perubahan kebijakan perlu ditangani hati-hati karena pengirim dapat secara sah mempertahankan state cache lama sampai masa berlakunya selesai.

Penghapusan kebijakan harus memperhitungkan cache yang masih aktif

Menghapus record TXT dan endpoint HTTPS tidak langsung menghapus kebijakan MTA-STS dari pengirim yang sudah menyimpannya. Pengirim tersebut dapat terus menerapkan dokumen cache sampai max_age berakhir.

RFC 8461 menetapkan mode: none untuk penarikan terkendali. Domain dapat menerbitkan kebijakan none baru dengan masa berlaku pendek, memperbarui id TXT agar pengirim mengambilnya, lalu menunggu seluruh kebijakan lama kedaluwarsa sebelum menghapus record penemuan dan endpoint kebijakan.

Urutan ini mencegah persistensi cache diperlakukan sebagai efek samping implementasi. Kebijakan cache adalah state protokol yang memang diharapkan, sehingga prosedur deployment dan rollback perlu memasukkannya dalam perencanaan.

MTA-STS dan DANE memakai fondasi autentikasi berbeda

MTA-STS dan DANE untuk SMTP menangani risiko downgrade dan autentikasi tujuan yang berkaitan, tetapi model kepercayaannya berbeda. DANE memakai record TLSA yang diautentikasi DNSSEC. MTA-STS memakai kebijakan HTTPS yang diautentikasi melalui ekosistem PKIX publik dan tidak mewajibkan DNSSEC.

Kedua mekanisme tersebut tidak dapat dipertukarkan. RFC 8461 secara eksplisit menyatakan validasi MTA-STS tidak boleh menimpa validasi DANE yang gagal ketika keduanya digunakan. Deployment yang mendukung keduanya harus mempertahankan semantik kegagalan yang lebih ketat sesuai state DANE yang berlaku, bukan memakai MTA-STS sebagai fallback untuk melewatinya.

MTA-STS karena itu lebih tepat diperlakukan sebagai kebijakan transport persisten, bukan sekadar sakelar yang menyatakan TLS tersedia. Efek keamanannya berasal dari kombinasi kebijakan HTTPS terautentikasi, identitas MX yang dibatasi, validasi sertifikat, cache di sisi pengirim, dan penolakan downgrade pengiriman selama kebijakan enforce yang valid masih berlaku.