Tony Meyer wrote:
>> condition = ${if eqi{$sender_address_domain}{$dkim_cur_signer}}
>
> Unfortunately, this didn't fix the problem. I get the paniclog entry
> even using this ACL:
>
> """
> acl_check_dkim:
> warn
> !dkim_status = invalid
> accept
> dkim_status = none
> accept
> dkim_status = none
> accept
> dkim_status = pass : invalid
> accept
> dkim_status = fail
> accept
> """
>
> Any further suggestions? The only other mentions of DKIM in my
> configuration are:
>
> acl_smtp_dkim = acl_check_dkim
> KNOWN_DKIM_SIGNERS = paypal.com : gmail.com : ebay.com : yahoo.com : fastmail.fm
> dkim_verify_signers = $dkim_signers : KNOWN_DKIM_SIGNERS
>
> Thanks,
> Tony
>
Been quite a distance from my kbd for a few days, but I have nothing
further on the whyso. You've posted the entire acl set, folk far more
expert than I have parsed that - which is not the same thing as saying
it is w/o flaw. A fix will probably show up soon.
*I* am still puzzled on a peripheral issue - why the 'panic' log is the
destination AND NOT main or reject log.
Wot I expect in PANIC is something that either prevented Exim starting
(can't get the IP or port), prevents doing the basic job on ALL or MOST
traffic, (bad perms, missing files, certs, scanner socket or IP, DB
connection not working ... or something that has already knocked it down.
Given that, inability to GEN a DKIM sig might qualify as a 'panic' but
inability to vet one presented is no different that any other
'credentials' fail.
Eg: serious w/r that message, problematic for that sender, but not of
the sort of fail that knocks Exim off its perch otherwise - as in still
OK and continuing to pass DKIM'less messages in general and DKIM sigs
w/o the specific glitches in particular.
IMHO, that ... classing it as a 'panic' - needs looked at, regardless of
what triggered it [1].
Bill
[1] An illegal attempt to write to the fs is 'serious', but should be
simply prevented at that point, not attempted, then seen as a panic when
it fails.
