Bug 6080 - new rule: RCVD_IN_SSBL
Summary: new rule: RCVD_IN_SSBL
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Rules (show other bugs)
Version: unspecified
Hardware: Other All
: P5 enhancement
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL: http://www.returnpath.net/internetser...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-03-03 11:06 UTC by J.D. Falk
Modified: 2017-06-07 16:28 UTC (History)
3 users (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
Description J.D. Falk 2009-03-03 11:06:04 UTC
please evaluate this additional blacklist rule:

header __RCVD_IN_SSBL            eval:check_rbl('ssbl', 'bl.score.senderscore.com.')
describe __RCVD_IN_SSBL          IP on Sender Score Blacklist; https://www.senderscore.org/rtbl/
tflags __RCVD_IN_SSBL            net
Comment 1 Karsten Bräckelmann 2009-03-03 11:46:24 UTC
I take it that according to https://www.senderscore.org/rtbl/ deep parsing of Received headers is safe? It does seem to potentially include end-user IPs, but states to list "large volume sending" IPs only, which should be fine.


What about the access policy (bottom of the page) here:
  http://www.returnpath.net/internetserviceprovider/blacklist/

All users of the blacklist are required to contribute to the Return Path Reputation Data Network.

How is that supposed to work for SA users?

Does it actually hold? What about an exception for free queries by SA, similar to Barracude BRBL? (see bug 5984 comment 1)
Comment 2 J.D. Falk 2009-03-03 11:58:21 UTC
(In reply to comment #1)

> I take it that according to https://www.senderscore.org/rtbl/ deep parsing of
> Received headers is safe? It does seem to potentially include end-user IPs, but
> states to list "large volume sending" IPs only, which should be fine.

Our system does try to figure out if an IP is dynamic, but if an IP hasn't been sending any spam then we won't list it...so, that /should/ be safe.

> What about the access policy (bottom of the page) here:
>   http://www.returnpath.net/internetserviceprovider/blacklist/
> 
> All users of the blacklist are required to contribute to the Return Path
> Reputation Data Network.
> 
> How is that supposed to work for SA users?

That's primarily intended for sites large enough to need zone transfers; with SA, we'd be happy to simply get some ad-hoc feedback every now and then.

I can get a formal exception statement written up if you think it's necessary....
Comment 3 Karsten Bräckelmann 2009-03-03 12:19:37 UTC
(In reply to comment #2)
> Our system does try to figure out if an IP is dynamic, but if an IP hasn't
> been sending any spam then we won't list it...so, that /should/ be safe.

Right, that's how I understood the description. Indeed, that should be fine.

I specifically asked to verify the bulk-sending constraint. Other lists do explicitly list IPs merely /because/ they are end-user IPs not intended to send mail directly -- which of course is not safe for deep-parsing.

If dynamic / end-user IPs do not get listed in SSBL just for sending direct to MX mail, *unless* they are sending huge volumes (as per the description), this should be good for deep-parsing as opposed to last-external only.


> > What about the access policy (bottom of the page) here:
> >   http://www.returnpath.net/internetserviceprovider/blacklist/

> That's primarily intended for sites large enough to need zone transfers; with
> SA, we'd be happy to simply get some ad-hoc feedback every now and then.
> 
> I can get a formal exception statement written up if you think it's
> necessary....

Hmm, personally I don't think I'm in a position to demand such a statement, though I sure would like to have one. :)  I guess comments in here by Return Path staff are already quite official... Alternatively it might be worth clarifying the quoted policy, to specifically talk about rsync users.

Just trying to eliminate any confusion about allowed usage. I for one didn't understand "all users" as limited to rsync. ;)  Thanks for clarifying this, J.D.


Nice to see the effort and offer. :)
Comment 4 Karsten Bräckelmann 2009-03-03 13:52:35 UTC
Committed revision 749770, rules/trunk/sandbox/kb/20_bug_6080.cf
Comment 5 Justin Mason 2009-03-14 14:42:08 UTC
fwiw, here's the results:

MSECS      SPAM%     HAM%     S/O    RANK   SCORE  NAME WHO/AGE
0.00000  16.0554   0.0965   0.994    0.90    0.00  RCVD_IN_SSBL  

http://ruleqa.spamassassin.org/20090314-r753615-n/RCVD_IN_SSBL/detail

looks pretty good, although not sure about those ham FPs, that'd limit the score imo.  also most of the spam hits are on high-scoring spam already.
Comment 6 J.D. Falk 2009-03-16 08:34:16 UTC
> looks pretty good, although not sure about those ham FPs, that'd limit the
> score imo.  also most of the spam hits are on high-scoring spam already.

About what I expected, actually.  Thanks for running the test!

We've got a new version in the works, but it's not open for queries yet, so it'd be difficult to share that with the full SA userbase.  It should be replacing the current SSBL (same zone, same rsync location) within a couple of months.

I'm not certain of the appropriate process, but would it make sense to leave this in the sandbox and then test it again once the new SSBL is available to everyone?
Comment 7 Justin Mason 2009-03-16 09:36:05 UTC
(In reply to comment #6)
> I'm not certain of the appropriate process, but would it make sense to leave
> this in the sandbox and then test it again once the new SSBL is available to
> everyone?

yep -- that should work fine. thanks!
Comment 8 Dave Jones 2017-06-06 22:46:31 UTC
Can we revive this with the new 0-100 scoring?  I have been using this in my SA platform now for a couple of years and it would really benefit the entire SA community and give a lot of visibility to ReturnPath.

ifplugin Mail::SpamAssassin::Plugin::DNSEval

header          __RCVD_IN_SENDERSCORE_90_100    eval:check_rbl('senderscore90-lastexternal','score.senderscore.com.','^127\.0\.4\.(9[0-9]|100)$')
meta            RCVD_IN_SENDERSCORE_90_100      SPF_PASS && __RCVD_IN_SENDERSCORE_90_100
describe        RCVD_IN_SENDERSCORE_90_100      Senderscore.org score of 90 to 100
score           RCVD_IN_SENDERSCORE_90_100      -2.2
tflags          RCVD_IN_SENDERSCORE_90_100      net

header          __RCVD_IN_SENDERSCORE_80_89     eval:check_rbl('senderscorer80-lastexternal','score.senderscore.com.','^127\.0\.4\.(8[0-9])$')
meta            RCVD_IN_SENDERSCORE_80_89       SPF_PASS && __RCVD_IN_SENDERSCORE_80_89
describe        RCVD_IN_SENDERSCORE_80_89       Senderscore.org score of 80 to 89
score           RCVD_IN_SENDERSCORE_80_89       -0.2
tflags          RCVD_IN_SENDERSCORE_80_89       net

header          RCVD_IN_SENDERSCORE_70_79       eval:check_rbl('senderscorer70-lastexternal','score.senderscore.com.','^127\.0\.4\.(7[0-9])$')
describe        RCVD_IN_SENDERSCORE_70_79       Senderscore.org score of 70 to 79
score           RCVD_IN_SENDERSCORE_70_79       1.2
tflags          RCVD_IN_SENDERSCORE_70_79       net

header          RCVD_IN_SENDERSCORE_60_69       eval:check_rbl('senderscorer60-lastexternal','score.senderscore.com.','^127\.0\.4\.(6[0-9])$')
describe        RCVD_IN_SENDERSCORE_60_69       Senderscore.org score of 60 to 69
score           RCVD_IN_SENDERSCORE_60_69       2.2
tflags          RCVD_IN_SENDERSCORE_60_69       net

header          RCVD_IN_SENDERSCORE_50_59       eval:check_rbl('senderscorer50-lastexternal','score.senderscore.com.','^127\.0\.4\.(5[0-9])$')
describe        RCVD_IN_SENDERSCORE_50_59       Senderscore.org score of 50 to 59
score           RCVD_IN_SENDERSCORE_50_59       3.2
tflags          RCVD_IN_SENDERSCORE_50_59       net

header          RCVD_IN_SENDERSCORE_30_49       eval:check_rbl('senderscorer30-lastexternal','score.senderscore.com.','^127\.0\.4\.([3-4][0-9])$')
describe        RCVD_IN_SENDERSCORE_30_49       Senderscore.org score of 30 to 49
score           RCVD_IN_SENDERSCORE_30_49       4.2
tflags          RCVD_IN_SENDERSCORE_30_49       net

header          RCVD_IN_SENDERSCORE_0_29        eval:check_rbl('senderscore0-lastexternal','score.senderscore.com.','^127\.0\.4\.([1-2]?[0-9])$')
describe        RCVD_IN_SENDERSCORE_0_29        Senderscore.org score of 0 to 29
score           RCVD_IN_SENDERSCORE_0_29        5.2
tflags          RCVD_IN_SENDERSCORE_0_29        net

endif
Comment 9 Kevin A. McGrail 2017-06-06 23:19:42 UTC
Are you asking to add the whitelist and granular implementation to replace the single test in 20_dnsbl_tests.cf?
Comment 10 Dave Jones 2017-06-07 01:25:46 UTC
From my experience, that bl.score.senderscore.com is very conservative and doesn't help much.  We can leave it as is if you want.  What I would like to see added and tested are the ranges in some form, maybe not exactly as I have them.  Any sender above 90 is pretty trustworthy, below 60 is suspicious, and below 30 should have a lot of points added.
Comment 11 Kevin A. McGrail 2017-06-07 16:10:12 UTC
OK, so the multibit score.senderscore.com and bl.score.senderscore.com don't have overlap?

Do you have a link to any descriptions of the list and Terms of Service?
Comment 12 Dave Jones 2017-06-07 16:28:08 UTC
The bl.score.senderscore.com seem to be slow reacting when the score has dropped very low for a long period.  The "multi-bit" response of 0-100 reacts quickly.  A normally good/trusted mail server would be in the 90s then when spam starts being seen, they drop the score depending on the volume and the complaints reported to them.  The score could drop very quickly or it could drop slowly.  See their https://senderscore.org/ site and enter an IP to see their 30-day graph with volume and scoring to get an idea of how this "multi-bit" score works.

I am finding this very accurate and helpful in separating out my masscheck corpus for manual review.

I have filled out a request on their site to get someone to contact me about T&Cs since I was not able to find it on their site.

Dave