Marc Perkel wrote:
> There has been some talk about parameter passing and returning values
> from ACLs to make them look like functions/subroutines. Not sure if
> progress is being made so I'm going to propose something and see what
> people think.
>
> My suggestion.
>
> warn set $acl_c_my_variable = my_acl apple banana carrot
>
> my_acl:
>
> warn logwrite = $acl_param1 $acl_param2 $acl_param3
> acl_return = vegetable
>
> ok - it's crude - but if we are going to do this someone has to start
> with a suggestion.
>
> acl_param[1-9] - parameters passed to acl
> acl_params - all params passed as a single string
> acl_return - value returned from acl
>
> If someone has a better idea feel free to improve it.
>
I'm not sure I grok what you believe is not already there.. but I'll bite.
So..
- if/as/when one needs to pass a 'parameter' INTO an acl-clause /
case-of structure.
THEN there exist a finite, but very large number of bespoke variables,
expansion and otherwise, plus all manner of lookups.
Already defined. Well-tested. In production use.
Remember - this is smtp, so there is a *very* finite set of possible
things that can be known w/r the smtp process during which acl's 'live'.
The 'large' part cometh from myriad lookups and such reflecting the user
environment, membership, preferences, status, et al - not from the
protocol itself. It really IS 'simple'.
So - first thing I have to ask is:
"Just what is it that we cannot already pass INTO an acl structure that
is not already well-covered? Moreover - covered with one or SEVERAL
methods each tuned for efficient use with specific needs?"
Then there is output-from or transfer-between.
- if/as/when one needs to pass a 'parameter' OUT OF an acl structure, or
to another such structure:
THEN we have not only MACROS, plus a now-selectably-large number of
general-purpose variable 'buckets, but also the ability to add headers,
call SQL or other lookup tools, and invoke executable - embedded or
external, scripted, compiled, or both.
Again - there exist a large number of bespoke tools already in place for
passing 'stuff' about.
Once again "What is it that is not already there?"
As important is that these existing variables and such are tuned not
only for efficient 'fit', but to reduce risk of unexpected or hard to
find errors.
IOW some are general-purpose (acl-m and acl_c) others expect to 'carry'
a specific type of load and no other ($sender_host_address, $domain,
$local_part).
Further, we have nesting and complex conditionals... If we need them.
Finally - although a router/transport set lives *after* the close of an
smtp connection, and can no longer alter that history, it is eminently
practical to pass information FROM the acl that lived through that
episode INTO the router/transport post-connection 'world' to guide and
direct it. And not just those Exim came out of the box with - but
anything that can be known - standard or not, useful or not.
I see the vegetables, but where is the 'beef' in this recipe you propose?
Looks to me like discarding brake pedal and steering wheel in favor of
talking directly to the tires. Which - if we choose to risk - we can
already do.
Bill
