John W. Baxter wrote:
>
>
> On 6/3/10 9:02 AM, "Andreas Metzler" <eximusers@???> wrote:
>
>> John Jetmore <jj33@???> 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
