John W. Baxter wrote: > > > On 6/3/10 9:02 AM, "Andreas Metzler" <[email protected]> wrote: > >> John Jetmore <[email protected]> wrote: >> [...] >>>> Last night I got the following in my paniclog on that server: >>>> 2010-06-03 02:52:36 1OK5EC-0003AM-0q DKIM: Error while running this >>>> message through validation, disabling signature verification. >>> Back to the source of my question, is the above log a big deal? >> No, it is just <http://bugs.exim.org/show_bug.cgi?id=966>. >> cu andreas >> > > Is "fixing" this as simple as removing the |LOG_PANIC > > In (watch the line breaks) > /* If we have arrived here with dkim_collect_input == FALSE, it > means there was a processing error somewhere along the way. > Log the incident and disable futher verification. */ > if (!dkim_collect_input) { > log_write(0, LOG_MAIN|LOG_PANIC, "DKIM: Error while running this message > through validation, disabling signature verification."); > dkim_disable_verify = TRUE; > return; > } > > (The removal would be in line 95 of dkim.c)? > > I do no wish to be paged when some site sends a faulty DKIM header at 03:00. > I do wish to be paged when there is a real panic situation. > > There are other instances of logging to the panic log over in the signing > code--I think at first glance those should stay--closer study could show > that some are driven by user or user MUA faults and should not be panics. > > --John > > >
Presuming this applies only to (the balance of) the current session and child process, why should it be a 'PANIC' situation anyway? Hard-coded PANIC, IMNSHO, should be reserved for events/absence of events that impair the ability of the MTA to function at all. Now - if it were to disable optioned-on DKIM signature verification (attempts) for all *subsequent* sessions/children, that MIGHT be worthy of a 'PANIC'. Even then, only if the sysadmin considered such to be of high priority. Given the less than universal takeup of DKIM to date, that seems an unlikely case as well. A simple log_message manually inserted in an acl covers that for those who need it. Although it is more code, I suggest it might better be made just one more option in log_selector, as doing that ONCE leaves the prioritization at the discretion of the sysadmin going forward. I further suggest that as a general course of action - even coding style - with anything not essential to basic MTA operation. There are just too many sysadmins and too many options to presume s sysadmin's prioritization in hard code for her. JM2CW Bill Hacker -- ## List details at http://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
