Re: [dkim-milter-discuss] d2i_PUBKEY_BIO() failures

[SM <sm...@re...>]

Hi Murray,
At 16:58 10-02-2009, Murray S. Kucherawy 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.

The later retry generally ends up as a temp-fail.  By having a 
temp-fail, we can always put in an override to accept that 
message.  Without the retry, we lose the message.  There are cases, 
for example when the sender does not know the receiver, where the 
receiver will "lose" the message.

>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.

Are we sure that this always results in a DKIM_STAT_CANTVRFY?

>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?

If the failure was because a memory allocation problem, that may not 
happen on the retry.  Changing the error to a permerror means that we 
will have a failed verification instead of the low probability that 
the verification might be successful.

>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.

If there was a permerror, this might not have been fixed.

Regards,
-sm