Spam Filter Refining

Forum: LinuxTotal Replies: 7
Author Content
techiem2

Apr 28, 2008
10:18 AM EDT
Ok, here's the deal. Our school gets about 17k messages a day, mostly spam of course. Apparently about 10k or so are getting caught by the system (amavis/spamassassin) which means @7k are still getting through. We are trying to figure out what we could do to trim things down more. We have tried reverse DNS (which worked great), but apparently a good number of places the faculty/staff needs contact with don't know how to configure their DNS properly so all their messages were getting dropped (i.e. they are probably running windows servers and left them the stock config or some such). Any suggestions? The only thing I can come up with off the top of my head would be to examine the spam and add some custom spamassassin rules (we've already added a couple).

Any suggestions?

Thanks!
herzeleid

Apr 28, 2008
10:51 AM EDT
Sanity checks up front are useful for saving spamassassin cycles and improving the overall signal to noise ratio of the incoming mail flow.

We use a number of sanity checks such as not accepting mail from invalid/nonexistent domains, and a couple of good realtime blacklists. We'd moved those checks to spamassassin, but recently we've had to re-enable some of the RBL checks up front just to keep the incoming volume to a manageable level. (zen.spamhaus.org is a good one)

The other sanity checks include greylisting (some spammers have begun to figure this out, but it's still useful), helo blacklisting, spamtrap and other features that are included in policyd, the postfix policy daemon. http://policyd.org/features.html
NoDough

Apr 28, 2008
10:54 AM EDT
Look into greylisting. It stops between 20 and 30 messages per second at my firewall. [Edit] Actually, it and RBLs stop that number.

In simple terms, greylisting does this...

- An unknown host initiates an SMTP connection. - The firewall verifies that it has not seen this host before. - Having not seen the host before, the firewall asks the host to defer the connection (i.e. come back later.) - If it's a valid SMTP server, it will come back later as asked and the message will be delivered. - If it's a spammer, it won't bother coming back. It's wasted enough time with you already.

That's about it and it's very effective.
techiem2

Apr 28, 2008
11:17 AM EDT
I think we have greylisting enabled. We have spamassassin using razor2, pyzor, dcc. policyd looks useful. Would it integrate into the postfix/amavisd setup? It looks like we are rejecting mail from invalid hostnames in postfix.

How do I look to see if it's using the spamhaus rbl (and add it if it's not)?
NoDough

Apr 28, 2008
11:22 AM EDT
We check against the following lists...

bl.spamcop.net zen.spamhaus.org cbl.abuseat.org dul.dnsbl.sorbs.net list.dsbl.org
techiem2

Apr 28, 2008
1:22 PM EDT
Well, I discovered that SA's trusted_networks wasn't set so it was getting confused with our network and defaulting to adding the (ALL_TRUSTED -1.44) flag to pretty much every email going through. So we've fixed that. Hopefully that will make more of the relayed spam get caught instead of passed through.
herzeleid

Apr 28, 2008
1:23 PM EDT
> policyd looks useful. Would it integrate into the postfix/amavisd setup?

That's how we're using it - policyd, postfix, amavisd, sa etc

> How do I look to see if it's using the spamhaus rbl (and add it if it's not)?

The relevant section of my main.cf looks like this:

smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_sender_domain, reject_unknown_recipient_domain, reject_non_fqdn_sender, reject_unauth_destination, check_recipient_access hash:/etc/postfix/recipient_bypass check_sender_access hash:/etc/postfix/sender_bypass check_policy_service inet:192.168.111.2:10031 check_recipient_access hash:/etc/postfix/access, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, permit

techiem2

Apr 28, 2008
3:00 PM EDT
Ok. Thanks. I'll look into those tomorrow. Spam must DIE! hehe

You cannot post until you login.