On Thu, 23 Jun 2022, Peter Saint-Andre wrote:
- section 3.2: I wondered why no mention of MTA-STS or DANE? Could/should we say that MTA implementations SHOULD include support for such strictness?
Hi John, thanks for sharing these insights. I'll reach out to a few Comcast colleagues regarding DANE. We the authors of course want to recommend what's best current practice, thus the interest in how widely deployed these technologies are. Another wrinkle is that MTA-STS is specific to the email world, whereas DANE has at least been defined as a more generalized technology and deployment might vary across application protocols (e.g., I know there has been some adoption of DANE in the XMPP community but it is far from ubiquitous).
Among the reasons that DANE in e-mail is less common is that it is tricky. Until MTA-STS and DANE, when a mail server started a TLS session it could and usually did present a random self-signed certificate and nothing checked it. But now it has to present a cert that matches the name that the client expects.
It is very common for a single mail server to handle mail for a zillion different domains. Sometimes all the MX records point to the same name for the mail server, e.g.. all of Gmail's hosted domains point to aspmx.l.google.com., but sometimes each domain has its own name, e.g. the MX for tucows.com is mx.tucows.com.cust.hostedemail.com. This means the mail server has to have a cert for every name that points to it and use SNI to return the correct one. I added SNI to my mail server and have a library of 100 certs for the 100 domains it handles but as you know I am strange.
Regards, John Levine, [email protected], Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
