> On Oct 21, 2017, at 2:40 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > > >> On Oct 20, 2017, at 7:09 PM, Jim Fenton <fen...@bluepopcorn.net> wrote: >> >> Maybe this was explained somewhere earlier in the thread and I missed it, >> but can you explain what ‘vanity hosts’ are? > > An alternate name for an MX host that might require a non-default > certificate chain based on SNI. For example, a customer example.org > of provider example.net might have: > > example.org. IN MX 0 smtp.example.org. > smtp.example.org. IN CNAME smtp.example.net. > > instead of the more direct: > > example.org. IN MX 0 smtp.example.net. > > sometimes the customer will even alias the target IP address: > > ; customer zone > example.org. IN MX 0 smtp.example.org. > smtp.example.org. IN A 192.0.2.1 > > ; provider zone > smtp.example.net. IN A 192.0.2.1 > > This type of aliasing makes some sense for port 587 submission, > where changes may require reconfiguring MUA settings, but not > so much for inbound MX, and yet it is done in a small, but > perhaps non-negligible fraction of cases. > > STS might require that this not be done, and it would likely > not be a major barrier to adoption. Or this could be supported, > and client MTAs would send SNI to elicit the appropriate chain.
Thanks, Viktor; that explanation helped a lot. One situation I can think of that might still require SNI is if two providers merged and combined their infrastructure. Example.com and example.net might each have 1000s of customers and it might not be practical for them to get the customers’ MX records updated in a timely fashion, so the same IP might need to handle requests for both domains for some period of time. -Jim _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
