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

Top Page
Delete this message
Reply to this message
Author: Mike Cardwell
Date:  
To: exim-users
Subject: Re: [exim] $header_* not defined in router?
* on the Mon, Apr 02, 2007 at 10:20:44PM +0200, Carlo Wood wrote:

>>> /me wonders why nobody told me that.
>> [looks back at thread]
>> That's because you didn't mention where the router was being run (ie. at
>> which point in the transaction). Now we know, and you know that you
>> can't do this in the RCPT ACL.
> I didn't know the router was run as part of the RCPT ACL. I thought that
> first all ACLs where run, and then the routers.


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.

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.

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.

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

Mike