Viktor Dukhovni пишет: > 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"? At least DMARC (RFC 7489) already uses recursion like this and it's generally considered as a safe, because public registries (including .name) do not allow domains / records with underscores, so _mta_sts can not be registered in a public registry (see RFC 3696). Generally, it's safe to stop at second level domain, but in addition, list of known public suffixes (https://publicsuffix.org/) can be used to avoid recursion to public domain and above. >> 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 ...
DNS RFCs only allow wildcards in leftmost position, so foo.*.example.com. doesn't conform to existing standards and AFAIK this syntax is not supported in bind. >> 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. There are public mail servers where users historically were allowed to register subdomains to receive mail in addition to mailboxes. > >> 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. > -- Vladimir Dubrovin @Mail.Ru _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
