On Mon, May 19, 2003 at 05:13:37PM +0100, Philip Hazel wrote:
> One thing you can do is to set the $address_data variable in your final
> router. The value of $address_data is available back in the ACL. You can
> then put it into a header line that your local_scan sees (and removes).
>
> This is kludgy, but it might work...
Hi Philip,
I've had a chance now to test out your suggestion and unfortunately it doesn't
give the results I was after. Perhaps I didn't explain what I was trying to do
sufficiently.
Our configuration often causes recipient addresses to be re-routed, possibly
multiple times. During ACLs when an address is verified, it seems that as soon
as one router accepts the address, the ACL considers the address verified.
So, the only data available in $address_data would be whatever I can set on
that first matching router. Unfortunately, that's not sufficient for
determining the final routed addresses.
It may be easiest if I explain with an example so here goes. Consider a
message with envelope recipient "sales@???". During delivery the
routers would be traversed as follow:
e.g.
* first traversal:
- "sales@???" satisfies "corp_aliases" redirect router which
replaces the addresses with "a_user@???" and
"b_user@???"
* second traversal:
- routing starts again for "a_user@???" which satisfies "corp_pop"
accept router
* third traversal:
- routing starts again for "b_user@???" which satisfies "default"
redirect router and the address is replaced with
"postmaster@???"
* fourth traversal:
- routing starts again for "postmaster@???" which satisfies
"corp_pop" accept router
To express that another way, during routing the addresses are modified as
follows until arriving at the final recipients:
(1) sales@???
|
(2) +-------> a_user@???
| |
| +--------------------------------------> accepted
|
(3) +-------> b_user@???
|
(4) +-------------> postmaster@???
|
+-----------> accepted
During recipient verification by the ACLs, though, only the first 'traversal'
is done, meaning that the only address data at my disposal at that time is to
say "this address was expanded to a_user@??? and
b_user@???".
What I was hoping to achieve is to be able to have the finally routed addresses
(postmaster@???, and a_user@???) available in the
local_scan function by some means.
> > Perhaps the presentation could be each item in the recipients_list array
> > containing a pointer to another array of post-routing recipient_item
> > structures?
>
> The difficulty is that Exim doesn't really work like this. Routing for
> verification might not be the same as routing for delivery. Equally,
> routing might expand one address into many children.
I appreciate that routing during verification and delivery ~can~ differ, but
this is not always going to be the case.
Our configuration, for example, bases the re-routing decisions solely on
$local_part and $domain (not header lines or anything like that), so for a
particular input (address), the outputs (finally routed addresses) will always
be the same.
> > Thinking of alternative solutions to the same problem, is there some way of
> > expanding "some@???" into what it would be routed to?
>
> It could be routed to rather a lot of different things!
In that case an array or list of addresses might be valuable.
I guess what I'm looking for is some mechanism of retrieving the same addresses
that would be generated from a call to "exim -bt" from within the local_scan
function. e.g.:
# exim -bt sales@???
postmaster@???
<-- b_user@???
<-- sales@???
router = corp_pop, transport = mda
a_user@???
<-- sales@???
router = corp_pop, transport = mda
Does what I describe fit in with the Exim model?
Thanks for your time,
Ollie
--
Oliver Cook Systems Administrator, Claranet UK
ollie@??? 020 7903 3065
