Hello,
Being tired of the vast amount of spam on certain catch-all domains
that started appearing just a few months ago, I've changed the MX
server and started using milter-greylist-4.0 on a FreeBSD-based VDS
with 64MB RAM, only to find out that in a matter of about one day, the
milter stopped running, causing a huge spike of spam since this VDS
didn't have any IP or domain-based REJECTs in /etc/mail/access that my
older MX had (and still has).
I've found out that the size of greylist.db was about 15MB, after
greylisting _one_ catch-all domain for _less than a day_. (The number
of non-spam messages on this specific domain is no more than 30 a day,
the number of spam messages can now easily be way more than 3000
messages a day if no filtering is done.)
Trying to keep it longer than this, I've blocked two NICs in
/etc/mail/access, and tried limiting the time during which the
greylisting tuples are stored (from milter-greylist-4.0 default of 5
days to a few hours).
However, I've also noticed that many greylisting entries share the
same IP-address. I've tried playing with 'rcptcount', and it might
have had some effect, although it also appears that 'msg' from an
rcptcount rule is _always_ being superseded by some other greylisting
rules, e.g. the 'msg' from the 'rcptcount' example in greylist.conf(5)
is very unlikely to be ever displayed, even when the rule itself is
engaged.
Anyhow, with these changes, I've removed the old greylist.db and
started milter-greylist once again last night, only to find out that
it's no longer running as of this morning, and a new 4.5MB
greylist.db.
root@mojo:/root# wc -l /var/milter-greylist/greylist.db
45641 /var/milter-greylist/greylist.db
0.000u 0.013s 0:00.09 11.1% 0+0k 0+0io 0pf+0w
root@mojo:/root# cat /var/milter-greylist/greylist.db | sed
"s#[[:space:]]*<.*##g" | sort -n | uniq -c | wc -l
1257
0.857u 0.110s 0:06.74 14.2% 10+326k 0+0io 0pf+0w
root@mojo:/root# ll /var/milter-greylist/greylist.db
-rw------- 1 mailnull wheel 4605379 Jul 17 07:09
/var/milter-greylist/greylist.db
0.000u 0.004s 0:00.16 0.0% 0+0k 13+0io 0pf+0w
As you can see, that's an average of 40 tuples per IP-address. In
reality, some of those spammers that target only specific addresses in
my domain, have only one tuple, whilst others, that target random
catch-all aliases, have as many as hundreds of tuples.
root@mojo:/root# cat /var/milter-greylist/greylist.db | sed
"s#[[:space:]]*<.*##g" | sort -n | uniq -c | sort -n | tail -n16
432 82.179.199.195
448 79.109.216.40
448 85.221.237.255
451 85.117.156.45
455 78.152.20.238
456 82.204.245.86
457 87.245.132.22
458 85.103.143.124
462 193.251.0.235
466 85.107.136.14
467 222.124.70.217
469 96.226.56.65
488 89.42.253.244
490 84.10.68.103
493 84.125.22.126
497 92.125.222.194
0.778u 0.065s 0:06.10 13.6% 8+257k 0+0io 0pf+0w
root@mojo:/root#
My understanding is that greylisting was designed to waste their
resources, instead, it appears that they are continue wasting mine.
I thus envision the following feature:
* being able to autoblacklist those addresses that have more than a
certain number of greylisting tuples. When a limit is reached, all
those tuples are removed for a specific IP-address, and the IP-address
is added to the autoblacklist, so that all further attempts won't
generate any more tuples for a specified amount of time
I've also noticed that 'rcptcount' appears to be quite ineffective in
fighting spam. For example, for testing purposes, I 'blacklist' and
'flushaddr' any host that tries to send a message to 3 or more
recipients. In reality, spammers do this with separate transactions,
and my new greylist.db is full of entries with more than two
occurrences of unique ip/from pairs. I'd possibly like a feature for a
more realistic 'rcptcount' implementation.
Any suggestions on how to go about implementing these features, or if
I better try greylisting with qmail or something? I'd use
ports/mail/spamd, but unfortunately this VDS doesn't have PF. :(
Cheers,
Constantine.Message
limit the number of tuples from a single ip-address, then autoblacklist
2008-07-17 by Constantine A. Murenin
Attachments
- No local attachments were found for this message.