Voservers ElEstdafa wrote:
> Hello,
> I was trying to block mails sent out from php scripts to recipients in a
> file (blacklist file)
> I added:
> acl_not_smtp = acl_voserver
Interjected:
an 'acl_not_smtp' structure has no 'smtp session'.
Ergo no distinct 'phases', such as CONNECT, HELO, MAIL_FROM, RECPT_TO,
or DATA. Generally it is a single-pass 'on-box' invocation
of the Exim binary.
Think of it as springing to life already at DATA phase, as the whole
message body and any attachments are 'in hand' immediately.
Hold that thought...
>
> bellow
>
> acl_smtp_rcpt = check_recipient
> acl_smtp_data = check_message
>
> Then down above the check_recipient I added
> acl_voserver:
> drop
> log_message = match recipients_drop.list.
> recipients = /etc/recipients_drop.list
> accept
>
> also created the file /etc/recipients_drop.list
>
> But this reject all messages sent with error: cannot test recipients
> condition in non-SMTP ACL
>
> Note that when I add the same acl to the check_recipient it works but for
> smtp mails only
>
> Any ideas on what's wrong?
See above w/r smtp session 'phases', The separate handshakes between
submitter and your Exim MTA DO exist here.
> ,,, Or how to solve this?
>
>
Not hard, but might be a bit tedious:
acl_not_smtp can do the same tests, just not always in the same manner.
A recipients check, for example, is ordinarily done by a 'router walk',
wherein each router is asked in turn to 'verify' that they 'could' match
the submission and route to a transport IF it were to actually be
submitted (which it is not...yet).
But it doesn't have to be done that way.
So long as you can access the same underlying information those routers
would do, or a 'clone' of same, optionally trimmed - you can do it directly.
In our case, that is by an SQL SELECT.
Any other DB call or lsearch against a list or file - or a series of
same - would serve as well.
CAVEAT1: One downside is that one may indeed need to search *several*
such creatures - to handle system aliases, forwarders and the like as
well as 'ordinary' recipients. Or - add those to the same DB/list.
It takes a bit of extra work to setup data access and craft the lookup
for this method rather than utilize already in-place routers.
However - done reasonably well, it need not take any more machine-time
or resources to accomplish than a router verify walk, and can obviate
the need for external scripting or embedded perl.
Furthermore .. and this can be a large plus - you can craft the bespoke
lookup in such a way that your possibly-errant scripts intentionally do
NOT have access to everything the routers could deliver to.
You could restrict them to a specific and shorter list of allowed
destinations... not necessarily including remote destinations.
YMMV
Bill Hacker
> Thanks.
>
>
