|Summary:||new rule: RCVD_IN_SSBL|
|Product:||Spamassassin||Reporter:||J.D. Falk <jdfalk>|
|Component:||Rules||Assignee:||SpamAssassin Developer Mailing List <dev>|
|Severity:||enhancement||CC:||davej, jdfalk, kmcgrail|
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