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
