[BALUG-Admin] anti-spam ...

[Rick Moen]

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.