Your assumptions may or may not hold. The MTA can't tell. But it
can tell that ESNI was used. (Well, it's likely a TLS stack that
does ESNI will provide a way for the application to know ESNI was
used, but not certain.)
Having added SNI to my MTA last week, I can say the MTA can definitely
tell unless you have an extremely exotic design. TLS stacks don't do
certificate management, applications do.
In the pre-SNI case, the application sets up a context with the
certificate and key and hands it to the TLS stack when it starts the
handshake. For SNI, the stack calls back into the application with the
SNI string, and the application finds a matching certificate and key to
return to the stack so if can finish the handshake. If you look at web
servers, the SNI cert file information is in with the rest of the server
config so that's how it works there, too. I also did a prototype MTA-STS
policy file server, same deal.
More to the point, though, I think you're overlooking two fundamental
differences between SNI in SMTP and in HTTP. On the web, only the client
making the request knows what web page she's looking for, and the log info
is saved on the server where random presumably hostile third parties can
look at it. In mail, neither of those are true.
By the nature of e-mail, the recipient of a message already knows who the
sender sent it to, since he or she got it. The Received headers go into
the message itself, not third party logs. So the recipient knwos her MXes
and the SNI doesn't tell her anything new about where the mail went to or
from. Even if you add forwarding scenarios, the existing trace info is
enough to tell what addresses the mail was forwarded through and again SNI
adds nothing new.
(Aside; I'd have no objection if "SNI=yes" was logged without
the name. Or "ESNI was used" or similar.)
I wouldn't be opposed to adding that as an option, but I would not agree
that it would make a meaningful security difference.
Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp