You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Ian Evans <dh...@gmail.com> on 2019/01/23 03:49:46 UTC
Do I still need these old spamtips.org rules in local.cf?
Several years ago I added a bunch of rules to my local.cf that I picked up
from spamtips.org. That was back in the days of Spamassassin 3.3.2, about
2012.
Just curious, six years later, if it's worth keep any of these rules or
whether their functionally has been rolled into or supplanted by later
releases. These are the rules:
##### Reputation compensations
# Definitions
header __RCVD_IN_MSPIKE_Z eval:check_rbl_sub('mspike-lastexternal',
'^127\.0\.0\.2$')
describe __RCVD_IN_MSPIKE_Z Spam wave participant
tflags __RCVD_IN_MSPIKE_Z net
header RCVD_IN_MSPIKE_L5 eval:check_rbl_sub('mspike-lastexternal',
'^127\.0\.0\.10$')
describe RCVD_IN_MSPIKE_L5 Very bad reputation (-5)
tflags RCVD_IN_MSPIKE_L5 net
header RCVD_IN_MSPIKE_L4 eval:check_rbl_sub('mspike-lastexternal',
'^127\.0\.0\.11$')
describe RCVD_IN_MSPIKE_L4 Bad reputation (-4)
tflags RCVD_IN_MSPIKE_L4 net
header RCVD_IN_MSPIKE_L3 eval:check_rbl_sub('mspike-lastexternal',
'^127\.0\.0\.12$')
describe RCVD_IN_MSPIKE_L3 Low reputation (-3)
tflags RCVD_IN_MSPIKE_L3 net
# *_L and *_Z may overlap each other, so account for that
meta __RCVD_IN_MSPIKE_LOW RCVD_IN_MSPIKE_L5 || RCVD_IN_MSPIKE_L4 ||
RCVD_IN_MSPIKE_L3
meta RCVD_IN_MSPIKE_ZBI __RCVD_IN_MSPIKE_Z && !__RCVD_IN_MSPIKE_LOW
# Scores
score RCVD_IN_MSPIKE_ZBI 4.1
score RCVD_IN_MSPIKE_L5 4.1
score RCVD_IN_MSPIKE_L4 3.5
score RCVD_IN_MSPIKE_L3 2.9
# SMF Brackets
header SMF_BRACKETS_TO To:raw =~ /<<[^<>]+>>/
describe SMF_BRACKETS_TO Double-brackets around To header address
score SMF_BRACKETS_TO 1.5
score URIBL_BLACK 0
score URIBL_RED 0
score URIBL_GREY 0
score URIBL_BLOCKED 0
Thanks for any advice.
Re: Do I still need these old spamtips.org rules in local.cf?
Posted by Ian Evans <dh...@gmail.com>.
On Wed, Jan 23, 2019, 12:35 PM Kris Deugau <kdeugau@vianet.ca wrote:
>
> The Mailspike DNSBL was added to SA upstream, so aside from custom
> scores you may want to keep, the base rule definitions are no longer
> useful in a third-party ruleset.
>
> For my part, I found there was little benefit to them in the SA cluster
> I maintain at work. We would have had to pay for a datafeed, but the
> additional hits didn't result in very much more spam getting caught.
> They're probably worth keeping on smaller systems where the additional
> cost is basically just the extra DNS lookup(s).
>
> > # SMF Brackets
> > header SMF_BRACKETS_TO To:raw =~ /<<[^<>]+>>/
> > describe SMF_BRACKETS_TO Double-brackets around To header address
> > score SMF_BRACKETS_TO 1.5
>
> Don't recall having seen anything that would match this in a while, but
> give it another couple years and some spammer will try it again...
>
> > score URIBL_BLACK 0
> > score URIBL_RED 0
> > score URIBL_GREY 0
> > score URIBL_BLOCKED 0
>
> This essentially disables the uribl.com DNSBL lookup (mostly, don't
> recall all the subrules offhand).
>
> Again, at work I can't justify the datafeed cost we'd pay for the small
> increase in catch rate.
>
> I'd recommend removing these disabling score entries and seeing if a)
> your spam catch rate improves and b) if you start to hit URIBL_BLOCKED.
> If you've been hitting URIBL_BLOCKED, you're either using a shared DNS
> cache ("Don't Do That"), or your mail volume is high enough that you
> need to pay for a datafeed. As of last time I checked you can get rough
> pricing if you create and log in to a web portal account on uribl.com;
> it's a bit unfortunate that they don't make it more accessible.
>
> -kgd
>
Thanks so much for your advice.
>
Re: Do I still need these old spamtips.org rules in local.cf?
Posted by Kris Deugau <kd...@vianet.ca>.
Ian Evans wrote:
> Several years ago I added a bunch of rules to my local.cf
> <http://local.cf> that I picked up from spamtips.org
> <http://spamtips.org>. That was back in the days of Spamassassin 3.3.2,
> about 2012.
Old rules aren't inherently bad, but they do need review now and them to
see if they're still worth keeping.
> Just curious, six years later, if it's worth keep any of these rules or
> whether their functionally has been rolled into or supplanted by later
> releases. These are the rules:
>
> ##### Reputation compensations
> # Definitions
> header __RCVD_IN_MSPIKE_Z eval:check_rbl_sub('mspike-lastexternal',
> '^127\.0\.0\.2$')
The Mailspike DNSBL was added to SA upstream, so aside from custom
scores you may want to keep, the base rule definitions are no longer
useful in a third-party ruleset.
For my part, I found there was little benefit to them in the SA cluster
I maintain at work. We would have had to pay for a datafeed, but the
additional hits didn't result in very much more spam getting caught.
They're probably worth keeping on smaller systems where the additional
cost is basically just the extra DNS lookup(s).
> # SMF Brackets
> header SMF_BRACKETS_TO To:raw =~ /<<[^<>]+>>/
> describe SMF_BRACKETS_TO Double-brackets around To header address
> score SMF_BRACKETS_TO 1.5
Don't recall having seen anything that would match this in a while, but
give it another couple years and some spammer will try it again...
> score URIBL_BLACK 0
> score URIBL_RED 0
> score URIBL_GREY 0
> score URIBL_BLOCKED 0
This essentially disables the uribl.com DNSBL lookup (mostly, don't
recall all the subrules offhand).
Again, at work I can't justify the datafeed cost we'd pay for the small
increase in catch rate.
I'd recommend removing these disabling score entries and seeing if a)
your spam catch rate improves and b) if you start to hit URIBL_BLOCKED.
If you've been hitting URIBL_BLOCKED, you're either using a shared DNS
cache ("Don't Do That"), or your mail volume is high enough that you
need to pay for a datafeed. As of last time I checked you can get rough
pricing if you create and log in to a web portal account on uribl.com;
it's a bit unfortunate that they don't make it more accessible.
-kgd