[pfx] Re: feasibility of REQUIRETLS, *_tls_security_level > may

On Tue, Mar 31, 2026 at 04:12:04PM -0400, Curtis Villamizar wrote:

> > With that necessary disclaimer out of the way, the best stats I'm aware
> > of are from Gmail:
> >  
> >     https://transparencyreport.google.com/safer-email/overview?hl=en
> 
> So fluctuating at 100% or just below.

You can expand the x-axis time range to as far back as ~Jan 2013 to see
the long-term view.

> > See in particular some of the extensions in the two tables at the bottom
> > of the page.
> 
> Not sure what you are referring to.

If on the Gmail transparency page you scroll all the way to the bottom,
you'll find two tables with "Top" senders/recipients that don't/do TLS
(you can choose the type of senders to list).

> I'll check my stats first.  DANE fallback to secure, which I think
> means CA signed would be great if possible to do so.  Even DANE
> fallback to encrypt would be an improvement.

DANE fallback to "secure" (which expects the recipient domain in the MX
host certificate) is not viable for any but a tiny minority of receving
domains.  DANE fallback to "verify" (which is vulnerable to forgery of
the MX records of non-DNSSEC domains) works for a somewhat larger
minority of MX hosts, but is far from practical (many have self-signed
certificates, or ones that don't match the MX hostname, may be from a
CA not in your trust store, may be expired, ...).

The only viable alternative general-purpose DANE policy floor is
"encrypt", rather than "may".  Any other setting would have to be
per-destination (smtp_tls_policy_maps), or used only when all mail is
sent to one (relayhost?) or a small number of servers.

-- 
    Viktor.  🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]