John W. Baxter wrote: > On 6/4/10 2:38 PM, "W B Hacker" <[email protected]> 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 -- ## 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/
