TLS-RPT pyytää osallistuvia lähetysjärjestelmiä jakamaan kootut SMTP TLS -tulokset. Sen DNS tietue on erillinen MTA-STS löytö ja erillään DMARC raportointi. Kelvollisen tietueen julkaiseminen mahdollistaa raportointipyynnön; se ei mahdollista kuljetusten valvontaa tai takaa, että jokainen lähettäjä tekee ilmoituksen.
Valitse omistama kohde
Viitteet: RFC 8460 §3, RFC 8460 §5.4.
Esimerkiksi example.com , julkaise TXT resurssitietue osoitteessa _smtp._tls.example.com . Pienin kuvaava arvo on v=TLSRPTv1; rua=mailto:tls-reports@example.com. Korvaa esimerkkiosoite postilaatikolla tai noutopalvelulla, jota hallitset ja jonka käyttöön olet valtuutettu. Tarkista toimituskapasiteetti, käsittely, säilytys ja kuka voi käyttää tuloksena olevia raportteja.
RFC 8460 tukee mailto- ja https-raporttien URI-tunnisteita. HTTPS-raportointi käyttää POST-testiä MTA-STS -käytännön hakemiseen käytettyä GET:tä sijaan. TLS-RPT kohde ei ole käytäntöpalvelimen URL-osoite. Käytä kerääjän todellista tuettua päätepistettä ja valtuutusprosessia sen sijaan, että lähetät raportteja yleiselle verkkosivustolle tai mielivaltaiseen toimittajan osoitteeseen.
Julkaise yksi soveltuva tietue
Viitteet: RFC 8460 §3.
Versiokentän ensimmäisenä on oltava tarkka TLSRPTv1-arvo, ja rua vaaditaan. Useat kohteet ovat pilkuilla erotettuja URI-arvoja samassa tietueessa. Merkit, joilla on erottimen merkitys URI:n sisällä, tarvitsevat asianmukaisen koodauksen. Raportoiva lähettäjä voi yrittää vain yhtä useista päätepisteistä; Älä oleta, että samat kopiot saapuvat kaikkialle.
Jos useita TXT tietueita palautetaan, tietueet eivät ala v=TLSRPTv1; hylätään. TLS-RPT etsintää varten on säilytettävä täsmälleen yksi soveltuva tietue. Useita merkkijonoja yhdessä TXT tietueessa ketjutetaan ilman välilyöntejä. Kaksi itsenäistä TLS-RPT käytäntöä eivät sulaudu yhdeksi kohdeluetteloksi.
Toista tietueen rajan tarkistus
Luo laboratoriovastaus yhdellä v=TLSRPTv1; rua=mailto:tls-reports@example.com ja asiaankuulumaton vahvistus TXT arvo. Suunniteltu valinta jättää yhden ehdokkaan. Lisää toinen itsenäinen TLSRPTv1-tietue, niin etsintämäärä ei kelpaa. Mukana toimitettu offline-laitteisto suoritettiin uudelleen tätä tarkistusta varten ja se suorittaa tämän suppean ehdokasvalintatapauksen; se ei ole täydellinen URI-validaattori, DNS palvelin tai raportointiasiakas.
Kun kyseessä on todellinen verkkotunnus, kysy absoluuttista omistajaa _smtp._tls.YOURDOMAIN. TXT -tyypin kanssa suoraan jokaiselta auktoriteetilta ja rekursiivisen ratkaisijan kautta. Säilytä TTL:t, täydelliset tietueet ja mahdolliset aliakset. Tarkista sitten keräin erikseen käyttämällä sen dokumentoitua testityönkulkua. Tämä artikkeli ei sisällä reaaliaikaista DNS julkaisua, raportin lähetystä tai vahvistettua raportin vastaanottoa.
Tarkista saapuvat raportit ennen kuin luotat niihin
Viitteet: RFC 8460 §3, RFC 8460 §7.
RFC 8460 edellyttää SMTP :n toimittamia raportteja DKIM -allekirjoitus raportointialueen ja kieltää DKIM l= body-length limitation. Reports lacking the required valid signature must be ignored. The DKIM key should declare the tlsrpt service type; the specification permits a collector to ignore reports lacking that declaration.
Käytä jäsentimen kokorajoituksia ja säilytä raportoijan identiteetti ja raportointijakso. Vältä tulkitsemasta hiljaisuutta terveeksi kuljetukseksi: liikenteen määrä, lähettäjien tuki, aikataulujen ilmoittaminen ja keräilijän viat voivat kaikki vaikuttaa saapumiseen. Korreloi vastaanotetut kuljetusraportit nimettyyn käytäntöön ja SMTP -reittiin sen sijaan, että käsittelet niitä sellaisina SPF, DKIM tai DMARC -tulokset tavallisille viesteille.
Säilytetty historiallinen todiste ja jäljellä oleva laajuus
Seuraavassa kuvataan säilytettyjä 7.11.2026 havaintoja, ei tämän katsauksen verkkokokeilua. Äskettäin suoritetut offline-tarkastukset kirjataan erikseen.
Säilytetty historiallinen paketti sisältää synteettisen TLS-RPT JSON -raportin, joka on linkitetty varsinaiseen SMTP isäntänimen virheeseen. Sen käytäntöalue on example.test, sen MX on mx.old.example .test, sen tulostyyppi on sertifikaatti-isäntä-mismatch ja sen epäonnistuneiden istuntojen määrä on 1. Raportin jakso sulkee laboratorioajon, ja sen yhteenveto sisältää yhden epäonnistuneen ja nolla onnistunutta istuntoa valitulle skenaariolle. Vastaavat SMTP tapahtumatietueet valid=false ja isäntänimen vahvistusvirhe. Tämä raportti luotiin paikallisesti havaitusta tapahtumasta, sitä ei ole saatu riippumattomalta lähettäjältä eikä DKIM todennettu. Muokkausta ei tarvittu, koska kaikki nimet ja osoitteet ovat vain laboratoriotietoja. Valinnainen lisätietokenttä on jätetty pois; RFC 8460 määrittelee arvonsa URI:ksi, joten selittävä alkuperä säilytetään raportin ulkopuolella sen sijaan, että se sijoitettaisiin kyseiseen kenttään. Se esittelee raportista ongelmaan -kartoituksen, kun taas varsinainen DNS julkaisu, keräilijän kuitti, allekirjoituksen validointi ja kaikki tuotantokohtaiset todisteet pysyvät erillään tästä opetusesimerkistä.