TLSRPT: Difference between revisions
Created page with "Category:Deliverability Category:Reporting In modern E-Mail communication, Opportunistic TLS is common. This means that TLS encryption for the transition of E-Mail is negotiated by MTAs on both ends. If two MTAs can agree on a TLS encryption method and cypher, transit proceeds TLS encrypted. If, however, no agreement van be reached, mail is transferred unencrypted. MTA-STS was introduced in [https://tools.ietf.org/html/rf..." |
No edit summary |
||
| (8 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
[[Category:Deliverability]] | [[Category:Deliverability]] | ||
[[Category:Reporting]] | [[Category:Reporting]] | ||
TLSRPT is used to send back feedback reports about TLS connections made while sending E-Mail. It's used to gain insight on the implementation of [[MTA-STS]] and or [[DANE]]. In praxis, many reporting organisations require a valid MTA-STS policy ("testing", "enforce" or "none"), before any reports are sent. | |||
MTA-STS was introduced in [https://tools.ietf.org/html/rfc8461 RFC 8461], which states that <q>MTA-STS is intended to be used along with TLSRPT</q> ([https://tools.ietf.org/html/rfc8460 RFC 8460]). It doesn't include the recommendation to send reports, but MTA-STS compliant MTAs should be able to receive and process TLSRPT reports at least. | |||
=Configuring TLSRPT= | =Configuring TLSRPT= | ||
| Line 20: | Line 19: | ||
* Volume / Reporting organisations | * Volume / Reporting organisations | ||
* TLS successes and failures | * TLS successes and failures | ||
* Information about policies used (MTA-STS, TLSA, DANE | * Information about policies used (MTA-STS, TLSA, DANE, etc.) | ||
=TLS reports with InboxSys= | =TLS reports with InboxSys= | ||
Latest revision as of 21:52, 1 November 2024
TLSRPT is used to send back feedback reports about TLS connections made while sending E-Mail. It's used to gain insight on the implementation of MTA-STS and or DANE. In praxis, many reporting organisations require a valid MTA-STS policy ("testing", "enforce" or "none"), before any reports are sent.
MTA-STS was introduced in RFC 8461, which states that MTA-STS is intended to be used along with TLSRPT
(RFC 8460). It doesn't include the recommendation to send reports, but MTA-STS compliant MTAs should be able to receive and process TLSRPT reports at least.
Configuring TLSRPT
TLSRPT is configured with a DNS record on a specific subdomain of your organisational domain, which includes the connection protocol. A TLSRPT record for E-Mail connections looks like this:
$ host -t txt _smtp._tls.senderdomain.TLD _smtp._tls.senderdomain.TLD descriptive text "v=TLSRPTv1; rua=mailto:tlsrpt@dmarc.example.com;"
Reports about successful and failed TLS connections is sent to the address in the rua-switch. TLSRPT reports provide information about:
- Volume / Reporting organisations
- TLS successes and failures
- Information about policies used (MTA-STS, TLSA, DANE, etc.)
TLS reports with InboxSys
This document from ECO explains in detail how to monitor DMARC reports with several open source tools. On request, InboxSys hosts a DMARC monitor consisting of Parsedmarc, Elasticsearch and a Kibana dashboard. The latest version of our hosted Parsedmarc package contains reporting monitors for DMARC and TLSRPT.
Useful links
- RFC 8460: TLSRPT RFC
- RFC 8461: MTA-STS RFC
- InboxSys DMARC Monitor
- wikipedia:Opportunistic_TLS