Re: [exim] treating moral config errors as serious

Top Page
Delete this message
Reply to this message
Author: Julian Bradfield
Date:  
To: exim-users
Subject: Re: [exim] treating moral config errors as serious
On 2019-07-18, Jeremy Harris via Exim-users <exim-users@???> wrote:
> On 18/07/2019 21:00, Julian Bradfield via Exim-users wrote:
>> On 2019-07-18, Jeremy Harris via Exim-users <exim-users@???> wrote:
>>> On 18/07/2019 20:03, Julian Bradfield via Exim-users wrote:
>>>> I've just had an embarrassing incident where a system upgrade
>>>> overwrote a customized greylistd, with the result that mail from new
>>>> senders was always deferred because of an invalid condition value, and
>>>> I didn't notice for more than a week.
>>>
>>> What sort of "invalid value" ?
>>
>> "white", "grey" (instead of the "true" or "false" that would have been
>> correctly emitted by the customized greylistd).
>
> Depending where you use strings indicating truth values,
> the interpretation varies. Router conditions have a lax
> interpretation: "false" "no" and "0" are false, anything
> else is true. So "grey" would be true.


I know.

> In others, eg. ACL conditions, tighter rules apply.
> Specifically, for ACLs, you get a defer. This is
> documented.


I know.

> We're unlikely to change those rules; it would break
> valid configurations.


I didn't suggest changing the rules, I asked whether I'd missed a way
to configure the rules (e.g. to replace "defer" by "panic").
Failing that, any way to grep the logs for things that "shouldn't
happen" would be useful. Of course I can now grep for this particular
error, but I'm sure there are many other ways of accidentally breaking
mail which will result in other log messages that shouldn't happen in
a normally running system. Ideally there would be a list of every
message exim can omit...