[ietf-dkim] protecting domains that don't exist

[robert at barclayfamily.com]

> To: ietf-dkim at mipassoc.org
> Date: Mon, 14 Apr 2008 09:53:28 -0400
> From: wietse at porcupine.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mipassoc.org/pipermail/ietf-dkim/attachments/20080414/a0f95620/attachment.html