John W. Baxter wrote:
> On 6/4/10 2:38 PM, "W B Hacker" <wbh@???> wrote:
>
>> 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'.
>
> Thank you, Bill.
>
> Sadly, I was thinking more of my situation here, where I don't want panic
> log entries for the DKIM parsing failure but do want the (main) logged
> information about incoming DKIM generally, than about a proper fix for
> <http://bugs.exim.org/show_bug.cgi?id=966>.
>
> I think I'll go ahead and build a sed script that throws my patch into the
> source and see what happens on the development server. (Our builds begin by
> extracting the source fresh from the tarball, so such things have to happen
> with each build.)
>
> --John
>
>
>
Never learned sed. Do use 'rpl -s' as well as grep to just find the offender,
manually edit it, recompile.
Which - at least on 'onesies' is arguably as fast, and makes it *way* easier to
let the Mark One human eyeball glance nearby and see wot else a change might
break. Something sed and patch aren't all that good at = at least until AFTER a
change has been done and tested.
;-)
But yeah - whether 'greatest good..' or just 'least future devel hassle' - a
generic change toward sysadmin steerability seems more approriate for all these
newish - and generally non-catastrophic-failure - options.
Bill
