On 04/20/2006 18:53, Michael Thomas wrote:
Scott Kitterman wrote:
On 04/19/2006 23:51, Jim Fenton wrote:
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.
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."
Hold on a sec... with normal 400's the sender is the one who's supposed
to eventually
give up, not the receiver. For a DNS entry that keeps timing out, why
should we
special case this?
Yes, but if the receiver indefinitely defers, it doesn't matter who gives up,
the eventual result is the same as a 500 something.
The one special case is that no response to a query for the new RR should not
be treated as no response since some DNS resolvers will not reply at all to a
query for an unknown RR.
I don't know if we need to deal with this now or when we are talking about the
new RR, but we need to make sure that the totality of the specs do not add up
to defer if you get no response for a query to the new RR. It's probably as
simple as don't treat it as no response unless there is no reponse for both
the new RR and TXT.
Scott K
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html