Tony Finch wrote:
>On Fri, 15 Jul 2005, Russell Wilton wrote:
>
>
>>Questions: Is this a bug / mis-feature in address_data handling?
>>
>>
>
>address_data is delberately persistent. You seem to be trying to use it in
>a way that doesn't allow for this, hence your problems. It isn't clear to
>me why LDAP and the address_data have anything to do with your routing
>process after a redirection address has been generated: the address will
>not be in +local_domains so it should hit your dnslookup router and never
>reach your funky stuff.
>
>Tony.
>
>
I've done some further digging and I've figured out how to solve my
problem, but there may be a better solution. Here is the essence of
what is happening.
I have a router near the top of my routers section whose sole purpose is
to look up the local part of the address in LDAP and populate the
address_data variable with delivery info, including a forwarding address
if it exists, for subsequent routers to use. The router looks like this:
peer_hub:
driver = manualroute
transport = remote_smtp
domains = +virtual_domains
address_data = ${lookup ldap{USER PASS ldap:///.....} {$value} fail }
route_data =
The 'fail' on the end of the lookup, and the blank route_data mean that
the router will always decline whether the LDAP lookup succeeds or not.
The subsequent routers check whether address_data is blank to determine
if the address was valid. This works fine most of the time.
If the user has specified a forwarding address, a redirect router uses
it to forward the mail. If the forwarding address is in the local
domain, a second pass through the routers is begun. Again, this works
fine as long as the forwarding address is valid.
If the second LDAP lookup fails and the router declines, as usual, the
subsequent routers will find the data from the first lookup, still in
address_data. The forwarding router will forward it again and viola, we
have a loop. After a couple of passes, the loop detection code makes
the forwarding router decline. The mail falls through to the local
delivery router and gets delivered to the local user who was trying to
forward it.
The solution, although I haven't implemented it yet, seems to be to
change my LDAP lookup to replace the trailing 'fail' with a '{}' so that
the address_data will get cleared if the lookup fails, like this:
address_data = ${lookup ldap{USER PASS ldap:///.....} {$value} {} }
I realize my configuration has an error, but it was an easy mistake to
make and it appeared to run correctly for months before I noticed there
was a problem. I wonder if other people could be spared some grief with
this subtle error by making address_data a little less persistent.
Perhaps the address_data should get cleared at the start of each pass
through the routers. Comments?
Russ
--
Russell D. Wilton E Mail: WILTON@???
Internet Services Manager Voice: (403) 329-2525
University of Lethbridge FAX: (403) 382-7108
4401 University Drive Lethbridge, Alberta, CANADA T1K 3M4
