Hi folks,
I've spent a lot of time tuning our spamassassin setup over the
years. Channels, RBLs, pyzor, DCC, bayes, KAM rules, some home spun
rules, etc... and things do work fairly well, the rate is very high ,
but the ones that get through are the ones that are designed to get
around the defenses before they are shutdown. I get the feeling the
scores from many rules are too low, and I'm looking for the right way to
move forward.
The reason I say this is because I've got a spamtrap account, which is
comprised of several addresses that are heavily targeted by spam lists,
and these accounts seem to get the fast flux, rapid zone updates and ip
reputation burns (and other techniques) that are used to do initial spam
flooding before they are picked up by things. Once pyzor, dcc, and the
RBLs pick these up, they are usually scored high enough to get flagged
for everyone else, but without the RBLs, the scoring is too low to meet
that[0]. Of course I "learn" these messages when they come in.
I've been trying to analyze which are the techniques they use to try and
come up with rules that will stop them, but so far they are hard to come
up with something manually. i've taken several of these that got through
and later, after a day, checked them with network tests, and they are
all scored very high by the various lists, fuzzers, and checksums. Often
you will see these don't even hit rbls... but the ones that do, aren't
hitting enough of them to catch them... however usually, if an rbl is
hit, then it gets marked as spam, as most of the times several of the
RBLs all fire at once... but if they are not on rbls, they don't get
flagged as spam by the regular rules.
So, what can I do to tweak these rules to score things up more,
specifically the rules that provide a low false positive rate[1]. This
seems something that should be done programmatically, and not
manually. It seems like what 'masscheck' maybe does generically for all
rules for all installations, but can I use that to just adjust our rules
for our particular breed of spam that comes through?
Thanks for any ideas,
micah
0. with some notable exceptions, like KAM_DMARC_REJECT and
HELO_DYNAMIC_SPLIT_IP
1. like KAM_DMARC_STATUS, HTML_NO_CHARSET are possible ones, or mails
that do not have a To: have a score of 0.1
--
micah
I've spent a lot of time tuning our spamassassin setup over the
years. Channels, RBLs, pyzor, DCC, bayes, KAM rules, some home spun
rules, etc... and things do work fairly well, the rate is very high ,
but the ones that get through are the ones that are designed to get
around the defenses before they are shutdown. I get the feeling the
scores from many rules are too low, and I'm looking for the right way to
move forward.
The reason I say this is because I've got a spamtrap account, which is
comprised of several addresses that are heavily targeted by spam lists,
and these accounts seem to get the fast flux, rapid zone updates and ip
reputation burns (and other techniques) that are used to do initial spam
flooding before they are picked up by things. Once pyzor, dcc, and the
RBLs pick these up, they are usually scored high enough to get flagged
for everyone else, but without the RBLs, the scoring is too low to meet
that[0]. Of course I "learn" these messages when they come in.
I've been trying to analyze which are the techniques they use to try and
come up with rules that will stop them, but so far they are hard to come
up with something manually. i've taken several of these that got through
and later, after a day, checked them with network tests, and they are
all scored very high by the various lists, fuzzers, and checksums. Often
you will see these don't even hit rbls... but the ones that do, aren't
hitting enough of them to catch them... however usually, if an rbl is
hit, then it gets marked as spam, as most of the times several of the
RBLs all fire at once... but if they are not on rbls, they don't get
flagged as spam by the regular rules.
So, what can I do to tweak these rules to score things up more,
specifically the rules that provide a low false positive rate[1]. This
seems something that should be done programmatically, and not
manually. It seems like what 'masscheck' maybe does generically for all
rules for all installations, but can I use that to just adjust our rules
for our particular breed of spam that comes through?
Thanks for any ideas,
micah
0. with some notable exceptions, like KAM_DMARC_REJECT and
HELO_DYNAMIC_SPLIT_IP
1. like KAM_DMARC_STATUS, HTML_NO_CHARSET are possible ones, or mails
that do not have a To: have a score of 0.1
--
micah