On May 28, 2008, at 12:44 PM, Dave Crocker wrote:
PRO
---
ADSP is supposed to arm the domain owner with a means of protecting
his *name space* from unauthorized use in an email From: header.
[...] If an NXDOMAIN check is not performed _THEN_ it becomes
trivial for an attacker to circumvent ADSP.
Only determining whether a domain exists to confirm a legitimate lack
of an ADSP record prohibits use of wildcards by other protocols. SMTP
is not the only reason DNS is used. As you indicated initially, the
test is to verify whether a domain might support SMTP. This can be
confirmed by checking the existence of MX or A records, where of
course the domain would be disqualified when it does not exist (As it
would for RFC2821). Some companies use internal exchanges using lists
within private name space. Even the minimal requirement that a domain
exists within DNS requires a means to make exceptions. ADSP imposes
the same need.
CON
---
I suspect a critical issue is the exact meaning of "name space". As
used here, it appears to refer to everything under the 'root' of an
owner's domain. That is, it is meant to cover an entire sub-tree,
rather than to a specific, single, registered string.
Parent domain would be a better term than "root".
The existence check sets the goal of protecting unused names under a
some domain name "root".
Disagree. Checking for evidence of SMTP support prevents domain
spoofing independent of any parent domain. This check will not convey
any parent domain related policies.
[...]
The assumption is that a specific domain name and all of the names
under it will share the same reputation.
The assumption is customers will recognize a parent domain and believe
a message containing an email-address within the parent domain is
equally controlled by the parent domain.
It seems both you and Jim's SSP draft have a concept of identities
useful for reputation confused with ADSP records and DKIM identity
parameters. Only the DKIM key domain can be safely bound to a
reputation.
We *want* different reputations for transactions.paypal.com and
newsletter.paypal.com and corporate.paypal.com. Remember that these
names that are used to sign with DKIM are voluntarily chosen by the
signer. If they use different strings, they intend different
assessment. If we assume an inheritance, tree-based model for
reputation, such as with paypal.com, we eliminate this very useful
ability to discriminate among different mail streams coming from an
organization.
Being able to assert the practice of a domain is independent of any
domain reputation. Only when a common Key Domain is used, would
reputations be shared. The use of common Key Domains is completely
within the control of parent domains and is fully independent of the
ADSP practice assertions made by Author Domains (when these differ).
This argument is flawed since it is based upon a false premise.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html