Re: [Exim] :fail: from a router

> > Ah - I do have verify = recipient in my rcpt acl. And this is where the
> > "unknown user" error is coming from. With this in the ACLs, Exim has to
> > make a run through the routers to make sure it can deliver the message,
> > correct? Since my blacklist router fails the message, the ACL rejects
the
> > sender, correct? This clears the fog in my head quite a bit!
>
> This could be. As someone aleady stated, a space after :fail: may be
> required (I have not tested w/o it). The information returned during
> routing is the message that would be returned unless you have a specific
> message set in the acl.
>
> > Now, is there any way for me to have the ACL set different errors to
> > return? My whole point for doing this is to allow each individual POP
> > user to set their own scan prefs, whitelists and blacklists. Otherwise
I
> > would do it all in my ACLs rather than having headers set in the ACL and
> > looking for them in the routers.
>
> Yes, use message = (and optionally log_message =) in the acl. This
actually
> would fail in an ACL if the user is an alias to another user. Routing can
> take care of that, but things can get sticky if you have an alias pointing
> to multiple users who differ in preferences. My oppinion in this is don't
> consider aliases when checking preferences unless you can do it in a way
> that wouldn't effect the others.
>
> You can have an ACL lookup user preferences either by files or via sql or
> ldap.

I have tried both with and without the space after the final :. What I am
seeing is that when this fails in the ACL, the cannot_route_message I define
in the router is not being passed back to the ACL. It only uses the
message= value provided in the ACL. Likely what I want to do just can't be
done the way I am trying to do it.

Does anyone know if a variable is set with the router that caused the ACL to
fail? If so, I could use that variable value to query an error message for
the ACL from a file or MySQL.

What about the system filter - when is it evaluated and is it considered
when the ACL runs through the routers to determine deliverability? This
could solve my blacklist problem but could create problems for the
whitelists.

In the end, it looks like my only solution to this might be to make the
error in the ACL be very generic or list all the possible reasons the
message was rejected.

> > Could I do this in transports instead? Every example I have seen have
> > been routers. I guess that is my next documentation reading project.
:-)
>
> I don't think so. transports only take a message and transport it to it's
> destination (be it a local file, remote smtp, pipe, etc). The contionals
> are on routers. The routers attempt to figure out how a message needs to
be
> transported. I used a router to update an sql database that contains an
> automatic whitelist. (Basically local users who email non-local users
will
> whitelist the non-local user. I know there's a thing about senders, but
> the suits don't seem to understand) I did this in a router because I
wanted
> mail I sent (via /usr/lib/sendmail) to be whitelisted as well.

That's a great idea! I might have to think about doing that as well.

-Lane