TLSRPT - Revision history

Sebastian at 20:52, 1 November 2024

2024-11-01T20:52:45Z

← Older revision		Revision as of 22:52, 1 November 2024
Line 5:		Line 5:

	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.		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.

	~~TLSRPT is also used to monitor and troubleshoot DANE.~~

	=Configuring TLSRPT=		=Configuring TLSRPT=

Sebastian at 20:52, 1 November 2024

2024-11-01T20:52:27Z

← Older revision		Revision as of 22:52, 1 November 2024
Line 6:		Line 6:
	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.		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.

	TLSRPT is also used to monitor and troubleshoot [[DANE]].		TLSRPT is also used to monitor and troubleshoot DANE.

	=Configuring TLSRPT=		=Configuring TLSRPT=

Sebastian at 20:52, 1 November 2024

2024-11-01T20:52:10Z

← Older revision		Revision as of 22:52, 1 November 2024
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]]~~. Unfortunately, without a valid MTA-STS policy ("testing", "enforce" or "none"), most reporting organisations don't send reports at all~~.		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.

			TLSRPT is also used to monitor and troubleshoot [[DANE]].

	=Configuring TLSRPT=		=Configuring TLSRPT=

Sebastian at 19:53, 1 November 2024

2024-11-01T19:53:59Z

← Older revision		Revision as of 21:53, 1 November 2024
Line 5:		Line 5:
	[[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.		[[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 also used to monitor and troubleshoot [[DANE]].		TLSRPT is also used to monitor and troubleshoot [[DANE]]. Unfortunately, without a valid MTA-STS policy ("testing", "enforce" or "none"), most reporting organisations don't send reports at all.

	=Configuring TLSRPT=		=Configuring TLSRPT=

Sebastian at 19:42, 1 November 2024

2024-11-01T19:42:10Z

← Older revision		Revision as of 21:42, 1 November 2024
Line 20:		Line 20:
	* 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=

Sebastian at 22:29, 8 October 2024

2024-10-08T22:29:58Z

← Older revision		Revision as of 00:29, 9 October 2024
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.		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.		[[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.

Sebastian at 16:10, 7 October 2024

2024-10-07T16:10:49Z

← Older revision		Revision as of 18:10, 7 October 2024
Line 3:		Line 3:
	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.		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 ~~connnections~~. 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.		[[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 also used to monitor and troubleshoot [[DANE]].		TLSRPT is also used to monitor and troubleshoot [[DANE]].

Sebastian at 16:03, 7 October 2024

2024-10-07T16:03:07Z

← Older revision		Revision as of 18:03, 7 October 2024
Line 3:		Line 3:
	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.		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 connnections. MTA-STS compliant Mail is returned to the sender if the TLS negotiation fails. RFC 8461 states that ~~_MTA~~-STS is intended to be used along with ~~TLSRPT_~~ ([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.		[[MTA-STS]] was introduced in [https://tools.ietf.org/html/rfc8461 RFC 8461]. It's main purpose is to assure TLS connnections. 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 also used to monitor and troubleshoot [[DANE]].		TLSRPT is also used to monitor and troubleshoot [[DANE]].

Sebastian at 16:01, 7 October 2024

2024-10-07T16:01:11Z

← Older revision		Revision as of 18:01, 7 October 2024
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 ~~van~~ be reached, mail is transferred unencrypted.		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 connnections. MTA-STS compliant Mail is returned to the sender if the TLS negotiation fails. RFC 8461 states that _MTA-STS is intended to be used along with TLSRPT_ ([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.		[[MTA-STS]] was introduced in [https://tools.ietf.org/html/rfc8461 RFC 8461]. It's main purpose is to assure TLS connnections. MTA-STS compliant Mail is returned to the sender if the TLS negotiation fails. RFC 8461 states that _MTA-STS is intended to be used along with TLSRPT_ ([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.

Sebastian: 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..."

2024-10-07T16:00:34Z

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..."

New page

[[Category:Deliverability]]
[[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 van 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 connnections. MTA-STS compliant Mail is returned to the sender if the TLS negotiation fails. RFC 8461 states that _MTA-STS is intended to be used along with TLSRPT_ ([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 also used to monitor and troubleshoot [[DANE]].

=Configuring TLSRPT=

TLSRPT is configured with a DNS record on a specific subdomain of your [[Organisational Domain|organisational domain]], which includes the connection protocol. A TLSRPT record for E-Mail connections looks like this:

<pre>
$ host -t txt _smtp._tls.senderdomain.TLD
_smtp._tls.senderdomain.TLD descriptive text "v=TLSRPTv1; rua=mailto:tlsrpt@dmarc.example.com;"
</pre>

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

=TLS reports with InboxSys=

[https://international.eco.de/download/223621/ This document] from [https://international.eco.de/ ECO] explains in detail how to monitor DMARC reports with several open source tools. On request, [https://inboxsys.com/dmarc-monitor/ InboxSys hosts a DMARC monitor] consisting of [https://github.com/domainaware/parsedmarc Parsedmarc], [https://github.com/elastic/elasticsearch Elasticsearch] and a [https://github.com/elastic/kibana Kibana] dashboard. The latest version of our hosted Parsedmarc package contains reporting monitors for [[DMARC]] and TLSRPT.

=Useful links=

* [https://tools.ietf.org/html/rfc8460 RFC 8460]: TLSRPT RFC
* [https://tools.ietf.org/html/rfc8461 RFC 8461]: MTA-STS RFC
* [https://inboxsys.com/dmarc-monitor/ InboxSys DMARC Monitor]
* [[wikipedia:Opportunistic_TLS]]