Mark has a good point in that NXDOMAIN is a definite answer and RFC4871
is clear on how to treat the failed signature. 

If one throws ADSP into the hopper (with a discardable assertion) then
that is a different story and the sender/signer should exercise more
care and testing.

Mike

> -----Original Message-----
> From: [email protected]
[mailto:[email protected]]
> On Behalf Of Mark Martinec
> Sent: Thursday, August 27, 2009 9:22 AM
> To: [email protected]
> Subject: Re: [dkim-ops] Yahoo/BellSouth configuration
> 
> Murray,
> 
> > > But this isn't a transient DNS error.  The authoritative answer
from
> > > bellsouth.net is that there's no such key, because they forgot to
> > > install it.
> >
> > I guess it's a matter of preference, as I'd rather defer on NXDOMAIN
and
> > try at least once more if for example the key record somehow hasn't
> > propagated yet.
> 
> I very much disagree that it is a matter of preference.
> The NXDOMAIN is a definite answer and there is no point in
> retrying.
> 
> 
> John R Levine writes:
> > I see your point, but working around the incompetent only encourages
> them.
> > If anyone's collecting stuff to put in the next version of the
> deployment
> > document, we should encourage people to check that their DNS servers
are
> > serving the key records before using them in outgoing mail.  I
install
> > mine a couple of days ahead, just to be on the safe side.
> 
> Checking the whole setup before starting signing is fine,
> although a signer is free to start signing even before publishing
> the public key, as the RFC 4871 guarantees that such failed
> signatures would be treated no differently than no signatures.
> The RFC 4871 is very clear on this:
> 
>    2.  If the query for the public key *FAILS TO RESPOND*, the
verifier
>        MAY defer acceptance of this email and return TEMPFAIL (key
>        unavailable). [...]
> 
>    3.  If the query for the public key fails because the corresponding
>        key record does not exist, the verifier MUST immediately return
>        PERMFAIL (no key for signature).
> [...]
>    A verifier SHOULD NOT treat a message that has one or more bad
>    signatures and no good signatures differently from a message with
no
>    signature at all; such treatment is a matter of local policy and is
>    beyond the scope of this document.
> 
> 
> I think it is plain wrong and a bug if a verifier tempfails a message
> on an authoritative DNS failure.
> 
>   Mark
> _______________________________________________
> dkim-ops mailing list
> [email protected]
> http://mipassoc.org/mailman/listinfo/dkim-ops

_______________________________________________
dkim-ops mailing list
[email protected]
http://mipassoc.org/mailman/listinfo/dkim-ops

Reply via email to