Keamanan transport SMTP memiliki persoalan observabilitas. Domain penerima dapat memublikasikan kebijakan MTA-STS atau record DANE TLSA, tetapi banyak kegagalan terjadi pada sistem pengirim di luar kendalinya: validasi sertifikat dapat gagal, host MX dapat tidak terjangkau, negosiasi STARTTLS dapat bermasalah, atau kebijakan transport yang dipublikasikan dapat tidak valid. Penerima memerlukan telemetri dari pengirim tersebut untuk membedakan deployment yang berfungsi dari kebijakan yang tanpa terlihat menghambat pengiriman.
SMTP TLS Reporting, yang umum disebut TLS-RPT, menetapkan kanal telemetri tersebut dalam RFC 8460. Domain penerima memublikasikan record DNS TXT yang menyebut satu atau beberapa tujuan laporan. Sistem pengirim yang mendukung mekanisme ini kemudian menghasilkan laporan agregat mengenai sesi TLS yang berhasil memenuhi kebijakan dan kegagalan yang ditemui saat mengirim email ke domain tersebut.
TLS-RPT tidak mewajibkan TLS untuk pengiriman SMTP. Mekanisme ini melaporkan hasil keamanan transport. MTA-STS dan DANE dapat menetapkan atau mengautentikasi persyaratan transport; TLS-RPT menyediakan bukti operasional mengenai sesi yang dihasilkan.
Kebijakan laporan berada di _smtp._tls
Penerima memublikasikan kebijakan TLS-RPT sebagai record TXT di bawah _smtp._tls untuk policy domain. Kebijakan minimal dengan pengiriman melalui email dapat berbentuk:
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tls-reports@example.com"RFC 8460 menetapkan TLSRPTv1 sebagai nilai versi. Direktif rua memuat URI tujuan laporan agregat. Versi 1 mendukung tujuan laporan mailto dan https.
Tujuan HTTPS dapat dipublikasikan seperti berikut:
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=https://reports.example.com/v1/tlsrpt"Record DNS tersebut adalah kebijakan pelaporan, bukan kebijakan transport SMTP. Publikasinya tidak membuat STARTTLS wajib, memilih host MX yang diterima, atau menetapkan aturan identitas sertifikat. Kontrol tersebut berada pada mekanisme seperti MTA-STS atau DANE.
Penanganan record dibuat ketat ketika terdapat ambiguitas. Setelah record yang tidak diawali penanda versi TLS-RPT disisihkan, pengirim yang tidak memperoleh tepat satu record yang berlaku menganggap domain tidak menerapkan TLS-RPT. Aturan ini mencegah beberapa record kebijakan independen tergabung menjadi konfigurasi yang tidak disengaja.
Laporan merangkum keberhasilan dan kegagalan
Laporan TLS-RPT adalah dokumen agregat yang dikodekan sebagai I-JSON. Metadata mencantumkan organisasi pelapor, informasi kontak, pengenal laporan, dan rentang waktu laporan. Bagian kebijakan menjelaskan policy domain serta kebijakan transport yang diterapkan pengirim.
Laporan juga membawa hitungan sesi agregat. total-successful-session-count mencatat sesi yang berhasil membentuk koneksi TLS sesuai kebijakan. total-failure-session-count mencatat sesi yang tidak berhasil membentuk koneksi yang diwajibkan.
Data keberhasilan penting karena laporan yang hanya memuat kegagalan tidak menyediakan baseline pembanding. Aliran sesi yang berhasil berfungsi sebagai heartbeat bahwa jalur pelaporan aktif dan negosiasi TLS SMTP yang sesuai kebijakan memang berlangsung.
Detail kegagalan dapat mengelompokkan kejadian seperti masalah validasi sertifikat, kegagalan negosiasi STARTTLS, kesalahan kebijakan MTA-STS, atau kegagalan validasi terkait DANE. Satu percobaan pengiriman dapat menemui lebih dari satu jenis kegagalan, sehingga hitungan kegagalan tidak selalu saling eksklusif.
Karena itu, TLS-RPT tidak tepat diperlakukan sebagai ledger pengiriman pesan. Unit observasinya adalah perilaku transport pada sesi SMTP dan kebijakan yang diterapkan, lalu dirangkum untuk analisis operasional.
MTA-STS dan DANE tetap menjadi mekanisme enforcement terpisah
RFC 8460 dirancang untuk melaporkan hasil yang berkaitan dengan keamanan transport SMTP, termasuk MTA-STS dan DANE. Pemisahan antara pelaporan dan enforcement penting saat menganalisis insiden.
MTA-STS memungkinkan penerima memublikasikan ketersediaan TLS yang diharapkan, persyaratan identitas sertifikat, dan aturan pencocokan MX melalui mekanisme kebijakannya. DANE untuk SMTP menggunakan data TLSA yang dilindungi DNSSEC untuk mengaitkan informasi autentikasi TLS dengan server email. TLS-RPT dapat melaporkan kegagalan yang berkaitan dengan kedua model tersebut.
Misalnya, sebuah penerima memiliki kebijakan MTA-STS yang valid tetapi memasang sertifikat pengganti dengan identitas yang tidak lagi memenuhi kebijakan itu. Pengirim yang mendukung TLS-RPT dapat mencatat kegagalan validasi dan memasukkannya ke laporan agregat. Record DNS TLS-RPT tidak menyebabkan penolakan; record itu menyediakan tujuan bagi bukti yang dihasilkan evaluasi kebijakan transport.
Pemisahan yang sama berlaku untuk DANE. Validasi TLSA tetap menjadi bagian pemrosesan DANE. TLS-RPT menyediakan format standar bagi pengirim yang kompatibel untuk melaporkan hasil kebijakan DANE.
Kategori kegagalan mempersempit area masalah
Kegagalan transport dapat terlihat serupa dari sisi penerima. Email dapat tertunda atau tidak tiba baik karena resolusi DNS, MX yang tidak tersedia, kapabilitas STARTTLS yang hilang, sertifikat yang tidak dipercaya, maupun kebijakan transport yang tidak valid.
Result type TLS-RPT memberi operator sinyal gangguan yang lebih spesifik. Laporan dapat menunjukkan kegagalan validasi kebijakan dan memuat field seperti hostname MX penerima, alamat IP penerima, serta jumlah sesi gagal. Skema juga mengizinkan informasi tambahan yang terkait dengan hasil kegagalan.
Struktur ini berguna saat perubahan terkontrol dilakukan. Jika operator mengganti host MX, sertifikat, isi kebijakan MTA-STS, atau record DANE, laporan agregat dapat menunjukkan pergeseran dari sesi berhasil menuju kelas kegagalan tertentu. Laporan tidak membuktikan adanya intervensi berbahaya; hasil yang sama dapat muncul akibat kesalahan konfigurasi biasa.
Kualifikasi tersebut penting untuk pemantauan keamanan. RFC 8460 dirancang untuk menampilkan potensi serangan sekaligus kerusakan konfigurasi yang tidak disengaja. Ketidakcocokan sertifikat, misalnya, merupakan bukti kegagalan validasi, bukan bukti tersendiri bahwa penyerang menjadi penyebabnya.
Transport laporan memiliki properti keamanan tersendiri
Laporan TLS-RPT dapat dikirim melalui email atau HTTPS. Kedua jalur memiliki aturan penanganan berbeda.
Untuk pengiriman email, RFC 8460 menetapkan media type TLS-RPT dan mewajibkan laporan yang dikirim melalui SMTP membawa tanda tangan DKIM valid dari reporting domain. Spesifikasi juga mencegah kanal laporan terjebak oleh kegagalan transport yang sedang dilaporkannya: laporan kegagalan yang dikirim melalui SMTP disampaikan tanpa mematuhi kegagalan MTA-STS atau DANE TLSA pada pengiriman laporan tersebut.
Pengecualian itu bersifat sempit. Pengecualian berlaku pada transport laporan agar kebijakan transport penerima yang rusak tidak menekan bukti yang diperlukan untuk mendiagnosis kerusakan.
Untuk pengiriman HTTPS, laporan dikirim dengan HTTP POST ke endpoint yang dikonfigurasi. Laporan dapat berupa JSON biasa atau gzip terkompresi dengan media type yang ditetapkan spesifikasi.
Endpoint laporan adalah batas input. RFC 8460 secara eksplisit membahas risiko termasuk flooding dan konten laporan yang tidak tepercaya. Sistem pemrosesan perlu memperlakukan field laporan sebagai data tidak tepercaya, bukan material yang dapat dieksekusi atau konfigurasi tepercaya.
Telemetri agregat tetap perlu ditafsirkan dengan cermat
TLS-RPT memberi penerima visibilitas yang tidak dapat direkonstruksi hanya dari log server email miliknya. Pengirim di luar domain dapat gagal sebelum mencapai MX tujuan, atau dapat menolak koneksi karena kebijakan transport tidak dapat divalidasi. Laporan membawa sebagian observasi jarak jauh itu kembali ke policy domain.
Namun, cakupan bergantung pada sistem pengirim yang berpartisipasi. Tidak adanya kegagalan yang dilaporkan tidak membuktikan bahwa setiap pengirim berhasil mencapai domain, dan aliran laporan bukan sensus lengkap pengiriman email Internet.
Pemakaian operasional yang paling kuat adalah korelasi. Perubahan DNS, rotasi sertifikat, revisi MTA-STS, pembaruan DANE, dan migrasi MX dapat dibandingkan dengan perubahan kelas keberhasilan serta kegagalan TLS-RPT. Log sisi penerima kemudian dapat menyediakan bagian lokal dari kejadian yang sama.
TLS-RPT mengisi celah khusus dalam arsitektur keamanan SMTP: mekanisme enforcement dapat menolak transport yang tidak aman, sedangkan mekanisme pelaporan membawa bukti terstruktur mengenai keputusan tersebut kembali ke domain yang bertanggung jawab atas kebijakan. Pemisahan itu menjaga telemetri agar tidak berubah menjadi kontrol enforcement lain dan memberi operator sinyal langsung ketika kebijakan email aman tidak lagi cocok dengan infrastruktur yang terpasang.