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? You believe this is more effective, and safer than a check_rbl_sub() SBLXBL call on the header? header RCVD_IN_XBL_ALL eval:check_rbl_sub('zen', '127.0.0.[45678]') describe RCVD_IN_XBL_ALL Received via a relay in Spamhaus SBL-XBL tflags RCVD_IN_XBL_ALL net score RCVD_IN_XBL_ALL 0.01