On 04/19/2006 23:51, Jim Fenton wrote:
Scott Kitterman wrote:
There is another potential issue with this approach if we get to a
dedicated RR type. While not an issue when using TXT, there are
resolvers that will fail to respond when queried with an unknown RR type
(no I don't know which one, just that it happens).
In this case if the verifier defers based on lack of response, it may be
indefinite.
This points out another problem: if a verifier defers verification or
acceptance of a given message, it SHOULD maintain enough state so that
the message may be accepted after some number of retries, so that
messages with key retrieval problems are not rejected entirely.
-Jim
For SPF, which is where I ran across this, their problem was that they'd
specified that queries for SPF records could be made both to TXT and their
dedicated RR type (Type 99/SPF) either in parallel or in series and that if
there was no response, then it should be considered a temporary error. This
approach resulted in domains that used resolvers that wouldn't respond to a
Type 99/SPF query always getting a temporary error, even if they had a
perfectly good TXT record but Type 99/SPF was also queried.
Their solution was to change the draft to say that it was only a temporary
error if neither TXT nor Type 99/SPF responded. The idea being that if you
didn't get any response for TXT (not even NXDOMAIN), then their DNS was down
and temporary error was an appropriate response.
First, I think we need to make sure that any error condition that we suggest
deferring message acceptance for is truly a temporary condition. No DNS
response to a new RR type does not fall into this catagory. It isn't clear
to me whether we need to worry about this now or if it can wait until we get
to defining the new record?
WRT your point, I agree. Perhaps we need to add another bit along the lines
of, "If an email is deferred based on lack of response to the query for the
public key, the verifier SHOULD NOT indefinitely defer the message. While
messages SHOULD be deferred for temporary DNS issues, lack of response to a
query for a public key alone SHOULD NOT result in messages being permanently
rejected."
I realize that as written the proposed text is pretty proscriptive for the
receiver, more so than we generally have been. I couldn't come up with a way
to phrase it that wasn't. I put the word alone in the second sentence to
leave it open to receivers to consider this along with other factors in local
policy and perhaps indefinitely defer based on this and other factors.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html