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

Reply via email to