On Mon, Oct 13, 2025 at 02:17:56PM +1100, Viktor Dukhovni via mailop wrote: [...] > With STARTTLS, message transmission is fully *encrypted*, but the remote > end is often not *authenticated*. That said, your key observation is that > SMTP is often not end-to-end, and the *client* is then not necessarily > related to the sender.
The client's IP address is already authentication. After all, it is commonly used as part of authorisation. It's a pretty strong signal in its own right. > Therefore, in the context of MTA-to-MTA (port 25) email relayng, a client > certificate could perhaps be used as a lookup key for client reputation, > that could be more robust than an IP address. [...] "Could perhaps" and then "could" again, all in the same sentence? This is the kind of weasel wording found on homeopathic remedies. Talking of things which are expensive, full of bafflegab, and don't work... You gave a link to an Internet-Draft. It proposes adding a new domain name field to the TLS client certificate to be used by DANE. DANE is little more than a mechanism to store certificate identities in DNS and sidestep certificate authorities, i.e. it's a workaround to avoid paying hundreds of dollars for SSL certificates in the bad old days before Let's Encrypt came along. So let's look at how this would work in practice. Imagine that a spammer has just bought canter-and-siegel.ai with a stolen credit card. They self-sign a certificate (or maybe even get one from Let's Encrypt to lend a bit more credibility) and put its identity in the DNSSEC-signed zone, which of course they can do because they control the domain. This is all hosted on the AWS free tier or wherever else will accept the stolen credit card for long enough to do a decent spam run. Meanwhile, you receive a connection from the spammer's server, which is successfully authenticated as being from canter-and-siegel.ai. How does this bring things any closer to *authorisation*? Sure, you could refuse to accept mail not from that domain, but this disadvantages non-spammy providers such as Google -- stop laughing at the back -- who send mail on behalf of many domains. You'd have to fall back on some other mechanism such as authenticating the sender domain of individual messages, and oh look, DKIM already exists. In other words, the client certificate has not contributed anything useful to the eventual accept/reject decision by the server, and was a complete waste of time. This is a FUSSP and should be treated as such. _______________________________________________ mailop mailing list [email protected] https://list.mailop.org/listinfo/mailop
