Spam fighting with Postfix and SpamAssassin.

  • Blueforce
  • 06/20/07
  • Offline
Posted: Fri, 2007-09-21 20:04

Hi there!

Does anybody have a good guideline on how Postfix and SpamAssassin should be configured for ultimate spam fighting?

Postfix has lots of settings and I don't know if our system is configured for best spam fighting. Our server is only hosting 40 domains and 200+ mail accounts. I think SpamAssassin is taking care of about 500-2000 spam every 24 hours, total for all mail accounts, still there are many spam mails that just slips thru each day (usually 5-20/account). We also have many backscatter mails with forged from addresses and/or HELO information, and I know there are header and body checks that can stop this, but I donâ


Re:Spam fighting with Postfix and SpamAssassin.

  • Blueforce
  • 06/20/07
  • Offline
  • Sun, 2007-09-23 17:03

Joe or Jamie, Do you have any suggestions about this?

I really would like to know how to add header and body checks for these backscatter emails.

Regards, Leif


Re:Spam fighting with Postfix and SpamAssassin.

  • PlayGod
  • 09/14/07
  • Offline
  • Sun, 2007-09-23 17:19

Still, it would be nice to understand how it all works, because it is essentially what the outsource is doing (Postfix + clamd + spamassin), only the outsource is working on a massive scale with 10 million + end users.


Re:Spam fighting with Postfix and SpamAssassin.

  • Blueforce
  • 06/20/07
  • Offline
  • Wed, 2007-09-26 08:37

Hi Joe,

I have been trying to figure out how these rules should look, but not yet got them to work.

Our server identify it self as server1.indecta.se Any help here would be appreciated.

Regards, Leif


Re:Spam fighting with Postfix and SpamAssassin.

  • PlayGod
  • 09/14/07
  • Offline
  • Sun, 2007-09-23 17:13

After processing email for many years using clamd and spamassassin, and seeing the spammers always seem to stay one step ahead, or have automated incremental changes to their attacks, we finally outsourced to one of the leading anti-spam/virus filtering services for a small per-address fee (we resell it for about 4x what we pay). We also resell it as a store-and-forward option for domains that we don't host, or for customers who are running in-house Exchange servers.

After a 30-day free trial with the outsourced solution, none of our customers have balked at the per address fee. If it saves them 5 minutes per month, it has paid for itself.

Our main justification: it takes a huge load off the web servers. We still have some customers who don't want to pay the fee, and prefer to use spamassassin... we explain to them that spamassassin creates huge files, and be prepared to pay more in terms of site performance, bandwidth and disk space if they don't go with the outsourced solution. With the one we use, the MX records all point to the outsource, so we don't have to deal with email until after it has been run through the filtering.

It sounds like a cop-out, but this was a decision based on having an overloaded NOC and a couple of frustrated sysadmins. We offload the majority of that bandwidth, process, storage etc. to the outsource and we concentrate on keeping our customers happy. As much as we'd like to remain open-source, certain services are worth paying for, and this is one.

We are looking at other solutions, including an anti-spam appliance for the NOC, and other outsourced MX filtering services... but we don't plan to use spamassasin and clamd for our own domains or close customers. Whenever I sell a website development project, I strongly push the outsourced spam/virus filter. Most folks understand the need.

I have used spamamassin on several sites prior to working in my current job, where all of my hosts are on my LAN and in my NOC. I can tell you that, on boxes where there are several hundred virtual domains and most are running spamassasin, the server loads during spam attacks get quite high, and last week we had an older server running cpanel where the bayes files for one domain went over the domain's quota and created a loop that completely overloaded the server (8.0+), due to the process not being able to write.

When a user is at or near the full disk quota and they have bayes_token enabled, this can cause a condition where the spamd will run out of control and the bayes_token files will become corrupt for that user.

ref: http://tinyurl.com/35r4e9


Re:Spam fighting with Postfix and SpamAssassin.

  • Blueforce
  • 06/20/07
  • Offline
  • Sun, 2007-09-23 19:39

Hi PlayGod,

Thanks for your reply! I know there are several outsourced solutions for this, but I don't think that is the solution for us. Postfix, Spamassassin and ClamAV is actually doing a great job as it is now, although I think there are things that could be more "fine-tuned" in the settings.

When searching for recommendations and preferred settings for Postfix and SpamAssassin there are lots of documentation and "recommendations" out there... But I don't have enough knowledge to get all things running the way I want, for example the backscatter header and body checks, I can't to get it to work :-(

Hopefully there are some more experienced persons that are willing to share some of there knowledge to me.

I'm aware of the quota that SpamAssassin needs to be able to run, and that have not been a problem, our smallest mailboxes have 50mb quota. Anyway, thanks for pointing it out!

Regards, Leif


Re:Spam fighting with Postfix and SpamAssassin.

  • Joe
  • 10/23/08
  • Offline
  • Mon, 2007-09-24 15:07

So, spam is a hard problem. ;-)

Backscatter is a bit easier, but is very specific to your environment. You need to know what your mail server announces itself as, so that you can block stuff that claims to be yours but really didn't come through your system.

The Postfix backscatter HOWTO covers most of the common cases--but it's not generic (and can't be), so maybe it isn't obvious how to apply these kinds of rules). The HOWTO is here:

http://www.postfix.org/BACKSCATTER_README.html

To put those into practice, we'd want to know what your mail server calls itself on outgoing mail. From there, we can begin thinking up rules that will deny incoming mail that bounced that was really from some other server.