On 04/20/2006 09:53, Douglas Otis wrote: > On Thu, 2006-04-20 at 07:53 -0400, Scott Kitterman wrote: > > 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." > > Deferred handling allows recovery from equipment faults which may take > hours or days. Holding state for such situations could create a sizable > overhead. Unless there is a reason to believe there may be some issue > at the receiver, continued deferral seems appropriate. > For some definition of sizeable I'm sure that's true.
Greylisting, which requires that the state be held, is popular enough that I don't think this overhead is a significant issue for most. The arguments I see against greylisting are almost exclusively about message delivery reliability. I don't see people not using greylisting due to the processing overhead. >From my perspective, as long as the deferrals are for true temporary errors, then if the length of the temporary error exceeds the time period for which the sending MTA will retry, that's OK (so I don't personally feel obligated to mandate that message state be maintained). My concern is that there are DNS errors that are not temporary and so we need to be careful with this section not to mandate eventual message rejection due to lack of a reply to a query for public key. Scott K _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
