FWIW, TLSRPT can be used by any receiving domain, though the utility may be diminished if you're not using DANE/MTA-STS. For example, you may get reports that your cert is expired, even if you haven't declared MTA-STS or DANE. We should sending reports in all cases where the TLSRPT record is valid.
To add to the available software, there are a bunch of projects that will ingest reports. I open sourced a python script a while ago to do that, though it probably needs some TLC. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: mailop <[email protected]> On Behalf Of Andrew C Aitchison > via mailop > Sent: Tuesday, June 23, 2026 2:14 PM > To: [email protected] > Cc: [email protected] > Subject: [EXTERNAL] Re: [mailop] ESPs with bad certificates (was: Re: > [MAILJET] > Anyone else noticing this issue from them?) > > On Tue, 23 Jun 2026, Randolf Richardson, Postmaster via mailop wrote: > > > [Snip] > >> PS, on the subject of ESP's.. what is the deal with so many bad > >> certificates from ESP's.. > > > > I've seen plenty of problems with TLS encryption failures due to > > expired certificates, non-matching SNI / wrong certificates, etc., and > > I suspect a few problems may be a play for many of them... > > > > Automation is usually focused on keeping free certificates (like > > Let's Encrypt's, which has a 90-day cycle) updated on web server > > daemons, but very rarely for other daemons, and so I suspect that it's > > likely an oversight since eMail system configurations tend to require > > less maintenance than web server configurations (which often host > > custom programming). > > > > Also, many mail server daemons will still deliver to SMTP hosts with > > expired certificates, so users often don't notice when there's a > > problem with TLS, unless their eMail client applications report > > certificate problems when receiving or sending eMail ... or users > > don't bother to report anything to their technical support since > > choosing "Accept the Risks" has become a common part of modern > > computing (even some "Cookie usage" notices present as security > > notices, which also contributes to users habitually ignoring warnings > > due to "security risk" notices being commonplace). > > > > Postmasters should be checking regualrly on the state of the TLS > > certificates that their mail systems use, and ensuring renewals occur > > early enough, that the correct TLS versions are supported/dropped as > > the security industry changes, etc., which fits well into the DNS zone > > updates for rolling DKIM keys, DNS traffic encryption, etc. > > RFC8460 defines a mechanism - SMTP TLSRPT - for sending domains that are > compatible with MTA-STS or DANE to share success and failure statistics with > recipient domains, including reports of invalid certificates. > > Do note the issue with me sending an you email to say that I could not send > you > and email ... hence the option of an https POST. > > Whilst very few MTAs currently send reports, there are a pair of projects > under > > https://urldefense.com/v3/__https://github.com/sys4__;!!CQl3mcHX2A! > HtARx-FacXh0Kh5vDl62lgq1QglYx6tIApYGivrU0LSUIzsldHp6ODBRk- > n6Tq7PNeKawndE_ivUxwpWL1w$ > - libtlsrpt and tlsrpt-reporter - which together will allow more MTAs to > generate > TLSRPT messages. > > I believe that libtlsrpt is integrated into Postfix. > I would like to attempt the same for Exim once I get my head around tlsrpt- > reporter. It would help me if it had an Ubuntu package. > > -- > Andrew C. Aitchison Kendal, UK > [email protected] > _______________________________________________ > mailop mailing list > [email protected] > https://urldefense.com/v3/__https://list.mailop.org/listinfo/mailop__;!!CQl3mcH > X2A!HtARx-FacXh0Kh5vDl62lgq1QglYx6tIApYGivrU0LSUIzsldHp6ODBRk- > n6Tq7PNeKawndE_ivUDp3xxsU$ _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
