On Tue, Oct 24, 2017 at 7:04 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > On Oct 24, 2017, at 1:54 PM, Ivan Ristic <ivan.ris...@gmail.com> wrote: > > > > I don't know, I think people will find good uses for it if it becomes > available. For example, here's one: virtual SMTP providers. > > > One company maintains the core infrastructure, others build businesses > > that focus on branding, marketing, and support. Easy to do at scale with > > SNI, difficult without. Just an idea. > > This is largely unnecessary. No, it really is. If I am building a business on top of someone else's infrastructure, I don't want to build on top of something I don't control; in this case, their domain name. Thus, I don't want to give their MX servers to my customers. It can be as simple as not wanting your users to know that you're "reselling" someone else's service. It raises all sorts of questions. More importantly, once my customers configure their MX, getting them to change their configuration would be not only impractical, but effectively impossible. Asking them to change anything would at the very least be an annoyance, lot of them would refuse, and lots of them would perhaps look elsewhere. At the same time, perhaps the business will want to switch to someone else for the core infrastructure. Or, even, start managing its own infrastructure.... and so on. > Email users never see the "branding" > of MX hosts. Users just see the destination domain. The MX records > are only seen by unattended software. The MX records can just point > at the appropriate infrastructure name. > > Google and Microsoft already provide hosting to millions of domains > with just one certificate chain that directly or through a wildcard > matches all the MX hosts used to do so. > > In Holland there was a recent merger between two hosting companies, > and at the conclusion a few thousand hosted domains updated their > MX records. Maintaining multiple sets of legacy names and managing > multiple certificate chains going forward is more complicated than > working with the hosted customers to update their DNS. > > -- > Viktor. > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > -- Ivan
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
