Phil Pennock via Exim-users wrote:
> On 2020-10-01 at 13:24 +0700, Victor Sudakov via Exim-users wrote:
> > Could you please help me unite the following two ACL expressions into one:
> >
> > accept condition = ${lookup{$local_part@$domain}lsearch{/etc/dovecot/aliases}{yes}}
> > accept condition = ${lookup{$local_part@$domain}lsearch{/etc/dovecot/users}{yes}}
>
> Why?
>
> It's _possible_ to combine conditions but too often it creates a bit of
> a mess.
>
> If you just leave it as two different accept verbs, then if the first
> one doesn't pass, the second will be tested and ... you will have a
> short-circuiting OR by using accept-then-accept.
Hello Phil,
I thought there would be a performance penalty if we evaluate two ACL
conditions in a succession (in case the first fails, we evaluate the
second), instead of always evaluating one ACL condition.
Actually I have no other reason to combine them.
>
> For a Router, all condition rules must pass, so it becomes an AND.
>
> > Should be fairly simple but... I've tried variants of '${if or {...' by
> > the manual but all I got were errors like
>
> The explanations here have been covered by others in the thread but I'm
> combining it all into one, then comparing to the original.
>
> So: a string needs to be made into a boolean status, because or/and take
> booleans, not general strings. "Expansion conditions".
>
> * bool{X} interprets X in the same way that ACL condition rules do
> * bool_lax{X} interprets X in the same way that Router conditions do
Why did the Exim architects find it necessary to complicate things by
making if/or/and behave differently from ACL and Router condition rules?
And why did they call bool{...} and friends "Expansion conditions"
while they are clearly not conditions, but operators?
>
> So these should be equivalent:
>
> accept condition = ${if or{\
> {bool{${lookup{$local_part@$domain}lsearch{/etc/dovecot/aliases}{yes}}}}\
> {bool{${lookup{$local_part@$domain}lsearch{/etc/dovecot/users}{yes}}}}\
> }}
Yes, thanks, this works. I wish however that I would not have to write
complicated nested conditions for exim any time soon.
>
> I don't know about you, but I find the separate rules easier to read and
> debug, with fewer braces to be matched and fewer bits of specialist lore
> to be memorized.
>
> Simplicity and lack of nesting wins out over fancy boolean conditions
> constructed by a human instead of a machine.
>
--
Victor Sudakov, VAS4-RIPE, VAS47-RIPN
2:5005/49@fidonet
http://vas.tomsk.ru/
