On Tue, 28 Apr 2020, John C Klensin wrote:
While I don't think it would be useful in any realistic case I can think of, I don't think anything in RFC 4954 would prevent a delivery-end server from advertising the extension and an intermediate MTA relay from using it. That would provide some validation of (or independent of) the argument to the EHLO command that did not depend on IP addresses. ...
Sure, it's easy to imagine ways one might make arrangements like that. Since SMTP AUTH uses SASL you're mostly limited to shared secrets with counterparties you already know. (I say mostly since in principle SASL can use OpenID although I don't know anyone who does.)
On the third hand, in STARTTLS both sides can offer a certificate. Somewhere I have lying around old submission server patches that let clients authenticate doing STARTTLS with a cert that is signed by a particular CA. It has the same problem as any other certificate, key distribution and management is painful, after which it works fine. I hear that people do that although I don't know any directly. Maybe Ned does.
Any SMTP client can present a certificate during STARTTLS, either signed by a CA or using DNSSEC and TLSA, and the server can do what it wants with it. I suppose it might be useful for senders with large farms of outgoing mail hosts to use a shared certificate so when they switch IPs, the reputation stays with them.
Regards, John Levine, johnl@xxxxxxxxx, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly
