Quoting Michael Paoli (Michael.Paoli@cal.berkeley.edu):
Yes, ... a pretty good rule set, albeit quite aggressive. Did already tweak fair bit on configuration earlier ... I'm sure there will be occasional items (notably false positives) that come up. Fortunately thus far they've been pretty few, but yes, will need to deal with those - at least as feasible and appropriate.
The same is true of SpamAssassin's rulesets. And there's a point about that, that I'll return to below.
But yeah, some of the other email addresses (and ISPs, etc.) I have ... sometimes I look over the spam for sending domains, and for those I've never ever yet seen any non-spam use of, rather than block 'em outright, I just tighten the screws a bit more so spam from such is more probable to not make it through, while leaving it still at least reasonable for legitimate email (should there ever be such from such a domain) to reasonably make it through.
Quite a lot of the newer TLDs seem to never originate any non-spam e-mail, I notice.
Another thing I notice ... seems the spammers are learning a bit
Well, yes, but:
... and/or some of eximconfig's database tracking - the (attempted) spam volumes seem to be trending down from earlier ... probably started out as "ooh, fresh meat, let's see if we can spam there" - or so the spambots would behave ... but weeks later, perhaps more like: "uh, ... that's a harder target ... let's not spend quite as much resource trying on that one".
My best guess is that this will prove to be, in part, a perceptual illusion on your end.
What's definitely true is that an IP that gets newly deployed as an MTA host sees a ramp-up of spam delivery attempts as its presence on spammers' lists of known MTA IPs gets sent around.
The part that I greatly _doubt_, based on everything I've read about spammers, is any IP-specific learning effort. Why do I say this? Because spammers' byword is always 'We do lots of dumb things, but we make it up in volume.' After all, they're mostly using stolen machine resources (malware-driven host compromise) and stolen bandwidth, so they don't perceive a payoff from concentrating on specific target IPs. This is why even simple spam defences tend to work pretty well, even ones that are easily defeated with human attention, because spammers don't lavish human attention on any specific target. It's more remunerative to just hammmer IP space.
Which brings me to my point: Although spammers themselves are characteristically really stupid, the people who construct their toolsets are not. And among the many things the latter people do is test mass-mailings against standard antispam toolsets, e.g., a bog-standard, uncustomised installation of SpamAssassin. If the normal spamicity cutoff score in SpamAsssassin is 5.0 (which IIRC it is), then spam toolset makers provide point'n'drool methods for their slackjawed customers to ensure that spam they sent out measures no higher than 4.8.
_Therefore_, local tweaks to the SpamAssassin rulesets are A Good Thing. You want your setup to be absolutely _not_ the same as everyone else's. Diversity of target, avoidance of an antispam monoculture, is a positive benefit.
I've tweaked a number of the constituent SA rules, and also lowered the cutoff score to 4.0 after testing. But you[-generic] need to also remember to occasionally check for significan false positives (as I'm sure you do), because things can change.
I vaguely recall that I messed up by not putting custom SA ruleset weightings into a site-specific local.cf file, which means one day I'll need to go find all the local tweaks I made in /usr/share/spamassassin/* files, where they are at risk of getting overwritten by upgrades.