From: "Wietse Venema"
These issues are inherent with delegation, and since
everything rides on top of DNS anyway, it seems to me
that application-defined delegation methods that attempt
to side-step DNS "problems" just add their own problems to it.
This also applies to DKIM DNS PUBLIC KEY lookup as well. Do you have a
appliction defined plan for this?
In any case, this is an exception to the rule. Not the rule.
It is equivalent to MX lookup failures. We have application defined methods
to deal with it.
In general, there is no reason why we can't deal with general DNS related
issues. We already do for our current service needs.
Keep in mind that DKIM is a payload solution so there is ample solutions for
a system to put a message on hold due to some DKIM DNS lookup failure if
that is what the local policy wants. We may even want to allow it the first
time, but if it is constant, then it moves it into another category. It may
even use a GreyList concept! Who knows?
All this is just part of the implementation details.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html