Hi Daniel,
Thanks for your answers!
On Mon, Mar 21, 2016 at 18:03:27 +0100, Daniel Margolis wrote:
Thanks for the kind words. You're spot on about the URI paths, and this is in
fact a point of ongoing discussion. I'm currently going over a suggestion to
change this to "policy._smtp_sts.example.com/current", which I think has
basically the property you describe. (There's some nuance here about whether
we
should be worried about zones with untrusted subdomains, as in dyndns.org; if
you can serve a bad policy for a domain you can DoS them, but you can do that
anyway with poisoned MX records, so it's not clear to me we really need to
worry here or not. A doubly-nested subdomain was I think in part proposed to
mitigate such a risk.)
An alternative would be to embed the URI of the policy directly in the spec.
But I don't think the difference here is critical, since in either case you
are
using some DNS lookup to determine where to get the policy--either a TXT
record
that has a URI in it or an A record (or whatever) directly.
So, tl;dr: yes, we will probably do exactly what you said and use a
subdomain.
OK, nice.
Regarding the hosted provider case, I think you're exactly right. In the
near-term, if you were fairly sure your provider would always have a CA-signed
cert or a TLSA record for their MXs, you could just on your own initiative
serve a policy for your domain that says so. But the safer way to deploy this
is probably more a model like how our hosted users deploy DKIM: we generate a
policy for them and say, "Paste this in your zone file."
But isn't that a problem? It means that you are going to have many
copies of the same policy, as it was when the customers copied it.
Aren't you worried about the difficulty of updating the policy
everywhere?
Cheers
David
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp