Re: [exim] exim_surbl

John Schmerold wrote:
> That, of course is one of the reasons I wrote, I suspect we could do
> better. An obvious area for our situation is to deny based on
> recipient email address (if we don't exist, why are we accepting mail
> for them).
>

That IS a big one, yes...

> This box is a filter for several clients using mail servers that
> include Exchange, cPanel, Groupwise & Vmailmgr, so configuring
> recipient addresses is easier said than done.
>

But well worth it...

We use a single DB instead of a complex verify-mode router-walk.

Arguably less efficient to do an SQL call than walk Exim routers, BUT - there is
just ONE place to look or 'maintain' (even 'postmaster' has an entry there, as
do our valid MLM input addresess).

..and there are *many* ways to grab the data from all manner of disparate input
sources and formats and suck it into the DB.

> We're using several (probably too many) rbls, that helps, guess
> greylisting is next.
>

BT, DT, GGTS.

But a simple 15-second delay whenever a 'fault' is hit (else NOT) has been just
as effective, and with no discernable delay on decent traffic..

Seems a goodly number of 'modern' zombots are programmed to not waste 'their'
time on recalitrant victims....

W/R rDNS fail, HELO mismatch, RBL 'hit', header format and mime faults -
generally too much 'falsing' if used as pure go no-go.

Instead, you can give these each weighted 'demerit' scores based of severity,
carry them about in bespoke and/or cumulative acl_c(n), transfer to acl_m(n), do
gt/lt/eq testing against system-wide, per-domain, or per-user tolerance levels.

HTH,

Bill