Auteur: W B Hacker Datum: Aan: exim users Onderwerp: Re: [exim] Blacklisting/Whitelisting reverse DNS domain names
Brian Spraker wrote: > I've got another funny one going on here after changing over to MySQL lists
> instead of flat files.
>
> When I blacklist a reverse DNS domain name, it works - but whitelisting will not
> work.
>
> In essence - here is what I'm doing. When my server checks the reverse dns on
> the IP address of the connected party, it will return the reverse dns (of
> course).
>
> I then run the reverse DNS through a check to see if it is either whitelisted or
> blacklisted. Whitelist checks always come first.
>
> As an example, I entered "*il.comcast.net" into my blacklist. I then telnet
> into the mail server from an IP with a reverse dns of bla-bla.il.comcast.net, it
> works and informs me that my reverse DNS domain has been locally blacklisted
> (which is the message I want it to say).
>
> Blacklist ACL:
>
> hosts = ${lookup mysql{SELECT domain FROM exim_domain_blacklist }}
>
> Very simple and it works.
>
> HOWEVER, I then add "*il.comcast.net" into my whitelist table - and it fails to
> allow me to complete the SMTP mail. Since whitelist is checked first, it should
> skip right over the blacklist ACL (which is what occurs when I check host IP,
> sender domain, and sender e-mail address in other ACLs).
>
> Whitelist ACL:
>
> hosts = ${lookup mysql{SELECT domain FROM exim_domain_whitelist }}
>
> Very simple and exactly the same as the Blacklist ACL - except the different
> table.
>
> So why would the blacklist work - but the whitelist doesn't?
>
> Thank you all.
>
> Brian S.
> BsnTech Networks
>
>
>
>
>
Not quite enough information, but here's where to look:
- WHEN the 'action' triggered by an acl 'hit' (SQL or otherwise) is 'final'
(deny class verb) the connection goes away and no further acl's are traversed.
That's a 'hard fail' or 'no second chance' blacklist. Yours seems to be such,
but not all are.
A whitelist hit, OTOH, is seldom 'final'. You may whitelist on arrival IP, OR
port and protocol in the CONNECT phase, reinforce later with successful AUTH,
yet still wish to deny on a ClamAV WinCrobe hit in the DATA phase, for example.
Ergo, in addition to whitelisting at CONNECT, you need to either force skipping
of ALL subsequent clauses within each smtp phase, (see 'endpass')...
... ELSE carry some form of 'token' going forward, such as a value or flag in an
acl_c variable, AND have each of those subsequent clauses test said flag, apply
or skip each of its test(s). Copied frm an acl_c to an acl_m, that flag can live
all the way through DATA phase, be written into the queue, and be available for
router/transport decisions.
While it isn't rocket science to craft an SQL call that does both white/black
tests (and more) within a single acl clause, you will almost certainly want to
make more tests, many of them not SQL related, so a flag is more flexible.
