Re: [Uta] SMTP TLS reporting (RFC 8460), policy domains and DANE
On Fri, Nov 17, 2023 at 09:11:40PM +0100, Mechiel Lukkien wrote: > Alex wrote: > > TLSRPT is going to look for its information at _smtp._tls. > domain>. That same 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. Since DANE policy is managed by the email provider, and not the hosted domain, one should expect to find any TLSRPT endpoints listed for the MX hostname(s), with the MX operator being the primary responsible party for monitoring for an resolving any issues. If the (MX) hosted customer domain operator is also interested in receiving TLSRPT messages, they could I guess also publish a suitable TXT record, and you might then notify either or both the customer and the service provided, deduplicating reporting endpoints, since some self-hosted sites may list the same endpoints for both. > If the goal is to always evaluate that to "recipient domain", there > would be no need for the indirection through "Policy Domain". As a > reader, that makes me think an author is using the indirection to make > it variable based on the DANE or MTA-STS context. Go with the spirit, rather than the letter of the RFC. The goal is to provide information to operators about observed failures, where "operators" means primarily those in a position to respond to any issue. Doing TLSRPT with MTA-STS when email is hosted by a provider in practice requires each customer domain to proxy or delegate the "mta-sts." HTTPS service to the provider's service endpoint and to CNAME the TXT record to the provider's TLSRPT TXT record. With DANE, both problems go away. > I do also see how it would be useful for recipient domain owners to > receive TLS reports about success/failures of TLS connections to (3rd > party) MX operators for their domains, regardless of TLSRPT policy > presence for the MX target. Notify both (after endpoint deduplication) when both are published. > Viktor wrote: > > Just failure reports? Or also success reports in the absence of any > > failures? > > I'm also sending success reports, and have been receiving them. The > RFC mentions this as a useful way to send a "heartbeat" signal that > all is well. The reports I'm getting are almost all about successful > connections, which indeed is good to know. I would prefer to not receive success report noise. IIRC the TLSRPT DNS record does not have a field to indicate that success reports are not desired. Software implementing TLSRPT should IMHO default to not sending success reports, and have that be a feature that the (sending) MTA operator has to turn on explicitly. Ideally, it should also allow receiving domains to ask to opt-out of success reports, and so the software should also support exclusion lists for this case. > > Whoever manages the policy should receive the reports. If DANE MTA > > operators want to receive TLSRPT data, indeed they should publish > > the relevant records for each of the MX hosts. > > But if I'm understanding Alex correctly, he wouldn't expect this. Do the *right* thing, regardless of what Alex, I, or the RFC might say, defaulting to following the RFC when it is close-enough to the right thing, but RFCs are not always clear and not always in hindsight correct, so deviations or elaborations are sometimes necessary. There is no RFC police. > More DANE TLSRPT implementations would be nice. I've been receiving > TLS reports mostly from just a few providers. I think/thought it is > because implementations aren't too common. But other implementations > may indeed only be reporting failures. Are there known implementations > with failure-only TLS reporting? I am not following the space closely enough (or at all) to give you a useful answer. > > The set of defined error conditions is not necessarily exhaustive, > > if, while implementing, you think of compelling additions, propose > > additional entires for the IANA registry. > > What would the procedure be? A new RFC? I'm assuming I cannot just > submit new values... Some IANA registries are subject to expert review, and don't require "standards action". You when need just an informational RFC through the ISE, so that others can find a stable reference for the code point. Check the registry policy. Of course if you want the new code point to see wide use, a short standards-action RFC through the UTA or other suitable WG may be best. > I would think it's better to overreport the failure, than underreport > it. There's already too much email. More junk is not helpful. And automated email sometimes results in mail delivery loops, reports about reports, ... So I rather differ with you on "overreporting". When there's a problem, hearing about it once is good, hearing about it from everyone is at least distracting. >
Re: [Uta] SMTP TLS reporting (RFC 8460), policy domains and DANE
On Tue, Nov 14, 2023 at 03:39:21PM +0100, Mechiel Lukkien wrote: > I'm implementing (outgoing) SMTP TLS reporting (RFC 8460) in my mail > server (https://github.com/mjl-/mox) 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. Just failure reports? Or also success reports in the absence of any failures? >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. This is clear to me, the *policy* domain is the one that vends the policy data, and that (in the form of TLSA records) is the TLSA "base domain" (TLSA query name, less the "_port._protocol" attleaf labels). > 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. Whoever manages the policy should receive the reports. If DANE MTA operators want to receive TLSRPT data, indeed they should publish the relevant records for each of the MX hosts. It is also possible for the recipient domain to configure "_smtp._tls" TXT records, and if there's no reporting address for the affected MX host, it is reasonable to fall back to the recipient domain as a potential report destination. So nobody will fault you for considering both. > 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. DANE TLSRPT support for Postfix is under development at sys4.de I hear, so some day you might see a report, but perhaps only if there's something broken on your end. If your domain is workign normally, I would not expect success reports. > 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. Or the sending MTA is not DANE enabled, or the implementation of TLSRPT is presently only targetted at MTA-STS. > 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. An operator of a multi-tenant MTA who publishes DANE TLSA records, and is interested in external reports of delivery issues to augment their own (naturally comprehensive and robust) monitoring should publish per MX host TXT records. Since this is not a task that should fall on each hosted recipient domain. A recipient domain that manages its own MX hosts, or wants to hear about delivery issues via their provider, might also publish a TLSRPT DNS record. A report sender might notify both if both are published and specify different notification endpoints. > - There can also be cases where only some MX targets of a recipient > domain have a DANE policy. Sure, and reports would go to the relevant operator when there's a problem. > - 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. The set of defined error conditions is not necessarily exhaustive, if, while implementing, you think of compelling additions, propose additional entires for the IANA registry. > - A "TLS-Required: No" header from the Require TLS RFC can cause a > verification failure to be ignored. And even the policy to not be queried or evaluated, so the "failure" might not even be observed, and would only have been a "failure" without the override. > I think it's still useful to report failure details, but the > connection would succeed. Perhaps, if the "failure" is observed, but ignored, though if mail delivery is successful, I'd be inclined to not report a problem. Let the deliveries that actually enforce the policy provide the signal. If there are none, then in some sense there's no immediate problem. Of course not all the senders that are failing will have TLSRPT support, and perhaps only the bleeding edge server that also supports REQUIRETLS is capable of TLSRPT as well, so the argument could go either way. On Thu, Nov 16, 2023 at 01:59:16PM +, Brotman, Alex wrote: > 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. Small correction, the TLS policy domain is
Re: [Uta] SMTP TLS reporting (RFC 8460), policy domains and DANE
Mechiel, TLSRPT is going to look for its information at _smtp._tls.. That same 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 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 >
