Erottele raporttien vastaanottamispyyntö kuljetusturvasta
TLS-RPT pyytää lähettäviä järjestelmiä raportoimaan SMTP TLS -havainnoista. Se ei itsessään vaadi salattua toimitusta tai korjausta MTA-STS tai DANE kokoonpano. Tarkistajan tulee ensin selittää, onko raportointipyyntö löydettävissä ja jäsennettävä, ja sitten erikseen selvitettävä, voiko kohde hyväksyä raportteja ja mitä vastaanotettu raportti itse asiassa määrittää.
Tämä artikkeli on ehdotettu tarkistusopas, ei toteutettu EmailAuth ominaisuus. Toimialuetta, postilaatikkoa, raportin päätepistettä tai viestiä ei testattu. Tarkka työvälinevaatimus on auki: Toteuta ja testaa luvattu toiminto. Pelkästään artikkeli, malli tai eritelmä ei ole työväline.
Vahvista löytötietue oikealla omistajalla
Käytäntötoimialueen osalta RFC 8460 sijoittaa pyynnön osoitteeseen _smtp._tls , jota seuraa tämä toimialue. Pidä kysytty omistaja, TXT tietue rajat, vastauksen tila ja keräysaika. Ehdotetun tarkistajan tulee erottaa epäonnistunut nouto vahvistetusta poissaolosta. Kun palautetut tietueet suodatetaan tuetulle TLSRPT-versiolle, on jätettävä täsmälleen yksi käyttökelpoinen tietue. useita merkkijonoja yhden tietueen sisällä ketjutetaan ilman välilyöntejä.
Jäsennä vaaditut v=TLSRPTv1 ja rua-tiedot spesifikaatioiden mukaisesti, mukaan lukien sen URI-pakosäännöt. RFC 8460 tukee mailto- ja https-raporttikohteita. Älä liitä DMARC-spesifistä ulkoisen kohteen valtuutussyntaksia TLS-RPT :hen vain siksi, että molemmat protokollat käyttävät rua-kenttää. Vahvista todellinen protokolla ja päätepistesopimus. RFC 8460 , jakso 3.
Erota päätepisteen syntaksi toiminnallisesta hyväksynnästä
Syntaktisesti kelvollinen osoite ei todista, että postilaatikko on olemassa, että se hyväksyy raportin koon tai että se käyttää yhteensopivaa prosessoria. Samoin verkkosivua palveleva HTTPS-kohde ei todista hyväksyvänsä määritettyä POST-raporttia. Kirjaa päätepisteen omistaja, tuettu kuljetus, tuontimuoto ja erikseen hyväksytty hyväksymistodistus. Älä lähetä testiraporttia tai paljasta asiakasmateriaalia vain muuttaaksesi tilailmaisimen vihreäksi.
Raportin toimituksella on erityinen kuljetussemantiikka. RFC 8460 sallii HTTPS-lähettäjien jättää huomiotta varmenteen vahvistusvirheet ja edellyttää SMTP -raportoinnin jatkamista TLS:ään liittyvistä virheistä huolimatta, mahdollisesti ilman salausta. Nämä protokollat eivät anna tälle tarkistelle oikeutta ohittaa varmennevaroituksia tai siirtää arkaluontoisia tietoja epäturvallisesti. Käyttöönoton on nimenomaisesti tarkasteltava luottamuksellisuuden seurauksia ja oma suojauskäytäntönsä ennen kohteen valitsemista tai testaamista.
Noudata SMTP -raportoinnin allekirjoitusvaatimuksia tarkasti
SMTP :n kuljettamissa raporteissa on oltava kelvollinen DKIM -allekirjoitus raportointialueelta; vastaanottajan on jätettävä huomioimatta raportit, joista se puuttuu. RFC 8460 n § 3 kieltää myös DKIM l= body-length attribute for these signatures. A generic DKIM pass is insufficient if the reporting signature relies on l=, because the requirement protects against appended misleading report content.
Julkisen avaimen tietueen tulee ilmoittaa tlsrpt-palvelutyyppi, ja vastaanottaja voi jättää raportin huomioimatta, jos ilmoitus puuttuu. Säilytä mikä allekirjoitusverkkotunnus, valitsin ja allekirjoitus tukevat raportin hyväksymispäätöstä. Näitä SMTP-kohtaisia vaatimuksia ei saa kuvata HTTPS POST:n DKIM-allekirjoitusvaatimuksena. RFC 8460 , jakso 3.
Jäsennä raportti tarkat tuontirajoitukset
TLS-RPT -raportit käyttävät I-JSON-tiedostoa, metadataa, raportointiväliä ja käytäntötaulukkoa. Sähköpostin siirto käyttää määrättyä raportin MIME rakennetta; gzip-pakkaus on tuettu ja spesifikaatio suosittelee. Käsittele sekä pakattua että tavallista syöttöä epäluotettavana. Sidotut saapuvat ja laajennetut koon, käsittelyajan, muistin, sisäkkäisyyden ja käytäntöjen tai virheiden syöttömäärät ennen tietueiden tuontia analyysiin.
Käytä I-JSON-tietoista vahvistuspolkua, mukaan lukien päällekkäisten objektien jäsennimien hylkääminen, sen sijaan, että luottaisit siihen arvoon, jonka salliva JSON-kirjasto säilyttää. Säilytä raakasyötteen alkuperä ja jäsennysversio ja aseta karanteeniin tukemattomat tai väärin muotoillut raportit merkitsemättä niitä toimialueen siirtovirheiksi. Tässä ei ole otettu käyttöön tuontirajoituksia tai jäsentäjää. RFC 8460 , osat 4–5, RFC 7493 ja OWASP-tiedoston latausohjeet.
Tulkitse havainto ja sen nimittäjä
Linkitä jokainen havainto raportoivaan organisaatioon, käytäntöalueeseen, käytäntötyyppiin, aikaväliin, vastaanottavaan isäntään ja asiaankuuluviin virhetietoihin. sts-policy-fetch-error koskee MTA-STS -käytännön hakemista; sertifikaatin ja isännän välinen epäsuhta koskee varmenteen identiteetin vahvistamista. Kumpikaan tarra ei yksin tunnista tarkkaa korjausta. Korreloi raportin aika ja konteksti erikseen valtuutetun päätepisteen, politiikan tai MX todisteen kanssa ennen muutoksen valitsemista.
Laskurit kuvaavat istuntoja, eivät välttämättä yksittäisiä viestejä. Epäonnistumisluokat voivat mennä päällekkäin samalla yrityksellä, ja raportti voi sisältää useita käytettyjä käytäntöjä. Jokaisen virheen yksityiskohtien määrän lisääminen yksilölliseen viestien kokonaismäärään voi siksi liioitella ongelman aiheuttamaa populaatiota. Säilytä tiivistelmä ja yksityiskohtainen semantiikka sen sijaan, että litistät ne yhdeksi yleiseksi epäonnistumissuhteeksi. RFC 8460 , kohdat 4.2–4.3.
Poissa oleva raportti ei osoita, että kuljetus olisi onnistunut. Lähettäjä ei ehkä osallistu, raportointipolku voi epäonnistua tai paikallinen prosessori voi hylätä syötteen. Sitä vastoin onnistunut istuntojen määrä osoittaa käytäntöjen mukaisen TLS yhteyden raportointijärjestelmän havainnointia varten, ei lopullista postilaatikon toimitusta tai viestien todennusta. Säilytä keräilyn terveys- ja kuljetushavainnot erillisissä tuloskentissä.
Vaadi osoitettu ongelma ennen korjauksen vaatimista
Kuvitteellisessa diagnostiikkasuunnitelmassa toistuvat käytäntöjen noutovirheet saisivat omistajan vertaamaan raportoitua aikaväliä käytäntöisännän saatavuuteen ja varmenteen todisteisiin. Työkalun tulee säilyttää vaihtoehtoiset selitykset, kunnes syy on vahvistettu. Se ei saa automaattisesti korvata raportointikohdetta, heikentää täytäntöönpanoa tai julkaista uutta käytäntöä.
Tarkka alkuperäisen todisteen portti on: Muokattu TLS-RPT JSON-esimerkki, joka on linkitetty vahvistettuun päätepisteeseen tai käytäntöongelmaan. Varsinaista raporttia tai vahvistettua tapahtumaa ei ole toimitettu. Referenssit tarkistettiin 8.11.2026. Ehdotettu työnkulku vaatii vielä testatun toteutuksen, suojattujen tuontikiinnikkeiden, riippumattoman ja inhimillisen teknisen tarkastuksen, visuaaliset tarkastukset ja omistajan julkaisuluvan.