Scott Kitterman wrote: > On 04/14/2006 10:36, Hector Santos wrote: > >> In section 6.2 "Get The Public Key, we have step #2 >> >> | 2. If the query for the public key fails to respond, the verifier >> | SHOULD defer acceptance of this email (normally this will be >> | achieved with a 451/4.7.5 SMTP reply code). >> >> This assumes dynamic SMTP level operational (DATA call out) implementation. >> In my view, this is the ideal and the prefer mode of DKIM operation. >> The fact that this is a SHOULD also seems to presume that the verifier is the first-hop MTA in the domain (i.e., one of the MX hosts). Otherwise it wouldn't matter whether or not you defer acceptance, or accept and queue the message. SHOULD seems a little strong in the general case. >> But what about post SMTP/transport DKIM implementations? >> >> This requires mail acceptance and DNS query errors/rejections can promote >> bounce attacks. This dilemma also promotes unreliable mail >> delivery/notification practice (dropping mail rather than take chance >> bouncing mail as required by SMTP). This is a tough one, hence why there >> is the direction to do SMTP level operations since the response is >> established and the design resolves all SMTP technical (and legal) >> expectations. Nonetheless, DKIM, as a payload solution, there will be >> operations in post smtp modes too. So this needs to mentioned/addressed as >> well. >> >> > 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 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
