On 2007-11-02 at 13:57 -0400, Maykel Moya wrote: > I would like to know if my lookup are cached troughout the session if I
> use the same query.
>
> Now I'm doing some ${extract {attrName} {${lookup ldap ... so the lookup
> could be exactly the same whenever I need something from LDAP, but if
> the results are not actually cached the ${extract are useless.
exim has a -d option, which can enable various types of debugging;
-d+all for rather verbose logs.
The output will detail what is and is not cached.
If you need to help Exim out because there's a $ in the lookup, then
there are three approaches that come to mind.
There's a section of the manual (The Exim Specification, spec.txt or
online in html, etc etc) entitled "Named list caching" which details how
you can append _cache to a named list directive to say that for the life
of a message, a particular list expansion will always have the same
value, even if it contains a $expansion. However, that's not likely to
help for something returning data in this format (unless you grotesquely
abuse something like a localpartlist).
If the lookup can be done once per message, then can you do it in an
ACL? Then you can use "set acl_m... = ${lookup ...." to put the value
in a variable which you can then reference later with $acl_m...; in
older versions of Exim, that would be acl_m0, acl_m1, etc; in newer
versions, you can have named ACLs, so acl_m_ldapdata.
Otherwise, you're looking at per-recipient lookups; to handle this, use
the "address_data" option on a Router; this makes the value of the
option available in the $address_data option in the Transport *AND* in
later Routers (unless and until one of them uses the address_data
option) and their Transports. However, for this case note carefully if
the transport might handle multiple addresses at once; if so, then only
the first address's address_data is preserved and if that's a problem
then you'll need to look at the "batch_max" or "max_rcpt" Transport
options as appropriate (local deliveries default to only one delivery
per transport invocation, so this shouldn't be a problem).
