MTA-STS memungkinkan domain penerima mempublikasikan ekspektasi untuk pengiriman TLS yang diautentikasi. Ini mengalamatkan koneksi SMTP ke layanan penerima. Itu tidak mengautentikasi alamat Dari pembuat pesan atau mengenkripsi pesan dari perangkat satu orang ke perangkat orang lain.
Penerapan yang berfungsi menghubungkan tiga hal: rute MX masuk domain yang sebenarnya, kebijakan HTTPS, dan data DNS yang menandakan kebijakan tersebut. Pelaporan TLS menyediakan jalur umpan balik terpisah.
Tetapkan batas penerimaan yang sebenarnya
Referensi: RFC 8461 §3.4, RFC 8461 §4.
Cantumkan host MX yang menerima email untuk domain tersebut, termasuk layanan pencadangan dan gateway keamanan upstream. Verifikasi TLS dan perilaku sertifikat pada batas penerimaan publik yang sebenarnya, tidak hanya pada server kotak surat internal.
Catat siapa yang memiliki rute MX , hosting kebijakan, perpanjangan sertifikat, dan tujuan pelaporan. Layanan kotak surat yang dihosting tidak selalu menghosting kebijakan MTA-STS pelanggan atau mengoperasikan setiap gateway di depannya.
Nilai subdomain secara terpisah. MTA-STS tidak menggunakan warisan kebijakan induk gaya DMARC. Subdomain penerima memerlukan konfigurasi yang dapat diterapkan pada domain tersebut.
Buat kebijakan untuk host sebenarnya
Referensi: RFC 8461 §3.2, RFC 8461 §3.3.
Sajikan kebijakan dari lokasi HTTPS yang diperlukan untuk domain penerima. example.com , lokasinya adalah https://mta-sts.example.com/.well-known/mta-sts.txt. Layanan HTTPS memerlukan sertifikat yang valid untuk nama host kebijakannya.
Kebijakan ini mengidentifikasi versi, mode, pola MX yang diizinkan, dan masa pakai cache maksimum. Mulailah dengan penerapan pengujian yang sesuai cakupan dan periksa hasilnya sebelum penerapan. Pilih periode pengamatan dari lalu lintas dan ketergantungan sebenarnya daripada memperlakukan durasi sampel sebagai bukti universal.
Ilustrasi kebijakan untuk domain MX tunggal fiktif adalah:
versi: mode STSv1: pengujian mx: mx1.example.net max_age: 86400Contoh ini mengasumsikan mx1.example.net adalah host penerima domain yang sebenarnya dan memiliki dukungan SMTP TLS yang sesuai. Ini bukan kebijakan yang siap pakai untuk penyedia lain. Cocokkan host yang diizinkan dengan tepat dan sertakan setiap rute penerimaan yang sah.
Publikasikan penemuan dan pelaporan secara terpisah
Referensi: RFC 8461 §3.1, RFC 8461 §8.1, RFC 8460 §3.
Di _mta-sts.example.com , nilai ilustratif TXT adalah v=STSv1; id=2026110701. Pengidentifikasi tersebut menandakan adanya revisi kebijakan. Publikasikan dan verifikasi kebijakan sebelum mengiklankan revisi barunya di DNS .
TLS-RPT menggunakan catatannya sendiri di _smtp._tls.example.com . Permintaan ilustratifnya adalah v=TLSRPTv1; rua=mailto:tls-reports@example.com, dengan asumsi alamat tersebut ada dan jalur pengumpulannya berfungsi.
Jangan berasumsi a DMARC rua tujuan secara otomatis menerima laporan TLS , atau pengujian MTA-STS saja membuat permintaan pelaporan yang berfungsi. Verifikasi setiap catatan dengan nama dan tujuan yang benar melalui proses pengumpulannya sendiri.
Uji rantai yang diterapkan
Referensi: RFC 8461 §4, RFC 8461 §6.
Ambil kebijakan secara eksternal dan konfirmasikan bahwa titik akhir HTTPS yang diperlukan melayani isi teks biasa yang dimaksud dengan HTTP 200. Jangan ikuti pengalihan HTTP: pengalihan bukanlah pengambilan kebijakan yang valid berdasarkan RFC 8461 §3.3. Periksa penemuan DNS dan bandingkan semua rute MX yang diiklankan dengan pola yang diizinkan.
Uji SMTP TLS dan validasi sertifikat di setiap rute penerima. Sertifikat web yang berfungsi di mta-sts.example.com tidak menetapkan bahwa server MX menyajikan sertifikat SMTP yang valid.
Tinjau laporan TLS yang tersedia dan bukti pengiriman terkontrol. Pengiriman layanan berbeda-beda dalam partisipasinya, jadi diam tidak menjamin kesuksesan universal. Pertahankan reporter, interval, dan MX yang terpengaruh pada setiap observasi.
Dalam kasus sintetis, kebijakan hanya mengizinkan gateway utama sementara DNS juga mengiklankan MX cadangan. Cadangan menerima email dalam pengujian biasa tetapi gagal dalam pencocokan kebijakan. Perbaiki kebijakan atau desain perutean sebelum penerapan; jangan abaikan cadangan karena volume hariannya kecil.
Rencanakan penegakan dan pemulihan di sekitar cache
Referensi: RFC 8461 §5, RFC 8461 §8.3.
Mode penegakan dapat mencegah pengirim pendukung melakukan pengiriman melalui koneksi yang tidak sesuai. Pengirim yang tidak mendukung berada di luar jaminan itu. Catat ketergantungan dan respons operasional yang dapat diterima sebelum mengubah mode.
Cache pengirim dapat mempertahankan kebijakan sebelumnya yang valid untuk max_age-nya. Menghapus DNS penemuan atau menghapus titik akhir HTTPS bukanlah kemunduran global yang langsung. Untuk penarikan, publikasikan mode yang valid: tidak ada kebijakan dengan masa pakai singkat, lalu perbarui id penemuan. Jaga agar kedua titik akhir tetap tersedia hingga semua kebijakan sebelumnya habis masa berlakunya, termasuk revisi lama dengan masa pakai lebih lama. Hitung setiap masa pakai sejak revisi terakhir kali ditayangkan, bukan hanya dari pengeditan berikutnya.
Untuk migrasi gateway, buat kebijakan kompatibel dengan transisi yang direncanakan, verifikasi rute baru, dan izinkan versi cache. Jaga agar titik akhir kebijakan tetap tersedia sementara pengirim yang relevan mungkin masih mengandalkannya.
Serah terima harus menggabungkan konfigurasi MX , riwayat kebijakan, kepemilikan sertifikat, dan penanganan laporan. MTA-STS tetap berguna ketika bagian-bagian yang bergerak tersebut dipertahankan bersama-sama.