To put things into perspective, on a cPanel installation (or a standalone box) things like DCC / Razor2 / Pyzor / iXhash are not installed. It used to be that the addition of those things really made a huge difference in spam detection versus a typical spamassassin install. Nowadays, even with DCC / Razor2 / Pyzor / ixHash functioning as well as the use of RBLs like Zen / Barracuda, the spam arrives often with spam scores in the 1.x range.
I suspect part of what is going to need to be done is some manual massaging of spam scores for certain rules. If memory serves me correctly, SpamAssassin doesn't even come shipped with the proper DCC.pm module -- it's outdated. So even if you are going to use DCC, you're not using the latest DCC.pm. And you want the latest DCC and you want to configure it properly so that it reports back to the DCC servers when you have spam that is triggering your spam scores. The distributed options really do help out, although not so much these days it seems.
What hurts [from the standpoint of spamassassin on a cPanel server for example] is that user has their own Bayesian database, AWL [if you use it], etc. So a spam run could come in to 1000 of your email users, one spam per user, and it would not tilt heuristics in favor of the spam being spam, whereas if all accounts were using a central Bayesian database and DCC / Pyzor / Razor were acting upon one corpus of data instead of separate data for each user, the detection rates for spam would be quite a bit higher I believe.
I have had SpamAssassin 3.4 installed on multiple standalone mail filtering boxes, and it made absolutely no appreciable difference in spam detection itself. The rules and methods used in 3.4 appear to be no more aggressive or effective than in previous versions. So nobody should get their hopes up that a simple change to spamassassin 3.4 will resolve their spam issues.
I know ConfigServer's product uses a central Bayesian database, or at least I believe it does, which likely allows spam detection in that environment to be better. Of course they also use all of the distributed plugins that aren't installed by default on a cPanel box. That combination makes it more effective. With that said, I've heard reports that Mailscanner users are experiencing similar issues with the increase in spam.
Bottom line is that spammers make a lot of money and thus have the motivation and resources to stay one step ahead of the game. It has always been like that. Nowadays the spammers are (a) performing single short spam runs (usually of high volume) from particular IP space and then moving on to other IP space to spam from, (b) making sure that the IP space they are using doesn't have a bad reputation to begin with, (c) are using all of the authentication methods of today, such as DKIM, DomainKeys, SPF/SenderID, DMARC. So you find that the spam runs occur from particular IP space that is not blocked by any of the common RBLs (like Zen or Barracuda). By the time the RBLs add the IP space [if they even do], the spammers are no longer using that IP space to spam from or won't be using it again for days or weeks. They might keep that IP space and spam from it again days or weeks later, but they don't do it often enough to get into an RBL long term and they spam in short [but very effective] bursts when they do use the IP space in order to remain off of the RBLs.
I really suspect the only way to fight this battle using generic free software like Spamassassin is to use it in a distributed fashion [with all of the distributed mechanisms properly configured and reporting back to servers] as well as using a single Bayesian database instead of per-user ones and massaging default spam scores in key rules for things like DCC / Pyzor / Razor2.
M
