Mechiel, TLSRPT is going to look for its information at _smtp._tls.<rcpt domain>. That same <rcpt domain> should be the policy-domain in the report. The domain for the MTA-STS/DANE policies may be different such as you mentioned with DANE. The MX for foo.com could point at mx.example.net. The TLSRPT will look for policy at _smtp._tls.foo.com, but DANE will look at _25._tcp.mx.example.net.
-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: Uta <uta-boun...@ietf.org> On Behalf Of Mechiel Lukkien > Sent: Tuesday, November 14, 2023 9:39 AM > To: uta@ietf.org > Subject: [Uta] SMTP TLS reporting (RFC 8460), policy domains and DANE > > Hi all, > > I'm implementing (outgoing) SMTP TLS reporting (RFC 8460) in my mail server > (https://urldefense.com/v3/__https://github.com/mjl- > /mox__;!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u > XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1juWS_PVpu$ > ) and am getting confused by TLSRPT's use of "domain"/"recipient > domain"/"policy domain", especially related to DANE. It seems to me these > concepts are getting mixed up. > > Since TLSRPT is a companion document to MTA-STS, targeting MTA-STS has > probably been its focus. MTA-STS specifies a policy for a recipient domain. > But > DANE policies are specified per mail hosts (typically MX target), not > recipient > domains. The terminology section about "policy domain" says: > > o Policy Domain: The domain against which a TLSRPT, an MTA-STS, or a > DANE policy is defined. For TLSRPT and MTA-STS, this is typically > the same as the envelope recipient domain [RFC5321], but when mail > is routed to a "smarthost" gateway by local policy, the > "smarthost" domain name is used instead. For DANE, the Policy > Domain is the "TLSA base domain" of the receiving SMTP server as > described in Section 2.2.3 of RFC 7672 and Section 3 of RFC 6698. > > Consider delivering a message to "user@recipientdomain.example". The > recipient domain is "recipientdomain.example" (with an MTA-STS policy), an > MX target could be "mx.recipientdomain.example" (the TLSA base domain > with a DANE policy). Given the terminology section, I would think this would > find a policy-typ "sts" at policy-domain "recipientdomain.example", and a > policy-type "tlsa" at policy-domain "mx.recipientdomain.example". Since the > terminology section for Policy Domain (above) says TLSRPT is defined against a > policy domain, that means the operator of mx.recipientdomain.example > should create a TLSRPT record at _smtp._tls.mx.recipientdomain.example to > receive DANE-related TLS reports (along with one at > _smtp._tls.recipientdomain.example for sts). That approach seems reasonable > to me, but most of the RFC seems written with the idea that only a recipient > domain would have a TLSRPT record/policy. And that's also how my initial > prototype implemented it, with TLSA results gathered into > a report for the recipient domain. When I thought I was done implementing > (after struggling with merging the various "sts", "tlsa" and "no-policy-found" > results), and reading the RFC again, I found the terminology of "policy > domain" (which feels like the correct approach to me) and changed the > implementation to match its conceptual explanation. I haven't had a per- > mailhost TLSRPT DNS record for long on my mail host, but haven't received a > TLS report for it. I've only received 1 TLSRPT with a "tlsa" policy so far > (along > with the specified "sts" policy), from Microsoft, and it lists my recipient > domain as the tlsa "policy-domain" (not the mx target which has the policy), > so it seems they have an interpretation similar to what I initially had. > > I'm left wondering what the correct and/or intended interpration is for > recipient/policy domain, whether mail hosts should have their own TLSRPT > policy DNS record, and what the expected "policy-domain" values are in TLS > reports. > > Below are some references to specific lines in the RFC related to > policy/recipient domains. The RFC is cross-referenced with the > implementation, sometimes with todo-annotations. Aside: Is there a way to > link to specific lines of an RFC at the datatracker or rfc-editor.org? I > haven't > found it yet. > > Mentioning recipient domains in "Abstract": > https://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L2 > 9__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4uX > VYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1jucfWS7K2$ > > This document > describes a reporting mechanism and format by which sending systems > can share statistics and specific information about potential > failures with recipient domains. > > This says the recipient domain "uses" DANE in "Introduction": > https://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L1 > 93__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u > XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1jubyCcHZ5$ > > Recipient domains may also use the mechanisms defined by MTA-STS > [RFC8461] or DANE [RFC6698] to publish additional encryption and > authentication requirements; > > SMTP TLSRPT describes itself as sending reports to recipient domains, in > "Related Technologies": > https://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L2 > 68__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u > XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1juV85luFC$ > > o SMTP TLSRPT defines a mechanism for sending domains that are > compatible with MTA-STS or DANE to share success and failure > statistics with recipient domains. > > Domain and policy domain in "Reporting policy", not recipient domain: > https://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L2 > 89__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u > XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1juXE1NEK9$ > > A domain publishes a record to its DNS indicating that it wishes to > receive reports. These SMTP TLSRPT policies are distributed via DNS > from the Policy Domain's zone as TXT records [...] > > Talking about recipient domain instead of policy domain in "Reporting policy": > https://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L3 > 78__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u > XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1jueD9M9mL > $ > > If the number of resulting records is not one, senders MUST assume > the recipient domain does not implement TLSRPT. > > The following may be talking about a recipient domain with an MX target equal > to the recipient domain (or no MX record at all), in "Reporting schema": > https://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L4 > 62__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u > XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1juQF7_ebn$ > > Reporters may report multiple > applied policies (for example, an MTA-STS Policy and a DANE TLSA > record for the same domain and MX). Because of this, even in the > case where only a single policy was applied, the "policies" field of > the report body MUST be an array and not a singular value. > > The "policy-domain" field should be the domain the policy is defined against. > I > would say that's the MX target with the TLSA record for DANE. In "JSON > Report Schema": > https://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L7 > 04__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4u > XVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1juVlgzThd$ > > o "domain": The Policy Domain against which the MTA-STS or DANE > policy is defined. > > Some more notes/feedback I wrote down while implementing: > > - Implementors need to carefully handle combinations of sts vs no-sts and tlsa > vs no-tlsa, and possibly combine those into a no-policy-found result. MTA-STS > and DANE aren't mutually exclusive. What about just having policy results "no- > sts" and "no-tlsa"? Seems more explicit to me and is easier to implement. > There can also be cases where only some MX targets of a recipient domain > have a DANE policy. > - Since detecting injected MX targets is one of the goals of MTA-STS, I would > expect a specific result type for when an MX target does not match the policy, > but it seems missing. I think "certificate-host-mismatch" > (https://urldefense.com/v3/__https://www.xmox.nl/xr/dev/rfc/8460.html*L > 541__;Iw!!CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4 > uXVYoL2HXiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1jucKTnjK1$ > ) is about the TLS connection and certificate (a TLS connection will not be > made > when a MX target doesn't match the policy). Similarly, a result type for "none > of the TLSA records match" seem like a relatively likely failure case and > could > have its own result type. > - I think more fields in the failure details should be optional. SMTP IPs > and/or > MX hostnames aren't always in play, e.g. when reporting on MTA-STS policy > fetch/parse or TLSA lookup failures. While the RFC is called "SMTP TLS > reporting", it is also reporting about MTA-STS and DANE policies without TLS > involved yet. > - A "TLS-Required: No" header from the Require TLS RFC can cause a > verification failure to be ignored. I think it's still useful to report > failure details, > but the connection would succeed. How this case should be reported could be > up for discussion. > - I don't submit TLS reports to HTTPS reporting addresses because I don't see > a > way the receiver can authenticate and use them. Report messages must have > a DKIM signature (I'm sending it with d= exact/strict host name, but accept > domains up to the public suffix domain for incoming reports, I think the RFC > requires the exact match). But reports submitted over HTTPS seem to be just > the JSON (optionally with gzip). Submitting a report _message_ over HTTPS, > with DKIM signature, could solve the problem. I think the RFC could be > stricter > with its use of "report" (the JSON document) vs "report message" (email > message with a report as attachment). > > Cheers, > Mechiel > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/uta__;!! > CQl3mcHX2A!D9Xu1BLWleyttI4TKEApW7sBSYzIfWJXnKC9vokcSZ4uXVYoL2H > XiO0qvrZG0g8RwCGcIqNor_UY3c1kfSAv8a2QOOTA9F1juR-QrKQn$ _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
