<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>TLS-RPT on Nalar</title>
    <link>https://nalar.dev/id/tags/tls-rpt/</link>
    <description>Recent content in TLS-RPT on Nalar</description>
    <generator>Hugo</generator>
    <language>id-id</language>
    <lastBuildDate>Wed, 23 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://nalar.dev/id/tags/tls-rpt/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>TLS-RPT Menampilkan Kegagalan TLS SMTP sebagai Laporan Agregat</title>
      <link>https://nalar.dev/id/tls-rpt-menampilkan-kegagalan-tls-smtp-sebagai-laporan-agregat/</link>
      <pubDate>Wed, 23 Sep 2026 00:00:00 +0000</pubDate>
      <guid>https://nalar.dev/id/tls-rpt-menampilkan-kegagalan-tls-smtp-sebagai-laporan-agregat/</guid>
      <description>&lt;p&gt;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.&lt;/p&gt;&#xA;&lt;p&gt;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.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
