Chris Knadle wrote:
On Thursday 19 January 2006 17:41, Giuliano Gavazzi wrote:
Then I considered doing email routing with ldap, but that has a
similar problem because the time in which wildcards can be used
is in the address used for the lookup and not a wildcard in an
address that's stored in the directory. [At least that's my current
understanding after doing some experiments.]
sorry, but I did not understand your current understanding.
I'll try to clarify.
If I were using the outdated inetLocalMailRecipient schema, I would have
ldap entries for people such as this (making it interesting):
dn: uid=lister,ou=People,dc=reddwarf
cn: Lister R D
uid: listerrd
mailHost: holly.reddwarf.net
mailRoutingAddress: [EMAIL PROTECTED]
mailLocalAddress: [EMAIL PROTECTED]
mailLocalAddress: [EMAIL PROTECTED]
mailLocalAddress: [EMAIL PROTECTED]
objectClass: inetLocalMailRecipient
...
I would be looking up the values under the mailLocalAddress attribute, and
rerouting email addresses found under the mailRoutingAddress attribute. For
exact matches this works gangbusters. But -- now let's say an email comes in
for <[EMAIL PROTECTED]>. A lookup is done for this, but a lookup
does not match <[EMAIL PROTECTED]>, and even if a wildcard is specified
at time of the lookup, that would only end up looking up
<[EMAIL PROTECTED]> which still won't find a match.
So -- does that explain what I wrote earlier?
- Chris
Not pushing SQL as the answer, there has to be a 'lighter' alternative,
but seems to me that what you want in PostgreSQL-speak is:
where <the DB field name> like 'local_part_prefix%' or <the DB field
name> = 'local_part'
- 'coz what is important will be seen either as the local_part or the
local_part_prefix. The suffix is either missing or 'don't care'.
Now the above sample is bass-ackwards even for PG, and neither properly
escaped nor correct lsearch/exim sytax, but the concept, I think, is to
find *either* an exact match *or* a partial match with anything
following it.
However 'correct' syntax shapes up, two phrases may be better than one
here, as the other challenge, ISTR, is that exim needs the '.' to
delineate prefix/suffix, and it may be missing....
There may be a simpler way in a regexp comparison to look only at the
first 'n' chracters, but I suspect you have highly variable length there...
HTH as a pointer to a way forward anyway...
Bill
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/