[Exim] LDAP sizelimits

Kezdőlap
Üzenet törlése
Válasz az üzenetre
Szerző: Paul Makepeace
Dátum:  
Címzett: exim-users
Tárgy: [Exim] LDAP sizelimits
Hi

Is there some way of setting the maximum number of results returned from an
LDAP lookup? I believe that the LDAP URL document states that the client MAY
send this auxilliary, non-query information but that it's not part of the URL
syntax. I looked through the docs (3.00) and didn't see any reference.

At the moment some of the queries can conceivably return large %ages of the
database which is causing deferrals and memory problems. FWIW and this
may/may not be related on some of the larger queries I get exim up to over a
half-gig of memory usage, over two-thirds is resident. The debug log for one
of these queue runs is hardly over 500KB so I don't know why it's doing this.
The data is being passed into perl as in:

# This director matches everything else and attempts resolution using LDAP

aliasuser:
  driver = smartuser
  condition = "${perl{ldap_who} \
    {${lookup ldapm {LDAP_URL(ALIAS_MATCH)}{$value}     \
    {${lookup ldapm {LDAP_URL(SN_MATCH)}   {$value}     \
    {${lookup ldapm {LDAP_URL(SN2_MATCH)}  {$value}     \
    {${lookup ldapm {LDAP_URL(CN_MATCH)}   {$value}     \
    {${lookup ldapm {LDAP_URL(CN1_MATCH)}  {$value}     \
    {${lookup ldapm {LDAP_URL(CN2_MATCH)}  {$value}     \
    {${lookup ldapm {LDAP_URL(CN3_MATCH)}  {$value}     \
    {${lookup ldapm {LDAP_URL(NOMAIL_MATCH)}{$value}    \
    {DUNNO}}}}}}}}}}}}}}}}}}"
  new_address = ${perl{new_address}}
  headers_add = "X-LDAP-Alias: V LDAP_ALIAS_VERSION. Sent to
$local_part@$domain
 resolving to ${perl{new_address}}"


NOMAIL_MATCH is by that stage pretty broad (cn=*${local_part}*) which on a
short email like jo@??? returns lots of matches...

If this isn't currently possible, does anyone have any suggestions as to
temporary workarounds while a more formalised method (e.g. config option) is
developed?

Many thanks,
Paul


--
Paul.Makepeace@???
Thus spake the Master Programmer:
  "Let the programmers be many and the managers few --
    then all will
      be productive." (http://misspiggy.gsfc.nasa.gov/tao.html)