>Basically this is an extension to SMTP to allow mail exchangers to be >queried for information about the email addresses for which they accept >mail. >Such information could include public keys. >TLS is required by this extension and is used to authenticate the responses.
This looks to me like a reasonable approach to distribute mail signing keys. I have concerns about some of the details, but in general, it seems obvious that the way to distribute information about mail addresses is through mail servers. Concerns and niggles: For AQPX, I think it either needs a port number, or redefine it so that one AQPX follows the redirection chain and returns a response other than 213. There are still plenty of firewalled environments that block everything other than port 443 and proxied port 80. (That's why I run ssh on port 443, and I'm not the only one who does.) I'm not too worried about malicious clients doing abuse by proxy, since the submission server knows who the clients are and a competent one has to deal with a range of client abuse issues already. I fear that the response model is already too big, and we're likely to end up with servers that can serve keys just fine, nobody provides forwarding info (EXPN is still dead), and the other results are sort of random. It's also not clear to me what the security model for transmit-signing-policy and the like are. Even assuming we add a TTL to deal with stale policy advice, I don't see what I as the recipient of a perhaps unsigned message can usefully do with policy advice like "when-able" since I have no way to tell whether the other end knows what my policies are. In section 6, the requirement that the TLS session has a certificate with the same domain as the address in the response is unlikely to work. There are mail systems that handle mail for tens of thousands of customer domains, and it's hard to imagine them maintaining tens of thousands of certs to serve up with SNI. I don't think this is particularly hard to fix, perhaps the customer can provide the relevant part of the JSON signed, and publish the signing key in a TLSA record at _aqry.<domain>. I want to emphasize that these concerns all look straightforward to fix and the basic idea is well worth working out and trying out. R's, John _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
