Re: [Uta] SMTP TLS reporting (RFC 8460), policy domains and DANE

[Mechiel Lukkien <[e-mail]>]

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

That sounds reasonable, thanks. I've implemented deduplication of reports based on reporting addresses now. If the reporting addresses in the TLSRPT record for rcptdom and mxhost are the same, only one report is sent (unless they would contains TLS results for other domains as well).


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

Ideally the intention, spirit and letter all match. (: I've kept my approach, but am expecting most implementations to interpret TLSRPT for rcptdom-only. At least until they start implementing DANE...


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

I don't mind success reports at the moment, though if everyone would start sending them it indeed could quickly become too much. Mostly because things will go wrong more often, like incoming reports that aren't properly authenticated, and outgoing reports that result in a DSN message. A tlsrpt record option to only send some success-only reports could help. But I think I recently read DMARCs pct= option wasn't too successful (by not being implemented correctly)... I've now made success-only reports optional, defaulting to sending reports only when there is a failure.


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

Makes sense. As an implementer it would help to learn about situations like this. I typically only look at RFC's and errata, and some articles on the web. If there's a good place to publish notes for implementers (that will be found by implementers) and that doesn't (ab)use the errata reporting, I'm interested in that. 


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

Thanks, will put this on a todo-list. Won't get to it soon.

Cheers,
Mechiel