SMTP umumnya meningkatkan koneksi plaintext dengan STARTTLS. Tanpa kebijakan transport yang terautentikasi, peningkatan tersebut dapat tetap bersifat oportunistik: pengirim dapat melanjutkan pengiriman saat TLS tidak tersedia, bergantung pada konfigurasinya. Perantara aktif yang dapat mengganggu pertukaran SMTP bisa memanfaatkan kelonggaran itu dengan menekan kapabilitas STARTTLS atau mengalihkan pengiriman.
MTA Strict Transport Security (MTA-STS), yang ditetapkan dalam RFC 8461, memberi domain penerima sebuah kebijakan yang dapat disimpan dalam cache dan ditegakkan oleh MTA pengirim yang patuh. Kebijakan tersebut menyatakan host MX yang dapat diterima dan apakah pengiriman memerlukan TLS dengan sertifikat yang lolos validasi PKIX.
Mekanisme ini tidak mengenkripsi email yang tersimpan, mengautentikasi penulis pesan, atau menggantikan kontrol antispam. Cakupannya adalah transport SMTP antara sistem pengirim dan penerima.
DNS memberi sinyal state kebijakan sedangkan HTTPS membawa kebijakan
Domain memberi sinyal MTA-STS dengan record TXT di bawah _mta-sts:
_mta-sts.example.net. TXT "v=STSv1; id=2026092401"Field v mengidentifikasi format record MTA-STS. Field id adalah nilai opaque yang berubah saat kebijakan yang dipublikasikan berubah. MTA pengirim dapat membandingkan nilai itu dengan identifier yang terkait dengan kebijakan dalam cache lalu mengambil kebijakan baru saat diperlukan.
Kebijakan itu sendiri diambil melalui HTTPS dari host dan path tetap:
https://mta-sts.example.net/.well-known/mta-sts.txtRFC 8461 mensyaratkan pengambilan kebijakan melalui HTTPS dengan validasi sertifikat. DNS memberi sinyal keberadaan kebijakan dan perubahan versinya; HTTPS membawa isi kebijakan.
Pemisahan ini memiliki konsekuensi operasional: mengubah hanya record TXT atau hanya dokumen HTTPS dapat membuat pengirim memiliki state cache yang berbeda. Pembaruan kebijakan perlu dikoordinasikan pada kedua permukaan tersebut.
Kebijakan mengikat pengiriman pada host MX yang dinyatakan
Kebijakan minimal dapat berbentuk seperti ini:
version: STSv1
mode: enforce
mx: mail.example.net
max_age: 604800version mengidentifikasi sintaks kebijakan. Setiap field mx memasok pola hostname MX yang dapat diterima. max_age menyatakan, dalam detik, berapa lama pengirim boleh menganggap kebijakan yang diambil masih valid.
Saat kebijakan aktif diterapkan, MX yang dipilih harus cocok dengan setidaknya satu pola mx pada kebijakan. Server SMTP juga harus menawarkan STARTTLS, dan sertifikat TLS yang disajikan server harus memenuhi aturan validasi sertifikat dalam RFC 8461.
Kebijakan tersebut membatasi dua keputusan terpisah: host tujuan dan sesi TLS terautentikasi menuju host itu. Sertifikat valid pada MX di luar kebijakan tidak memenuhi kebijakan, dan MX yang diizinkan tanpa TLS yang dapat diterima juga tidak memenuhinya.
Mode kebijakan memisahkan rollout dari enforcement
MTA-STS menetapkan tiga mode kebijakan:
mode: testing
mode: enforce
mode: noneDalam mode enforce, pengirim yang patuh tidak boleh mengirim ke MX yang gagal dalam validasi kebijakan. Pengirim dapat mencoba kandidat MX lain, tetapi kegagalan kebijakan bukan izin untuk kembali ke sesi plaintext tanpa autentikasi.
testing mempertahankan perilaku pengiriman yang permisif saat validasi MTA-STS gagal. Mode ini ditujukan untuk memunculkan masalah kebijakan sebelum enforcement ketat. Saat SMTP TLS Reporting juga diterapkan, kegagalan dapat dilaporkan melalui mekanisme TLSRPT yang ditetapkan dalam RFC 8460.
none menunjukkan bahwa domain tidak memiliki kebijakan MTA-STS aktif. RFC 8461 juga memakai mode ini dalam prosedur penghapusan agar kebijakan yang tersimpan dalam cache dapat kedaluwarsa secara terkendali sebelum record sinyal dan endpoint kebijakan dihapus.
Rollout dengan demikian dapat bergerak dari observasi menuju enforcement tanpa menjadikan publikasi kebijakan pertama sebagai perubahan yang tidak dapat dibatalkan.
Kebijakan dalam cache menjadi bagian dari batas keamanan
MTA-STS tidak mensyaratkan DNSSEC untuk sinyal TXT-nya. Karena itu, pencarian kebijakan pertama merupakan titik sensitif. Penyerang yang mampu menekan respons _mta-sts pertama dapat membuat domain tampak tidak memiliki kebijakan bagi pengirim yang belum pernah menyimpannya.
Caching mempersempit paparan tersebut setelah pencarian kebijakan berhasil. Setelah pengirim memiliki kebijakan valid, gangguan sementara pada DNS tidak otomatis menghapus persyaratan yang sudah tersimpan. Pengirim dapat terus menerapkan kebijakan sampai masa validitasnya berakhir, mengikuti perilaku pembaruan dan refresh yang ditetapkan spesifikasi.
Sifat ini juga membuat max_age lebih dari sekadar pengaturan praktis. Nilai yang lebih panjang memperpanjang periode saat kebijakan yang sebelumnya terautentikasi dapat bertahan terhadap gangguan pencarian, sekaligus menambah kehati-hatian yang diperlukan ketika kebijakan diubah atau dihentikan.
MTA-STS karena itu tidak setara dengan DANE untuk SMTP. DANE memakai data TLSA yang diautentikasi DNSSEC untuk autentikasi server SMTP. MTA-STS memakai kebijakan yang dikirim melalui HTTPS dan sertifikat PKIX, sedangkan DNS berfungsi untuk pencarian dan sinyal perubahan. RFC 8461 menetapkan bahwa validasi MTA-STS tidak boleh menimpa kegagalan validasi DANE ketika kedua mekanisme digunakan.
Validasi sertifikat terikat pada identitas MX
Pengirim MTA-STS tidak sekadar memeriksa keberadaan sebuah sertifikat. Koneksi TLS harus mengautentikasi identitas server yang dapat diterima untuk MX yang dipilih sesuai aturan validasi kebijakan.
Persyaratan itu mengubah kesalahan lifecycle sertifikat menjadi risiko pengiriman email saat enforce aktif. Sertifikat kedaluwarsa, ketidakcocokan nama, chain yang rusak, atau deployment yang menghapus STARTTLS dapat mencegah pengirim yang patuh mengirim ke MX tersebut.
Respons operasionalnya bukan melemahkan pengirim. Di sisi penerima, renewal sertifikat, konfigurasi MX, dan perubahan kebijakan perlu tetap terkoordinasi. Kebijakan yang menyebut host yang sudah dipensiunkan atau tidak mencantumkan host aktif dapat menyebabkan kelas kegagalan pengiriman yang sama meskipun TLS sendiri dikonfigurasi dengan benar.
TLSRPT menambah visibilitas tanpa mengubah aturan enforcement
SMTP TLS Reporting adalah mekanisme terpisah yang ditetapkan dalam RFC 8460. Domain penerima dapat memublikasikan tujuan pelaporan TLSRPT di bawah _smtp._tls dan menerima informasi agregat mengenai negosiasi TLS yang berhasil serta kategori kegagalan tertentu.
MTA-STS tidak bergantung pada tibanya laporan sebelum kebijakan ditegakkan. TLSRPT adalah observabilitas di sekitar kebijakan transport, bukan kanal otorisasi. Nilai operasionalnya adalah membuat kegagalan sertifikat, MX, pengambilan kebijakan, atau STARTTLS yang berulang menjadi terlihat alih-alih hanya muncul sebagai retry pengiriman di sistem jarak jauh.
Perbedaan itu penting selama mode testing. Laporan dapat memperlihatkan kebijakan yang tidak cocok dengan topologi email yang diterapkan sebelum ketidakcocokan yang sama memblokir pengiriman dalam mode enforce.
Penghapusan perlu menghormati cache pengirim
Menghapus record TXT _mta-sts tidak cukup untuk menarik kebijakan yang sudah tersimpan di tempat lain. Pengirim dapat terus menerapkan kebijakan dalam cache sampai max_age berakhir.
RFC 8461 menjelaskan jalur penghapusan terkendali dengan kebijakan baru yang memakai mode: none dan max_age pendek, disertai id TXT baru agar pengirim dapat mendeteksi perubahan. Endpoint kebijakan lama dan record sinyal baru dihapus setelah kebijakan yang sebelumnya disajikan memiliki waktu untuk kedaluwarsa.
Perilaku cache yang sama yang menahan gangguan sementara juga membuat penghentian mendadak tidak aman. MTA-STS bekerja sebagai state transport yang persisten, bukan petunjuk per koneksi.
Nilai keamanannya berasal dari persistensi tersebut. Setelah pengirim yang patuh memperoleh kebijakan valid, pengiriman SMTP tidak lagi bebas turun diam-diam ketika TLS terautentikasi gagal. Domain penerima telah memublikasikan batas yang bertahan untuk host MX dan autentikasi transport yang dapat diterima, lalu pengirim membawa batas itu ke percobaan pengiriman berikutnya.