On 1 Nov 2016, at 20:31, Alex wrote:
Hi,
On Mon, Oct 31, 2016 at 9:11 PM, Bill Cole
<sausers-20150...@billmail.scconsult.com> wrote:
On 31 Oct 2016, at 20:38, Alex wrote:
Hi all,
We keep receiving variations of this dropbox phish that's never
tagged
properly. I was hoping someone had some ideas for catching them.
I've added a few more body rules, and some header rules to block
this
"drpbox" spelling variation, but I hoped someone had some better
ideas
to block them before they're received...
http://pastebin.com/7PQgEsrJ
The domains in the body still aren't blacklisted anywhere, and the
IPs
are on more whitelists than otherwise.
Well, I find this quite useful with very few false positives:
uridnsbl URIBL_SBLXBL sbl-xbl.spamhaus.org. TXT
body URIBL_SBLXBL eval:check_uridnsbl('URIBL_SBLXBL')
describe URIBL_SBLXBL Contains a URL listed in the SBL/XBL
blocklist
tflags URIBL_SBLXBL net
score URIBL_SBLXBL 7
This check will FP after a fashion when a nominally legitimate
webserver
lands on the CBL because it is infected with something. I see that as
not a
FP at all but some may disagree.
Your sample directs recipients to an URL whose domain name resolves
to an IP
that has been pon the CBL for over 30 hours straight.
Is this not already in 25_uribl.cf?
Not in the one sa-update fetched for me today... It is however given as
an example in the Mail::SpamAssassin::Plugin::URIDNSBL pod/man with the
explicit 'ns' tflag, which is a bit of a surprise to me. My local.cf
comments imply that I added it at the suggestion of a wise colleague
many years ago (circa SA 3.2.)
You believe this is more effective, and safer than a check_rbl_sub()
SBLXBL call on the header?
I believe it is entirely orthogonal to that test, although I don't
expect there's many SBL/XBL listees in headers unless one does not use
Zen ahead of SA (which I suppose some people probably do not...)
