ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] domain existence check

2008-05-22 11:02:10

On May 22, 2008, at 9:03 AM, John Levine wrote:

We don't seem to have resolved the question of whether the ADSP should
define a specific existence check, or just say that you should check
but leave the definition for other places.

Personally, I think it's severe mission creep to try to define an
existence check.  It's straightforward to check for a NXDOMAIN or
NODATA result, but I see no reason to think that such a check has the
semantics an ADSP user would want.

The reason for the existence check is simply to make it possible
for an ADSP user to specify consistent policy across all their
space in the DNS tree. A simple check for NXDOMAIN is
sufficient to fill that need. Any semantics beyond that are moving
beyond the reason that the check is needed.



To touch on some of the issues (and try not to rehash them all), the
majority of A and AAAA records don't name domains used in mail and you
can't check short of sending a test message and waiting a week to see
if it bounces, there's many ways a name can exist but again not for
mail (what if there's just a TXT record), and any check we defined
would just be wrong if, e.g., next year we make MX . the no-mail
standard.

So I like Arvel and Wietse's approach, say to do it but don't try to
define it since any definition would be wrong.  Other thoughts?

If you don't define it then the sender has to assume the most
pessimistic implementation, in order for their wishes to be communicated
reliably to all checkers who implement their own form of check
for existence.

That most pessimistic implementation is to assume that the sender
checks only for NXDOMAIN, so the sender will need to explicitly
publish ADSP records for anything that's syntactically valid for
use in email and does not return an NXDOMAIN.

So, that's exactly the same operationally as specifying checking
just for NXDOMAIN, but less clearly communicated, as it replaces
a simple hard rule with unclear language that implies
exactly the same behavior for senders but is more likely to be
misunderstood and misimplemented.

Cheers,
   Steve

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html