4 ms·

I've read the announcement[1] and I don't see how this deprecation has anything to do with SMTP. Is it because the sending MTA will present its own server certi

I've read the announcement[1] and I don't see how this deprecation has anything to do with SMTP. Is it because the sending MTA will present its own server certificate as a client certificate to the receiving MTA? I thought most of this traffic was outright unencrypted or opportunistically encrypted with self-signed certs. Do most SMTP server require, or even use, certs issued by a CA? [1]: https://letsencrypt.org/2025/05/14/ending-tls-client-authentication/ https://letsencrypt.org/2025/05/14/ending-tls-client-authent...

scandox 1y ago
Many systems will not deliver where encryption is not present. Some systems won't deliver without a certificate issued by a public CA. And some systems won't accept an LE cert but require something called OV(organizational validation).
- gruez 1y ago
  >Some systems won't deliver without a certificate issued by a public CA. And some systems won't accept an LE cert but require something called OV(organizational validation). Which systems are these? Are they public email providers? Are they enterprises?
  - scandox 1y ago
    Enterprises. Porsche.com corporate email for example won't deliver without an OV. So once you're in the business of providing any kind of general email service you eventually have to deal with it. Edit: Porsche corporate
    - jamespo 1y ago
      I wonder how many side gmail accounts their employees have to use
    - TheNewsIsHere 1y ago
      Volkswagen has similar policies regarding partners and vendors. If you want into that ecosystem they require that you setup specific mail routing policies and mutually authenticated CAs to exchange email.
- arccy 1y ago
  but delivery to means the receiving end is a server, so they just need server auth TLS certs, not client auth.
  - scandox 1y ago
    That is true. I interpreted your last remarks as meaning you thought that most normal SMTP was outright unencrypted or opportunistically encrypted with self-signed certs.
mjl- 1y ago
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.
- rnhmjoj 1y ago
  > 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.
- btown 1y ago
  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/outgoing-smtp-support-for-client-certificate-authentication 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.

scandox 1y ago

Many systems will not deliver where encryption is not present. Some systems won't deliver without a certificate issued by a public CA. And some systems won't accept an LE cert but require something called OV(organizational validation).

gruez 1y ago
>Some systems won't deliver without a certificate issued by a public CA. And some systems won't accept an LE cert but require something called OV(organizational validation). Which systems are these? Are they public email providers? Are they enterprises?
- scandox 1y ago
  Enterprises. Porsche.com corporate email for example won't deliver without an OV. So once you're in the business of providing any kind of general email service you eventually have to deal with it. Edit: Porsche corporate
  - jamespo 1y ago
    I wonder how many side gmail accounts their employees have to use
  - TheNewsIsHere 1y ago
    Volkswagen has similar policies regarding partners and vendors. If you want into that ecosystem they require that you setup specific mail routing policies and mutually authenticated CAs to exchange email.
arccy 1y ago
but delivery to means the receiving end is a server, so they just need server auth TLS certs, not client auth.
- scandox 1y ago
  That is true. I interpreted your last remarks as meaning you thought that most normal SMTP was outright unencrypted or opportunistically encrypted with self-signed certs.

mjl- 1y ago

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.

rnhmjoj 1y ago
> 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.
btown 1y ago
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/outgoing-smtp-support-for-client-certificate-authentication 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.