Auteur: Wakko Warner Date: À: Lane Vance CC: exim-users Sujet: Re: [Exim] :fail: from a router
> >You can do that along with verify = recipient in rcpt acl. I've done this > >before.
>
> 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.
> 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.
--
Lab tests show that use of micro$oft causes cancer in lab animals