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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
