Could you all help me to understand this point in more detail. Define
the NXDOMAIN issue for me, and how it relates to receiver filtering
decisions. Examples welcome. (I have some idea of what I think this
means, but I'd like to see it clarified to better understand it.)
Eric Allman described the problem well in this thread:
http://mipassoc.org/pipermail/ietf-dkim/2008q2/009936.html
But, I'll have a crack at it myself.
Suppose example.com wants to protect itself from unauthorized use
through an ADSP policy of "I sign all mail." Suppose further that it
deploys this policy to every one of it's sub-domains. At this point
example.com has done everything it can to tell the world "I sign all
mail." Given the above, attackers can no longer send mail as
example.com or any existing sub-domain thereof to an ADSP capable
receiver without detection (and consequent filtering action). This is
very good.
Now suppose that the attacker decides to send the mail from
doesnt-exist.example.com. Note that this sub-domain is still part of
example.com yet since "doesnt-exist" doesn't exist there is no way the
administrator at example.com could have deployed an ADSP record for it
and where there is no ADSP record, the algorithm requires a result of "I
do not sign everything." Thus is ADSP defeated and we become, in my
view, a laughing stock for overlooking an obvious hole in our algorithm.
Enter the NXDOMAIN check. If, as part of the ADSP algorithm, an
NXDOMAIN check is performed, the algorithm can quickly detect that the
domain doesn't exist and that _this_ might be the reason there is no
ADSP record. This added insight closes the hole and can be used by
filtering agents.
The debate has shifted from outright hostility to any NXDOMAIN check at
all (complete elimination of it in it's entirely) to just removing it
from a required algorithmic step and instead referencing it
non-normatively with some version of "this is a good idea that you might
want to think about if you're not already doing it."
This is where we are at present on the NXDOMAIN issue I believe but
others might have a different view.
Arvel
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html