To: ietf-dkim(_at_)mipassoc(_dot_)org
Date: Mon, 14 Apr 2008 09:53:28 -0400
From: wietse(_at_)porcupine(_dot_)org
Subject: Re: [ietf-dkim] protecting domains that don't exist
John Levine:
As someone pointed out, you can interchange steps 1 and 2 in the
specification, putting the existence check first. And then, of course,
you
can decide that the existence check is done outside ADSP. If the
existence
check is removed, I would advocate putting in language that says an
existence
check SHOULD be performed before doing ADSP.
That seems reasonable. My objection (and I think also Dave's) is not that
it's a bad idea, but that it's not part of DKIM or ADSP.
+1
-1 I disagree. Having the NXDOMAIN check makes thh scoping boundaries of ADSP
explicit in the discovery algorithm. That is why I advocated making it step 1.
Anything that fails that test is explicitly outside the scope of what ADSP
covers. Without this explicit scope boundary the behavios of different systems
querying this data would become very unpredictable. With the scope boundaries
as defined by step 2 it is unequivocal that any query for something that does
not exist cannot be valid within ADSP.
It's unfortunate that DNS won't let us specify ADSP policies that
cover only non-existent originator domain names, but wishing for
such an ability does not mean that we suddenly can.
The NXDOMAIN result for the originator domain cannot(*) correspond
with an ADSP policy (one of "unknown" / "all" / "discardable"),
and therefore it cannot be part of ADSP.
Wietse
If this test were applied to every RFC then no RFC could ever formally state
what set of data it applies to (since obviously that counter set would be
something that would not have a valid response within that context). If we
applied this same test to DNS for example would we even have NXDOMAIN (or "Name
Error" as its called in rfc 1035) as a response code at all?
Would it be better if "error" were a specifically defined result in addition to
"unknown" / "all" / "discardable"?
(*) Otherwise we could declare 99.9999% ADSP deployment today.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.htm
_________________________________________________________________
More immediate than e-mail? Get instant access with Windows Live Messenger.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_instantaccess_042008
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html