Those are good points. On large domains it may be more difficult to serve a policy file on the bare domain. I'm thinking about smaller domains serving their own policy - but those are possibly less relevant for MTA-STS.
Ayke On Sep 15, 2017 23:00, "Jim Fenton" <[email protected]> wrote: > On 9/15/17 1:46 PM, Viktor Dukhovni wrote: > > On Fri, Sep 15, 2017 at 08:14:40PM +0000, Binu Ramakrishnan wrote: > > > >> One advantage of using a sub-domain is the ability to delegate STS > policy > >> serving (and mail hosting) to a 3rd party service provider. > > If support for 302 redirects is added, perhaps that case becomes > > less compelling? > > > > Though the redirect to the provider would have to be done by whatever > > serves "example.com", rather than "mta-sts.example.com", and it > > may in some cases be more difficult to get the redirect to happen > > there, so having a subdomain makes it a bit easier to do the job > > with a CNAME, if the provider can obtain the requisite certificate. > > > I see the advantage of including mta-sts as being that it doesn't > require access to the domain's main web server. In a large domain, it's > easier for the mail operations folks to operate a different web server, > and mta-sts could always be CNAMEd back to some other server (such as > the main one) if that isn't the case. > > But this does make me think: what do other .well-known services do? Do > they run into this problem? > > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
