[Exim] Odd behaviour with nested lookups in 3.02

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Paul Makepeace
Ημερομηνία:  
Προς: exim-users
Αντικείμενο: [Exim] Odd behaviour with nested lookups in 3.02
I have the following construction I posted a while back that attempts to
perform a series of increasingly less specific LDAP lookups to try to resolve
an email local part:

localuser:
  driver = smartuser
  condition = ${perl{ldap_who}
    {${lookup ldapm {LDAP_URL(ALIAS_MATCH)}{$value}
    {${lookup ldapm {LDAP_URL(SN_MATCH)}   {$value}
    {${lookup ldapm {LDAP_URL(SN1_MATCH)}  {$value}
    {${lookup ldapm {LDAP_URL(CN_MATCH)}   {$value}
    {DUNNO}}}}}}}}}}
  new_address = ${perl{new_address}}
  headers_add = "X-LDAP-alias: sent to $local_part@$domain"


For the sake of clarity I've split them over several lines. For some reason I
can't break these with backslashes or else I get:

1999-07-12 20:28:15 Exim configuration error
option "" unknown in line 321

Anyway, that's not the point ;-) (but is something I'd like to be able to do,
esp. with lines like the above). The point is that redundant/extra LDAP
lookups are happening.

To recap briefly on what the above logic is doing: the first lookup does an
LDAP match like (alias=cpsm100). If this returns >=1 results it uses that
$value else it attempts the second string, i.e. the rest of the code which
tries (sn=...) etc. It's supposed to be like, to use C's syntax & semantics,
alias(lp) ? answer : (sn(lp) ? answer : (sn1(lp) ? value : (cn(lp) ? value :
'DUNNO')))))

What actually happens is that if the ALIAS matches, the SN1 and CN lookups
are performed as well but not the SN lookup. If SN matches (i.e. ALIAS failed
just before) then CN is also tried but not the SN1. So basically it looks
like, for some reason, later queries are being attempted even with matches
previously.

To summarise graphically: If, below, 1 means a lookup and >=1 matches and 0
means a lookup and zero matches and x means no lookup attempted I see:

assc
1x00 -- oops, should be 1xxx
01x0 -- oops, should be 01xx
001x -- fine
0001 -- fine
0000 -- fine

I don't know whether this is a function of LDAP or the lookup or string
expansion. I thought I'd let someone know ASAP before going into it any more
in case a) mea culpa syntactica b) it was an easy bug fix. If not I can
provide more info/debug logs (didn't look any more revealing)/shell account
if it's really hard.

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)