On Mon, Oct 16, 2017 at 11:29:38PM +0200, Daniel Margolis wrote:
> This is about
> using SNI for hosting the policy (which is already HTTPS). I don't believe
> SNI brings any value for the MXs themselves (i.e. the SMTP connection). In
> fact, I can't think of any case where someone would want that. Can you give
> an example where it would be desirable, or where not supporting SNI would
> force a provider to split traffic?
RFC7672 (SMTP Opportunistic DANE TLS) specifically requires SNI
for the SMTP STARTTLS handshake. This is because the MX hosts used
by some domains are CNAME aliases (despite requirements to the
contrary) and CNAMEs are broadly supported by MTAs. As a result,
we sometimes find either of:
example.com. IN MX 0 smtp.example.com.
smtp.example.com. IN CNAME smtp.provider.net.
example.com. IN MX 0 smtp.example.com.
smtp.example.com. IN A 192.0.2.1 ; Same as...
smtp.provider.net. IN A 192.0.2.1
In such cases, the provider may need to be able to present a
certificate for the client's domain.
Note, I am not saying that it is a good idea to alias provider MX
hosts with vanity names from the client domain, indeed I typically
advise against this, and yet it is done with some frequency.
So it may be prudent to clarify whether STS is compatible with this
deployment model. Perhaps STS can require that the default (sans
SNI) certificate provided by the MX host match the policy. And
thereby rule out potential SNI-dependence.
Two examples:
lesando.network. IN MX 10 mail.lesando.de.
mail.lesando.de. IN CNAME mail.ud13.udmedia.de.
jachthavenwolderwijd.nl. IN MX 20 mail.wolderwijd.nl.
mail.wolderwijd.nl. IN CNAME mx1.bit.nl.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
