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

Startseite
Nachricht löschen
Nachricht beantworten
Autor: Jeremy Harris
Datum:  
To: exim-dev
Betreff: Re: [exim-dev] calling an ACL from an expansion
On 2012-06-14 00:55, Phil Pennock wrote:
> On 2012-06-13 at 21:42 +0100, Jeremy Harris wrote:
>> accept - OK - true + message
>> defer - DEFER - forced fail
>> deny - FAIL - false + message
>> oops - ERROR - non-forced fail
>
> Makes sense to me.
>
>> (though I don't see any way of using the string result *and* the
>> boolean result from a single call at present, one might happen in the future)
>
> This is the advantage of the conditional, it can just set $value, a
> variable which is already used generically like this.


Hmm. This gets ugly on a couple of counts.

- If it's only available as a conditional then you
   can only use it in a conditional context - which is
   a pain when what you really wanted was the expansion.
    - OK, perhaps we support both methods?


- Syntax as a conditional doesn't easily handle variable
numbers of arguments:
${if <cond> {yes}{no}} has troubles with the difference
between <cond> == <acl {name}> and <cond> == <acl {name}{arg}>
(is {yes} an arg for the acl or for the if?)

   - wrap <cond> in { }  ?  ugly, but matches condition saslauthd
   - don't wrap name or args in { } ?  how to parse?
   - wrap name + args in { }  but space-sep within?
      e.g. ${if acl {name arg1 arg2}  {yes}{no}}
      also nonstandard, but matches acl modifier "acl = name arg1 arg2..."



I was partway though coding the last option when I noticed saslauthd.
--
Jeremy