Thanks a ton to Wakko and Sander for all your suggestions and ideas! This
is now fixed and working just as I wanted it to.
The solution:
In your ACL where you have verify = recipient set the message =
$acl_verify_message. In my rcpt acl block I have the following:
accept domains = +local_domains
endpass
message = $acl_verify_message
verify = recipient
Then in any router where you will potentially fail a message you would
include:
data = :fail:$local_part@$domain has blacklisted all mail coming from
$sender_address_domain
with your desired error message immediately following the :fail:
Lastly, in your very last router you would want to include
cannot_route_message like the following to define the error message you want
to return if the message cannot be delivered at all:
cannot_route_message = Unknown local user or domain
-Lane
----- Original Message -----
From: "Wakko Warner" <wakko@???>
To: "Lane Vance" <lists@???>
Cc: <exim-users@???>
Sent: Wednesday, October 15, 2003 1:05 PM
Subject: Re: [Exim] :fail: from a router
> > 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.
>
> If you have message = then that will be returned regardless of what you
put
> after the :fail: .
>
> However:
> $acl_verify_message: During the expansion of the "message" modifier in an
ACL
> statement after an address verification has failed, this variable
contains
> the original failure message that will be overridden by the expanded
string.
>
> May do what you want.
>
> > 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.
>
> see above.
>
> > 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.
>
> I'm not sure, I don't have many dealings with filters.
>
> > 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 be =)
>
> > > 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.
>
> I thought it was a bad idea because of forged senders. I did it so I
> wouldn't have to put up with people getting blocked. I still think it's a
> bad idea.
>
> --
> Lab tests show that use of micro$oft causes cancer in lab animals
>
> --
>
> ## List details at http://www.exim.org/mailman/listinfo/exim-users Exim
details at
http://www.exim.org/ ##
>
>
