On 2019-07-18, Jeremy Harris via Exim-users <[email protected]> wrote: > On 18/07/2019 21:00, Julian Bradfield via Exim-users wrote: >> On 2019-07-18, Jeremy Harris via Exim-users <[email protected]> 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... -- ## List details at https://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/
