On Wed, Jan 23, 2019, 12:35 PM Kris Deugau <kdeu...@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.
>
