On Apr 7, 2008, at 2:01 PM, Jim Fenton wrote:
Siegel, Ellen wrote:
As long as such inheritance is possible, i.e. that a subdomain can
automatically inherit from a parent domain, it must be true that
we're discussing subtrees.
There is an important difference. The subtree of example.com
includes everything ending in .example.com such as a.example.com,
b.example.com, and even f.e.d.c.b.a.example.com. ADSP does not
cover the subtree; it covers only labels in the immediate
example.com domain.
When the policy record below _adsp.example.com contains a parameter
that precludes validity for sub-domains below example.com, then it
must be expected this is being used.
If we retain that capability, inadvertent or not, in the spec, I
think we need to call it out explicitly and discuss how to counter
it.
There are two ways to counter that capability: either the subdomain
publishes an ADSP record, or the parent domain publishes its ADSP
record with the t=s flag as described in section 4.2.1 (or,
conceivably, both). Another possibility, I suppose, is to apply an
Author Signature to the message which makes ADSP irrelevant as long
as it isn't broken.
Sub-domain coverage concerns _how_ policy records are discovered when
_not_ published within sub-domains containing email-address with
either none or invalid signatures.
However, I agree with Dave that it may be cleaner to just exclude
the possibility of inheritance rather than try to deal with the
fallout.
It's not cleaner for a domain that wishes to publish ADSP and has
thousands of hostnames in the same domain now faces the prospect of
publishing thousands of ADSP records, and doesn't have tools to
automate
this process.
This can be resolved by qualifying possible valid domains with the
existence of resource records needed to discover SMTP servers. This
limits the instances where ADSP records are need to those nodes that
contain SMTP discovery resource records.
My comment at ESPC was that I believe it would be a Best Practice
for Coalition members to routinely publish, or have published,
explicit ADSP records for domains that they send from.
In that case, there is no need for ADSP. Change the ADSP draft to
simply say use ESPC data to ascertain DKIM signature requirements.
Perhaps ADSP draft should change into a standard format for this data.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html