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
|
