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 [EMAIL PROTECTED] and [EMAIL PROTECTED] 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
