Dave Crocker wrote:
s The signing practices apply only to the named domain, and not
to subdomains.
So this is intended to overcome the problem of not being able to use
wildcards?
What is the query behavior that validators need to use, to discover this
record, when they start with a message having a deeply-nested From field
domain name?
To the extent that the above is not sufficiently clear:
There is not way to properly enforce or even discover the semantics of
this flag, in the general case of sub-domains. This option needs to
removed or be specified in a way that works.
This does not address the wildcard issue.
The parent-domain checking is done primarily to ease SSP deployment for
domains having large numbers of hostnames. Without this feature, a
domain needs to publish an SSP record for every label in the domain, so
that it's not possible to trivially bypass SSP by using a hostname as
the domain part of a From address. Otherwise, an attacker could use a
From address like user(_at_)www(_dot_)example(_dot_)com and
user(_at_)zeus(_dot_)example(_dot_)com where
www and zeus are hostnames within the domain. The DNS folks say there's
no problem with having a lot of records in a domain or zone, so it's
just a practical matter of getting them published.
This mechanism does not address deeply-nested From domains. Either such
domains really do exist (in which case they need SSP records), or they
do not (in which case the domain query will return NXDOMAIN), or there's
a wildcard, in which case a deeply-nested address will probably just
look non-Suspicious.
The "s" flag just keeps the policy from "bleeding down" to subdomains
(and hostnames, etc.) in those cases where it is not desired. It's
discovered when the parent SSP record is retrieved; if it contains the
"s" flag, the parent record is ignored.
This issue is also being tracked as issue #1402 that I opened a year ago.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html