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. > > 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. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
