On Thu, 16 Oct 2025, Grant Taylor via mailop wrote:
On 10/12/25 11:59 AM, Andrew C Aitchison via mailop wrote:
What would we need in order for SMTP TLS client certificates to have a
useful place in authenticating the sender ?
Please clarify who / what "the sender" is.
1) The person that strung together the words in the body of the email?
(author?)
2) The person that put those words into email form and submitted to an MTA?
(sender in RFC 822 header sense?)
3) The system connected to the receiving MTA? (other side of the SMTP
connection)
I'm not trying to be pedantic here, but I think it makes a difference.
Since TLS is hop-to-hop I don't see that 1 and 2 give more than an
illusion of authority, so definitely 3.
My personal use case is #3, authenticating the remote connected MTA (or MSA)
that's sending the message to my receiving MTA.
Specifically I already have to have, and have to protect, a public
certificate and private key for my hosts that I must keep secure. So
re-using those credentials for multiple things as opposed to needing to
secure additional credentials has some value to me.
This is especially true when the IP address may change and can't be used as a
form of authentication.
I don't think that a hop-by-hop security mechanism in and of itself can vouch
for #1 nor #2. At least not without a LOT more complications somewhat akin
to some of the complications with RPKI for BGP trying to vouch for the path.
Very much agreed.
I envision it as being parallel to SPF/DKIM and perhaps rolled into DMARC
and ARC. Yes, SPF and DKIM already exist and authenticate the content as
well the fact of the message, but a verified TLS client is almost free
and gives some level of assurance that the message did come from an MTA
authorised to used a given domain.
It seems a pity not to use that when calculating a reputation score.
It is a bit wishy-washy, but would ARC be worse if it included it
in its calculations ?
--
Andrew C. Aitchison Kendal, UK
[email protected]
_______________________________________________
mailop mailing list
[email protected]
https://list.mailop.org/listinfo/mailop
