On Sat, 2006-02-11 at 03:15 -0500, Hector Santos wrote: > In the "good actor" world, the sender will tend to be correct without > ambiguity thus lowering confusion for the receiver. The expectation is > you are doing thing correctly. Where there is an indecision, you side > with acceptance. > > Of course, for DKIM, it should all depend on the "reason" for the > breakage. > > In the case of a bad expiration attribute, that should be an immediate > red flag for rejection with a high payoff, low false positives.
When the effort is to reduce phishing attacks, a message held too long in a queue would not be a clear reason for rejection. This of course would assume the signature can still be verified. The threat may fall into the category of potential replay attack. One solution could be delayed acceptance in conjunction with replay-block-listing. Working through threats, strategies for assessment, and methods for blocking, that effort may provide a better overview of these handling strategies. It seems unlikely DKIM, by itself, will offer a means to reduce the level of spam, which appears to the motivation behind aggressive rejection. At this time, DKIM is unrelated to return-path, so even this avenue of attack remains unaffected. -Doug _______________________________________________ NOTE WELL: This list operates according to http://dkim.org/ietf-list-rules.html
