Re: [Exim] String expansion and named lists

Top Page
Delete this message
Reply to this message
Author: Edgar Lovecraft
Date:  
To: exim-users
Subject: Re: [Exim] String expansion and named lists
Kelley Reynolds wrote:
>
> > However, FWIW, I must say that it would be an *extremely* useful
> > feature if Philip could find the time to add it. Even just support for
> > named lists would be a great start.
>
> Not exactly the same as what you're after, but after bringing up named
> variables previously and consequently being shot down, I've found some
> pretty clean workarounds for not having them (without using perl,
> obviously). For example, using a little creativity, you can have at
> least the read portion by using the ${extract} function for LDAP-style
> lookups.
> For example, I have an SQL table with a variety of settings and using
> only one acl variable, I can store an entire row and just retrieve the
> bits I want using a slightly modified query.
>
> warn set acl_m9 = ${lookup pgsql{select 'sender_verify=' ||
> sender_verify from addresses where foo=bar limit 1}{$value}fail}
> ${extract{sender_verify}{$acl_m9}{$value}fail}
>
> as an example. To make things even cleaner, you can use macros and just
> substitute bits in the config.
> SENDER_VERIFY = ${extract{spam_assassin_threshold}{$acl_m9}{$value}fail}
>
> then something like
>
>   deny  condition = SENDER_VERIFY
>         !verify = sender

>
> Then just store 0 or 1 in the database. This lets you get a large number
> of named variables stored in a single acl_variable with only one
> database query instead of many. For writing to a list like that...
> well... that's more complicated, but can still be done with a mix of
> regex and some other fun.
>
> Not quite what you were after, but sort of relevant nonetheless.

--
And just to add to that, as I do something similar with LDAP lookups, but
during the Router stage, with a 'dummy' redirect router that runs first,
does an LDAP lookup of the info I want, and dumps it into the address_data
field so that the address_data can be used in future router condition
statements.
I should add, someone else asked Phillip if this was possible, and I
think the reply, was 'it should work, but I have never thought of useing it
that way before', well, just so everyone knows , it does!

Example:

ExampleRouter:
    #Redirct driver is used here so that we can get all of the lookup data
    #    that we need done.  Leave the data= to NULL so that no actual
    #    redirection is done.  This is a dummy(fake) router.
  driver                         = redirect
    #We do not want to use the router for any sender/rcpt verification
  verify                         = no
    #Do the lookup of the address_data
  address_data                   = \
    ${lookup in DB whatever}
    #The data is set to null so that we don't do anything
  data                           =
------------
then in later routers you can use the address data as described in the
manual for condition statements.
Example:


condition                        = \
        ${if eqi{no}{${extract{DATA}{$address_data}}}{1}{0}}


--EAL--