On Thu, 3 Aug 2000, Brian Candler wrote:
> I am playing quite seriously with LDAP at the moment, and I have a
> suggestion for an improvement - unless I have missed something, in which
> case please point me in the right direction :-)
I am not really an LDAP person - the code was originally contributed,
and I have just fiddled with it a bit. There, that's my excuse out of
the way ...
> This returns "attr1=red, attr1=blue, attr2=fred, attr3=smith" (for example).
> But each time I do the query, I want to extract a different attribute.
>
> Now, I notice that the NIS+ support has a syntax "<query>:<field>" which can
> extract a value in this way:
I am not a NIS+ expert either; I suspect that I copied this code from
somewhere else; can't remember where.
> There is of course the ${extract{fieldname}{data}} operator, however it
> doesn't do what I want for several reasons:
>
> (1) it expects spaces as separators, not comma-space.
You can use the sg operator to turn comma-space into space, but it would
make the expansion horrendous as well as taking time, of course.
> (2) if there is a repeated attribute, it only returns the first one.
I think the NIS+ code behaves like that too.
> (3) I can't use this syntax where a query is explicitly required, e.g.
I think the idea was that there is enough functionality in the LDAP
queries to pick out the field that you want using the query syntax,
whereas with NIS+ there isn't, so there's extra code in Exim. That is
without any caching considerations, of course.
> Now, it would be possible to extend the syntax of ldap queries like NIS+,
> but a more transparent solution would be to enhance the caching so that, for
> example, when you do
>
> ldap:///base?attr1,attr2,attr3?scope?filter
> ldap:///base?attr1?scope?filter
>
> the second query uses the cached results of the first. That would be really
> nice, but maybe not too easy to implement. I've done a bit of testing, and
> it seems that exim doesn't have this behaviour at the moment - two separate
> queries are done.
Exim just hands the query over to LDAP - using the ldap_url_search()
function. It doesn't try to be clever about analysing the query in any
way. (That was supposedly the beauty of using this interface - leave the
work to somebody else. :-)
It occurs to me that a sensible LDAP search engine should be doing its
own caching. Do you have any information on whether this is actually the
case?
> One other point: I am using an LDAP search in local_domains, and the
> knock-on effect of this is that every incoming HELO command triggers an LDAP
> search on the HELO name of the remote system. Is there any way I can stop
> this happening?
The reason this happens is the result of too many broken clients that
say
HELO server-name
or
HELO server's-local-domain
instead of
HELO client-name
When this happens, Exim forces a reverse DNS lookup, in order to get a
client name. Otherwise, you get some very confusing entries in the log
files. However, in order to make this check, Exim has to see if the
argument for HELO is a local domain. Hence your LDAP lookup. I would not
recommend using LDAP for local_domains. Exim makes quite a lot of use of
local_domains for a number of different reasons. This is not the only
example (relay checking is another). Also, if your LDAP database goes
down, all mail is delayed.
If you want your primary data to be in LDAP, one way round is to run a
cron job to regularly extract the list of local_domains into a cdb file
(say) for fast performance.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
