[mjl-]

Most SMTP traffic is encrypted nowadays, at least "opportunistically", without verification.

Only with MTA-STS enabled for the server will an SMTP client (that's delivering to an SMTP server) verify the TLS certificate against PKI (with DANE, it's verified against "self-signed" or CA certs in DNS). (I'm the developer of a mail server that sets up TLS for SMTP with MTA-STS and DANE using Let's Encrypt certificates by default).

I have never heard of any SMTP server doing TLS client certificate authentication. I'm pretty sure there's no standard for that, so it can't be a requirement for all incoming email. It could be a requirement between parties that have made agreements about that explicitly. And theoretically, some mail servers could use it as a signal of authenticity of the sender. But email has other, standardized mechanisms for that. And I suspect you might see delivery failures if you start requesting TLS client cert authentication from all SMTP clients.

[btown]

I imagine it's not used as an MTA-to-MTA signal, but rather for organizations where outbound messages, received by the org's SMTP server, should only be accepted when the internal sending device has a client certificate.

See, for instance: https://learn.microsoft.com/en-us/sharepoint/administration/...

Is it possible that orgs have been using Let's Encrypt to issue client certificates for devices on their network to be able to send internal emails over SMTP - to the devices of the old-school partner-level employees who won't use webmail, and to various physical devices on premises? Possibly.

The interesting thing to me is that LE wouldn't know whether this is happening, because they had been issuing combo server+client certificates with the "classic" profile, and wouldn't know which are being used for which purpose. And sure, it makes sense to separate out "tlsserver" and "tlsclient" - but why also add the punitive step of having tlsclient be a new but temporary thing that will go away in May 2026? I don't see any technical reason why they can't support tlsclient, on the new dedicated Google PKI for it, into the future.

[phasmantistes]

The "tlsclient" profile will not be TLSClientAuth-only: it will have both the TLSServerAuth and TLSClientAuth profiles, like the default profile does today. It will exist solely for the purpose of helping people transition off of using Let's Encrypt certificates for mTLS. If they've been unaware of these conversations, their systems will break when the TLSClientAuth EKU is removed from the default profile. That will be their wake-up call, and then they can temporarily select the "tlsclient" profile to get a brief grace period to migrate their systems before the TLSClientAuth EKU is removed entirely.

[mjl-]

Using tls client auth certificates for submission would make slightly more sense indeed. But who would request LE certificates to install them on desktops/phones of individuals? That sounds more complicated than managing your own client certificates.

In my mail server, accounts can use TLS client authentication with submission and imap. But only the public key in the certificate is used, to identify the account. No verification of name or before/after time. You just save the public key with an account, or remove it when you no longer want to allow it. No external CA to trust, or internal CA to run, and no automatic expiration of your connectivity.

As for LE: I think they want to keep things simple. AFAIK they are a relatively small organization. Every task they take on weighs on them. They also don't sign certificates for use with S/MIME.

[KennyBlanken]

> Most SMTP traffic is encrypted nowadays

This is laughably and naively optimistic.

[rnhmjoj]

> I have never heard of any SMTP server doing TLS client certificate authentication. I'm pretty sure there's no standard for that, so it can't be a requirement for all incoming email.

> I suspect you might see delivery failures if you start requesting TLS client cert authentication from all SMTP clients.

Thanks, this aligns with my understanding of things. So, this issue is probably a big nothingburger.