--On Tuesday, April 28, 2020 14:40 -0400 John Levine <johnl@xxxxxxxxx> wrote: >... > The only reputatation of SMTP clients is by IP address, > generally queried through DNSBLs. In the other direction, > clients can authenticate SMTP servers via TLSA or MTA-STS to > be sure they're talking to the intended MX, not a middlebox. John, I haven't found anything we disagree about other than what the value is of splitting these hairs. However, in the interest of splitting them even further: 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. Useful, probably not (at least for other than intra-ADMD operations at the receiving end) but not prohibited and certainly not restricted to submission servers as the sending end. On the other hand, possibly useful for authenticating a designated lower-priority MX server the next higher-priority one to which it is connecting if one needed to do that. As a possible use case, remember that we have a very long (and important and successful) history of associating MX records with national or enterprise gateways. One can define those as within an ADMD by sufficient handwaving, but for at least some cases that would imply sub-ADMDs and/or some ADMDs being more equal than others and, in any of those cases, present some desirability of being able to authenticate those gateways. An appropriately-narrow definition of "reputation of the client" or a careful distinction between the client (MUA? Submission server?) and the user who originated the message probably makes "The only" in the statement above true, but it is worth remembering that, if those distinctions are dropped, we have mechanisms for identifying and authenticating sending users that, btw, survive relaying (no matter what hair-splitting is done about ADMDs). At least AFAIK, the IETF has not yet deprecated either OpenPGP or S/MIME. best, john
