Re: [exim] $header_* not defined in router?

Top Page
Delete this message
Reply to this message
Author: Carlo Wood
Date:  
To: Mike Cardwell
CC: exim-users
Subject: Re: [exim] $header_* not defined in router?
On Mon, Apr 02, 2007 at 09:41:20PM +0100, Mike Cardwell wrote:
> I think there's one major piece of the puzzle that you're missing. All
> the acl's *are* run before a message is accepted. It is then stuck in the
> queue and passed to the routers, as you suggested. *However*, in the rcpt
> acl you can do "recipient verification". What this does is go through the
> routers to check to see if the message can be routed. Of course, whilst
> this is happening exim hasn't yet seen the emails message body, therein
> lies the problem.


Thank you for the full explanation. I understood this in the meantime,
but indeed - I had not realized in the beginning that routers are called
for verification too.

> Recipient verification in this manner can be done from the command line
> with commands such as "exim -v -bv destination@???", or from
> within the rcpt acl with:
>
> require verify = recipient
>
> In an earlier email you said that the router "Gives the result"
>
> R: spamtest for alinoe.com
> checking "condition"
> spamtest router skipped: condition failure
>
> That would happen during recipient verification yes, for the reasons
> specified above, however during the actual routing of the mail it would
> not fail.


However, the routing did not take place (I believe) with this router.
Is it possible that because a router failed during verification, it
later is not used for routing?

Thus, during verification:

router1: failed
router2: failed
router3: success

then, after the message is accepted and the real delivery
starts - it seems that router1 and router2 are simply skipped.

> Now to get a little more confusing. If you're going to do recipient
> verification, and this is well advised, you probabably need to stick
> a router above the one that is failing that can merely tell whether
> or not a message is going to be possible to route. That router should
> be ignored during actual delivery, but succeed during verification.


That would work, thanks. I now "solved" it by adding "verify = false"
to my test router. This causes it to be skipped during verification
and, apparently, that results in it being called during delivery.
Thus - routers as before, except having added "verify = false" to
router2, I have during verification:

router1: failed
router2: skipped
router3: success

and now router2 is processed again during delivery, succeeds then
and thus is used.

> I hope that at least clears one or two things up about the way exim
> operates.


It's getting more clear ;). Please confirm if my conclusions in this
post are correct and then I will understand exactly was had been going
wrong all this time!

Thanks,
--
Carlo Wood <carlo@???>