On Tue, 10 Feb 2009 16:58:22 -0800 (PST) "Murray S. Kucherawy" <[email protected]> wrote: >An intermittent but recurring problem is the above error message. It's >caused when that function in the OpenSSL library fails to create a handle >representing a public key after the key data has been retrieved from DNS. >So far every time I've seen it, it's been caused by a public key that got >mangled in the transition from being a PEM file to a DNS TXT record and >is thus corrupted. > >At the moment, libdkim returns DKIM_STAT_NORESOURCE to the filter when >this happens, which assumes that error is transient and (by default) >temp-fails the message hoping a later retry would work. There's been some >discussion on other lists that this behaviour isn't the best idea; the >claim is that the message should be treated as though a permanent key >retrieval problem occurred (e.g. key not found), and the message delivered >with presumably a "neutral" status reported by the filter. > >libdkim could be changed to report DKIM_STAT_CANTVRFY instead, indicating >to the calling application that a more permanent failure in verification >occurred. This would caused dkim-filter to immediately report a >verification error ("permerror") and pass the message instead of arranging >for a temp-fail of the message. > >I'm hesitant though, because I don't know for sure that this is the only >reason d2i_PUBKEY_BIO() might ever fail. But if it fails for some other >reason, is there a need to make the distiction? What if it failed because >it couldn't allocate more memory, for example? > >In fact, the current behaviour came in handy today when I was able to talk >to a signer with a corrupted key and get it fixed, at which point all the >temp-failing mail came through. > >Anyone want to offer up other opinions? > I'll offer you a related experience with my SPF policy server...
As you know, SPF has a similar concept of temperror and permerror. All DNS errors are treated as 'temporary', even though some require human intervention to fix. In this case I found that there were enough complaints about indefinite deferral due to long term DNS issues that I changed the default to not defer on temperror. My lesson learned (that I think is relevant) was don't defer on an error that requires human intervention to fix. It amounts to a slow rejection (eventually it times out of the sender's queue and bounces). Consider if you think it appropriate to reject mail bases solely on this error and if not, don't make it a temperror. Scott K ------------------------------------------------------------------------------ Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com _______________________________________________ dkim-milter-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
