sysadm wrote:
> Dear exim users
> I'm a newbie with exim, so please ignore my ignorance.
> I'm trying to construct a set-up where I do the RBL reject at the
> incomming SMTP level. In the set up I will also try to do host based
> black/white list reject/accept.
>
> I have created the following, will that do, or have I missed something?
>
IIRC it is the physician's maxim: 'First, do no harm'.
There are two 'classes' of arrival you will want to exempt from
testing:
- any relay_hosts or other 'VIP' collaborators. Not liely to be RBL'ed, but best
to *insure* they have a 'pass'.
- Your own MUA clients connecting and authenticating. These will often come
from (x)dsl/cable/WiFi/dialup, and many such networks are blacklisted,
voluntarily or otherwise.
As to how to 'skip' these past the testing, have a look at:
- authenticated = *
- the effect of 'endpass' on an accept clause to skip over all subsequent
clauses in an acl_smtp_[phase]
- the use of an acl_c/m variable to carry an exemption flag which can be tested
with a conditional at each individual clause.
> #for stopping spam at SMTP level start:
> deny message = rejected because $sender_host_address is in a
> local blacklist of hosts
> hosts = ${if exists {/etc/exim/black-list-hosts} \
> {/etc/exim/black-list-hosts}{}}
>
> deny message = rejected because $sender_host_address is in a
> black list at $dnslist_domain\n$dnslist_text
> dnslists =
> relays.ordb.org:sbl.spamhaus.org:xbl.spamhaus.org:sbl-xbl.spamhaus.org:bl.spamcop.net:\
>
> dnsbl.njabl.org:blackholes.mail-abuse.org:dialups.mail-abuse.org:relays.mail-abuse.org:\
>
> dnsbl.sorbs.net:http.dnsbl.sorbs.net:socks.dnsbl.sorbs.net:misc.dnsbl.sorbs.net:\
>
> smtp.dnsbl.sorbs.net:web.dnsbl.sorbs.net:spam.dnsbl.sorbs.net:block.dnsbl.sorbs.net:\
>
> zombie.dnsbl.sorbs.net:dul.dnsbl.sorbs.net:rhsbl.sorbs.net:cbl.abuseat.org:list.dsbl.org:\
> opm.blitzed.org
> !hosts = ${if exists {/etc/exim/white-list-hosts} \
> {/etc/exim/white-list-hosts}{}}
> #for stopping spam at SMTP level stop:
>
You need only a fraction of those. Some are duplicates, some are hors de combat.
Many of the better ones carry highly similar listings or are even aggregates of
the others.
For a starting point, have a look at the ones SpamAssassin is using at any given
rev level. These are usually troublefree, as SA is a good sized project in its
own right, and changes what it uses as needed to make use of the more effective
ones.
> I have placed it in the top of the ACL just after the acl_check_rcpt: Is
> that the best way to place it?
>
It will work there.
*Wherever* you put it:
- the whitelist check should come first.
- any 'Local' blacklist next
- then the remote callout.
Even if you change the 'deny' to a 'warn' and carry a score forward for later
action, there is no point in making the RBL callout if you already know you wish
to *either* whitelist OR blacklist.
As to 'where':
The earliest you can do IP-based RBL checks is in acl_smtp_connect.
With use of a 'warn' instead of a 'deny', you may carry the results forward for
later use - all the way into the message queu for routers to act on if stored in
an acl_m9x) variable.
BUT: The earliest you can extract per-recipient preferences is in acl_smtp_rcpt.
i.e. - if you have/want to have some addresses that will accept traffic even if
it has hit RBL scores, others that will tolerate one hit, but not two, etc.
AND; The latest you can DO per-recipient rejection with Exim is also in
acl_smtp_rcpt. Once into the DATA phase most MTA can no longer do per-recipient
rejections.
So - yes, you have it in a place where it will work.
> In the white-list-hosts and black-list-hosts files there is one host per
> line. but is it possible to give an entire range of ip address by for
> instance 193.243.4.0/24 or how do i do that ?
>
CAVEAT:
An Exim 'hostlist' and the 'hosts' call that uses such a list OR those you
construct (see 'dsearch') have special rules.
More than just format is involved - 'hosts' can trigger an external DNS lookup
of element in a list (cached, but still...).
There is no point in having Exim do that when you already have the information
to make a pass/block decision on-box. Especially if it is in the LBL because it
*doesn't* return properly.
For some tests, a linear search called by a 'condition =' is more appropriate
than a 'hosts = '. See lsearch and wildlsearch.
Look also at Exim's specialized iplsearch tool for working with IP numbers and
ranges.
Different lookup, comparison, and match tools fit each content type most
effectively, so expect to have more than one whitelist, and more than one blacklist.
Most of all..
- turn your logging verbosity up before you start (log_selector = +all)
- add plenty of 'log_message' and 'logwrite' to acl's when first testing them
- tail or analyze the logs carefully
- use 'warn' first, monitor the effects,
- then switch to 'defer' and monitor some more,
- before cutting over to 'deny' - and monitor the effects of that, too.
HTH,
Bill
