Re: [exim-dev] calling an ACL from an expansion

Top Page
Delete this message
Reply to this message
Author: Phil Pennock
Date:  
To: Jeremy Harris
CC: exim-dev
Subject: Re: [exim-dev] calling an ACL from an expansion
On 2012-06-12 at 19:54 +0100, Jeremy Harris wrote:
> > If the ACL returns non-accept, does that cause an immediate expansion
> > failure? Does it count as a forced failure?
>
> I've made it cause a failure, but I'm not sure of what type....
> It's in expand_string_internal() like the notdef
> case of EITEM_DLFUNC.


That's non-forced.

Non-forced errors are supposed to be syntax errors which are
panic-worthy, etc.

Part of the problem here is that ACLs typically return something close
to boolean + error cases, but you've got string expansion. I take it
that a defer return which sets message will expand successfully to that
message?

Should this instead be an expansion condition with a side-effect of
setting $value in both the true and false branches?


ACLs can return: OK DEFER FAIL ERROR.

The OK case is easy, we'll ignore that and just consider the other
three.

By my reckoning, ERROR is the only one of the three which should not
count as a forced failure, if they map to expansion failure. Whether
they do or not presumably depends upon whether or not message was set?

IF either DEFER or FAIL can result in expansion failure, then for those
two ACL return codes, the expansion operator should set
expand_string_forcedfail so that it becomes "fails by policy", rather
than "fails by misconfiguration".

(Why yes, we are using one word for two different meanings and just
tacking on "forced" to distinguish between them)

-Phil