* 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 [EMAIL PROTECTED]", 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 -- ## 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/
