"John R. Levine via NANOG" <nanog@lists.nanog.org> writes:
On Fri, 23 May 2025, Jay Acuna wrote:
Using a client TLS cert with SMTP is an option within the TLS protocol, and some clients do.
No, that was a misreading of a decades old file in the sendmail distro.
As anyone who rus a mail server knows, in fact SMTP clients do not send certificates (not to be confused with submission, which is not SMTP, where a few systems do use privately signed client certs.)
I really wish this zombie argument would die. The people who run mail systems are not all stupid, and if client certs were useful, someone in the past 30 years would have tried using them.
I'm not sure what you're trying to say here, but there is no difference between submission and smtp wrt mutual tls. If the server wants to authenticate the client, then a client certificate will be useful. Having optional authentication on port 25 doesn't mean that arbitrary MTAs contacting your MX will be asked to authenticate. It just means that friendly clients are allowed to authenticate, and may get special treatment if they do. Typically being allowed to use the smtp server as a smarthost, similar to what you'd expect on the submission port. I for one use client certificate authentication on ports 25, 465 and 587. There is also the sendmail accessdb support for client certificates. Note that this is different from doing "AUTH EXTERNAL". It doesn't result in an authenticated username. It's more like access list rules, where you match on subject and/or issuer instead of the client IP. Such rules can be used to e.g allow relaying for specific hosts. It is fully possible to use Let's Encrypt, or other public CA, certificates here without compromising the server, provided the rules use specific certificate subjects. I guess that accessdb functionality might break with the announced change. But it's probably for the best. If you have that kind of configuration and add EXTERNAL as a trusted authentication mechanism, then anyone will be able to authenticate. This is a valid reason to remove the client bit from public CA issued server certificates. Makes it harder to make such mistakes. A private CA will always be a better choice for client certificates, even if you just use the accessdb feature. Bjørn