Spamassassin not strong enough?

[BasicArtStudios]

Hello to you,

recently i updated my Spamassassin/Qmail-scanner/Clam-AV to the latest. So far it's running great, but i noticed it's leaving through a lot more spam than before. Did the rules change in anyway? Or do i have to configure some files i do not know... I left my original configuration in /root/.spamassassin rating with 5.1 Points and my /etc/mail/spamassassin/local.cf seems to be okay.

I saw in the headers some of the spam-files are rated negatively. How can that happen?

I know, that's a lot of questions in one post, but i don't know how to go on with this problems, the customers already start to notice that there's is arriving more spam.

Thanks for any help and tipps.

Greetings,

David


Ooops: Wrong Forum... Sorry

[scott]

The bayes db from spamassassin 2.0 is not compatible with 3.0, you'll need to consult the SA docs on converting it. Thats probably why the accuracy has decreased

[BasicArtStudios]

I looked for the bayes_seen and converted the database with

sa-learn --sync --dbpath /home/qscand/.spamassassin

Thanx!

[whatevah]

Ok, not exactly a timely response, but...

I know it's frowned upon by some sysadmins, but I'm a fan of using DNSBLs for blocking spam.

Also, since I know that no legit emails will be coming to my server from Russia, Korea or China, they are all in my iptables, being blocked from port 25. That took a huge chunk out of the daily spam traffic.

If you have PSA 6 (the only one I'm familiar with), you can configure the email server to query a DNSBL. It's an option marked "MAPS" or something like that in the Server Tab, then Mail in the PSA 6 server admin interface. For me, the one that works best is "bl.spamcop.net". It's set up as the primary blacklist for my system. the few that get past it get caught by "sbl-xbl.spamhaus.org". So, the spamhaus list may be more accurate, but I don't know, since spamcop blocks the rest before spamhaus has a chance to. Before employing them in the server tab, you should check their websites to see their blocking policies, and try them out in spamassassin with a low score for testing.

Another method that works great on killing "zombie" systems from sending you spam and viruses is "greylisting". Scott used to have an rpm for "qgreylist" in one of his yum channels, I don't know if he still does. I installed it a while ago, and customized the settings for my own needs. It works by telling any new incoming connections to try again later, and then closing the connection. Because most viruses and spam zombies don't support the proper SMTP protocols, they won't retry sending the email. But, real email servers will try again in a few minutes. The first connection attempt is logged, and if it connects again after the minimum limit set in qgreylist, it'll allow the email to be sent, and add it the list of authorized servers for a set time period (at least a week, I forget the length). This won't stop the professional spammers using tons of mail servers, but it does stop a lot of them.

I don't even have spamassassin installed anymore, I don't need it, thanks to the methods above. I got tired of having spamassassin wasting all that memory and cpu time on spammers.

[scott]

I think I read somewhere that china is the source of about 80% of all the worlds spam these days, so while draconian, its pretty effective.

I still have the greylisting rpm in the rh9 channel, but I discovered that some MTA's, like Lotus Notes for example, cant handle SMTP temporary failures and it drops the mail. (Basically establishing that Lotus Notes sucks...). In addition you've also got a delay introduced in recieving mail which could cause mail in some cases to take a whole day to deliver. It was damn effective though, it also stopped hordes of email virii. I did a one day comparison on one of my PG servers and it stopped nearly 7000 of the average 9000 spams that system got per day. So lots of pros and cons with greylisting. I personally stopped using it for the Lotus Notes reasons, but I wish I could put it back up.

[whatevah]

I configured my install to set the minimum delay to 2 minutes.

Code: Select all

# how long, after 1st seening an ip address, is it kept on the greylist
my $greytime = 2 * 60;
# how long, after seeing an ip address once, before is it forgotten about
my $maxageonce = 6 * 60 * 60;
# how long, after seeing an ip address several times, before it is forgotten about
my $maxagegood = 10 * 24 * 60 * 60;

I noticed that some valid systems would retry in under 5 minutes, so I didn't see the point in having a 10 minute minimum delay. Especially since I haven't seen any zombies retry, at all.

As you can see, if an external mail server sends my server another email within 6 hours of sending the first email, it'll be added to the approved list for 10 days. So, for at least 10 days, only the very first email sent will be delayed.

Of course, this doesn't stop the professional spammers like Scott Richter and most of the others on the ROKSO list, but it does provide a wonderful means to stop the zombie systems acting as bots for some the spammers. And, of course, all those automated viruses.