Re: [Sqlgrey-users] False Positives

[Lionel B. <lio...@bo...>]

Wayne Spivak wrote:
> I've been running SQLGREY 1.7.5 for several weeks.
>
> My database contains 65K connects, 266 domain_awl and had 14K from_awl
> entries.
>
>   

These numbers mean that greylisting probably blocks most of the SPAM on 
your configuration. I'd be worried if from_awl entries exceeded connect 
entries.

> Looking thru the from_awl entries, there were way too many false positives.
>
>   

I'm not sure what "false positives" are. SPAM sources in the 
auto-whitelists are obviously expected if they are mail servers and not 
basic spam bots. How is having too many "false positives" a problem for 
you? Usually SQL databases handle millions of entries quite easily...


> Is there a way to tighten the whitelisting criteria.
>   

Not much, you can have reconnect_delay set to a higher value if you 
suspect that many spam bots are always reconnecting only once after a 
known delay (setting reconnect_delay above this known delay will prevent 
them to get through), but it will obviously delay legit mails that don't 
match the whitelists. The awl_age can be set lower to clean up the awl, 
but if the servers in the whitelists could get through the first time, 
there's no reason they won't be able to later.

If the spammers use a real mail server, greylisting alone can't protect 
you. If you don't already you should use a safe blacklist (I'd recommend 
sbl-xbl.spamhaus.org) in combination with greylisting :
- if you use it before greylisting it will avoid too many entries in 
auto whitelists but will add more load on the mail servers (greylisting 
is usually much faster than querying RBLs),
- if you use it after greylisting you'll get the same number of entries 
in auto whitelists than without it but the load on your mail server will 
be lower and the load on your database higher.

You'll get the same level of SPAM protection from both.

Lionel