Scott Kitterman wrote:
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 longer I think about this, the more I am of the opinion that we
shouldn't talk about 400-ing in the -base specification. One of the
advantages of DKIM is that it the signer and verifier can be anywhere
within their administrative units, and in particular the verifier
doesn't need to be one of the MX hosts. The use of a 400 in this way
only makes sense if the verifier is in the process of receiving the
message from outside; otherwise, the verifier's domain already "owns"
the message so it might just as well accept and queue it.
I'd suggest that we just remove the mention of special responses to key
retrieval failures in -base, and put them in the overview document as a
deployment option.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html