On Sat, May 14, 2016 at 02:37:56AM +0300, Vladimir Dubrovin wrote:
> 1. Current draft does not allow to control STS policy for subdomains. It
> means every subdomain which can be used as a recipient's domain must
> have it's own policy.mta-sts A-record and _mta_sts TXT record.
And this is unavoidable with STS. When sending mail to:
[email protected]
It would be rather unsafe for the client to "walk up the tree"
looking for STS records in parent domains. Where should it stop?
"com."? What about "name." where there are delegations of the
form "foo.name" and "foo.bar.name"?
> There are
> situations where this is practically impossible, e.g. wildcard domains.
> For example, I want MX to accept mail for *.example.com and support STS.
> Having policy.mta-sts.*.example.com can be problematic if *.example.com
> already exists as e.g. CNAME.
That's actually not a problem, CNAMEs have no effect on sub-trees,
so you can have a sub-domain of a CNAME, just not a delegated one:
*.example.com. IN CNAME ...
foo.*.example.com. IN TXT ...
> In addition, it can lead to overhead in
> reporting, because every subdomain generates it's own report as a
> separate message.
Yes, mail to wildcard sub-domains is mostly a bad idea, and leads
to all sorts of problems.
> The proposal is, to include additional field, e.g. "s" with possible "y"
> and "n" values into _mta_sts record
>
> sts-subdomains-flag = "y" / "n"
> sts-subdomains = "s" *WSP "=" *WSP sts-subdomains-flag
Easy enough, but...
> and extend policy search procedure to request / use cached policy from
> parent domains (e.g. example.com) if no _mta_sts exists in subdomain (eg
> sub.example.com). If nearest parent domain with pubished _mta_sts policy
> has s=y in the TXT record and "subdomains":true in the policy - use
> this policy for subdomain and aggregate reporting into parent domain's
> report.
This is the part I think is a bad idea. It is inefficient, and it
is unclear where to stop the search.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
