TLSRPT: Difference between revisions

From InboxSys document library
Jump to navigation Jump to search
← Older edit
No edit summary
No edit summary
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
[[Category:Deliverability]]
[[Category:Deliverability]]
[[Category:Reporting]]
[[Category:Reporting]]
In modern E-Mail communication, [[wikipedia:Opportunistic_TLS|Opportunistic TLS]] is common. This means that [[TLS]] encryption for the transition of E-Mail is negotiated by [[MTA]]s on both ends. If two MTAs can agree on a TLS encryption method and cypher, transit proceeds TLS encrypted. If, however, no agreement can be reached, mail is transferred unencrypted.


[[MTA-STS]] was introduced in [https://tools.ietf.org/html/rfc8461 RFC 8461]. It's main purpose is to assure TLS connections. MTA-STS compliant Mail is returned to the sender if the TLS negotiation fails. RFC 8461 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.
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.
 
TLSRPT is also used to monitor and troubleshoot [[DANE]].


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, DNSSEC, etc.)
* 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

Retrieved from "https://docs.inboxsys.com/index.php?title=TLSRPT&oldid=350"