Discuss

discuss@lists.surbl.org

1867 discussions

Re: [SURBL-Announce] SURBL stats: list hit rates measured in DNS
by Jose Marcio Martins da Cruz 14 Nov '04

14 Nov '04

Jeff, You'll find some stats from our mail server at : http://j-chkmail.ensmp.fr/urlbl/urlbl.txt Some words about it : - When a list get a hit, it stops searching other lists. - The first list checked is the our one. surbl lists are checked just after our one, in alphabetical order. This means : j-chkmail ab.surbl.org ... So, our stats doesn't show all lists, but if this interests you, I can easily adapt our stats scripts to get hits for all lists. Either way, this shows that most spam detection using SURBL, at our domain, comes from ab and multi. This conclusion is mitigated by : - many entries from our list (j-chkmail) may exist on ob/sc or ws. - our list (j-chkmail) isn't being updated too frequently, because as I said you before, I add entries only when they aren't yet at surbl lists and surbl lists are being updated very fast... Best Jose-Marcio > > In order to explore some conjunctions of existing lists that > might have fewer false positives, we've created some stats > measuring the number of DNS hits against all blocklists that the > individual lists get, along with some permutations of those lists. > > > Jeff C. > -- > Jeff Chan > mailto:jeffc@surbl.org > http://www.surbl.org/ >

1 0

Re: [SURBL-Discuss] RFC: consensus list?
by Frank Ellermann 14 Nov '04

14 Nov '04

Jeff Chan wrote: >> (35 + 35 + 21 + 7 + 1 = 99, is that correct ?) It is, 128 -1 -7 -( 6+5+4+3+2+1 ) = 99. Where -1 is "not no bit", -7 is "not only one bit", and the rest "not two bits". > Actually it may be necessary to create some new lists, > partly depending on whether the application can combine > individual lists by itself. Yes, bit 0 could replace only one "new list", not several. But as long as you can express the condition for the "new list" by a single boolean expression of the 7 multi bits, one bit is good enough. Excl. the special case "no bits", because that would result in 127.0.0.1. > And I just realized a major flaw in my suggestion to try > 127.0.0.84 as a single list 84 = 64+16+4 (you said JP+OB+WS, I don't check it). Let's say that you want any combo where these 3 bits are set. Then you have 3 fixed bits, and 4 free bits (at the moment only 3 free bits, but you may want to add the 7th bit later). 2 ** 4 = 16, you need 16 result codes to identify all combos with JP+OB+WS: 84,86, 92,94, 116,118, 124,126, (= 8 without the 7th bit, for the remaining 8 combos just add 128, from 212 to 254) > it will NOT have any JP + OB + WS + SC That's 86 = 84 + 2. > That kind of combination needs to be done by creating a > new list on the data side, or special processing in the > application. Or by adding bit 0 on your side for THE one "optimal rule": 85,87, 93,95, 117,119, 125,127 (= same 8, now bit 0 is set) > I will create some temporary test lists in the second or > third octet of multi to test on corpora instead. Yes, post a real complex boolean expression, it's fun stuff, SURBL would set a new standard (impressing ISIPP and OPM ;-) But don't touch the zeros in 127.0.0.? without warning, it would break my poor <http://purl.net/xyzzy/src/rxwhois.cmd> : | if SockGetHostByName( arg(1) || arg(2), 'P.' ) then do | if abbrev( P.ADDR, '127.0.0.' ) | abbrev( P.ADDR, '127.1.0.' ) | then say arg(3) '(' || substr( P.ADDR, 9 ) || '):' arg(2) | else say 'erroneous result' P.ADDR 'for' arg(1) || arg(2) | return 1 | end /* 127.1.0.1 .. 127.1.0.7 for .opm.blitzed.org(1+2+4) */ | return 0 Bye, Frank

2 5

RFC: consensus list?
by Jeff Chan 14 Nov '04

14 Nov '04

Pondering the question of how to make a "telco grade" SURBL that had as close to zero false positives as possible, but would still catche many spams, I remembered that many of the biggest spam domains seem to appear in several different SURBL lists. What does anyone think about creating a "consensus" list that a telco or ISP might use to block at the MTA level? For example a domain that appears on: ((SC or AB) and (JP or OB)) or PH might be a candidate for such a list. The main reason I don't include WS is that it's a hand built list and I don't have a feeling for the latencies from it. SC and AB are both mostly based on SpamCop user reports. JP and OB are both mostly based on spamtrap data. PH represents really destructive fraud and phishing and probably should be included unless the FP rates from it are significantly above zero. I realize this is a simplistic scheme and other ways of combining the list are possible, but what does anyone think those idea? Conceivably we could have other combinations. Another possibility might be records that appear in SC and AB and WS and JP and OB I think we can nearly guarantee that those are 100% spam. :-) (Would want to check those that are in WS separately from JP, which is currently included in WS.) What other ways to combine lists might produce near zero FPs yet still hit most spam? Shall we just try some of them and see how well they work? Comments? Jeff C. -- "If it appears in hams, then don't list it."

6 13

Re: [SURBL-Discuss] RFC: consensus list?
by Frank Ellermann 13 Nov '04

13 Nov '04

Jeff Chan wrote: > LOL! I didn't think of that! Just an idea how to use bit 0 of multi in a way indicating "interesting" combinations. Ryan identified "any 3 out of 6 multi bits" as relevant. That's probably too KISS for you, and if you'd add the not yet used 7th multi bit it would result in 7 over 3 (any 3 out of 7) combinations, 99 result codes if I got it right. (35 + 35 + 21 + 7 + 1 = 99, is that correct ?) Apparently SA already supports Ryan's idea, and then you don't need it. But if you have more complex rules to get an "optimal" proper subset of all multi result codes, then you could (ab)use bit 0 to mark it. Or in other words, any odd N in 127.0.0.N would be optimal. And 127.0.0.1 would be still protected (= never returned). > without explicitly creating new, combined lists. Yes, that's unnecessary. Unless you have more than one definition of "optimal". Bit 0 can only handle one "rule", i.e. any combination of AND / OR / NOT multi bits you like. Bye, Frank

2 1

Re: [SURBL-Discuss] RFC: consensus list?
by Frank Ellermann 13 Nov '04

13 Nov '04

Jeff Chan wrote: > Comments? See Ryan's answer, it's easy to do interesting stuff with the multi bits, multi was a good idea. If you want to simplify it set bit 1 if 3 or more other bits are set, examples: 127.0.0.6 => 127.0.0.6 (2 or less bits unchanged) 127.0.0.100 => 127.0.0.101 (64+32+4 => 64+32+4+1) 127.0.0.14 => 127.0.0.15 (8+4+2 => 8+4+2+1) Bye, Frank

2 1

Re: [SURBL-Discuss] RFC: consensus list?
by Rich Graves 13 Nov '04

13 Nov '04

Jeff Chan wrote: > The idea is to have a "golden" list that is so accurate > (for spams it does identify) and has so few FPs that > it would be safe to block outright at the MTA level, > for example. > > An MTA milter or plugin probably can't determine that > from multi alone (i.e. looking at all the lists), so I'm > wondering if we can create a list for that purpose out > of the existing lists. SpamAssassin does have "meta" rules. Look at NIGERIAN_BODY4 or UPPERCASE_75_100 in 20_meta_tests.cf. meta SURBL_3 (URIBL_JP_SURBL + URIBL_AB_SURBL + URIBL_PH_SURBL + URIBL_SC_SURBL + URIBL_WS_SURBL + URIBL_OB_SURBL) > 2 describe SURBL_3 Contains URIs in at least 3 blacklists score SURBL_3 3 True, that would also catch messages with one URI in JP, a different URI in AB, a third URI in OB, and no actual overlap, but that's not very likely... -- Rich Graves <rcgraves(a)brandeis.edu> UNet Systems Administrator

3 2

Re: [SURBL-Announce] fraud.rhs.mailpolice.com phishing data added to ph SURBL
by Jeff Chan 13 Nov '04

13 Nov '04

On Thursday, November 11, 2004, 10:35:02 PM, Jeff Chan wrote: > As of 12 November 2004, we have added data from > fraud.rhs.mailpolice.com into ph, joining our exiting phishing > data from mailsecurity.net.au. I should add, this means if you were testing fraud.rhs.mailpolice.com as a separate list, as in SA 2.63 or 2.64 with SpamCopURI: uri MP_URI_RBL eval:check_spamcop_uri_rbl('fraud.rhs.mailpolice.com','127.0.0.2') describe MP_URI_RBL URI's domain appears in MailPolice fraud list tflags MP_URI_RBL net score MP_URI_RBL 2.0 or SpamAssassin 3.0.0: urirhsbl URIBL_MP fraud.rhs.mailpolice.com. A header URIBL_MP eval:check_uridnsbl('URIBL_MP') describe URIBL_MP URI's domain appears in MailPolice fraud list tflags URIBL_MP net score URIBL_MP 2.0 or SpamAssassin 3.0.1: urirhsbl URIBL_MP fraud.rhs.mailpolice.com. A body URIBL_MP eval:check_uridnsbl('URIBL_MP') describe URIBL_MP URI's domain appears in MailPolice fraud list tflags URIBL_MP net score URIBL_MP 2.0 Then you should remove or disable the above rule as redundant if you are also using ph in multi.surbl.org, which SpamAssassin 3.0.0 and 3.0.1 do *by default*: http://spamassassin.apache.org/full/3.0.x/dist/rules/25_uribl.cf urirhssub URIBL_PH_SURBL multi.surbl.org. A 8 body URIBL_PH_SURBL eval:check_uridnsbl('URIBL_PH_SURBL') describe URIBL_PH_SURBL Contains an URL listed in the PH SURBL blocklist tflags URIBL_PH_SURBL net score URIBL_PH_SURBL 3.0 (IIRC you can disable rules simply by setting them to zero, but in this case I'd probably recommend commenting them out or deleting them.) So keep the PH rule and delete any test rule using fraud.rhs.mailpolice.com separately. Jeff C. -- Jeff Chan mailto:jeffc@surbl.org http://www.surbl.org/

1 0

Please test MailPolice Fraud list
by Jeff Chan 12 Nov '04

12 Nov '04

Please test the MailPolice Fraud list as Bill described earlier (copied below). We would like to include this data in our PH anti-phishing list, but request your help in testing it first. We're particularly interested in any false positives. Jeff C. __ This is a list that MailPolice hosts and I have been running it for a few hours and it has already flagged some phish and fraud e-mails. Here is some info about the list: http://rhs.mailpolice.com/#rhsfraud This is my configuration for SA 2.64 with the SpamCopURI plug-in: uri MP_URI_RBL eval:check_spamcop_uri_rbl('fraud.rhs.mailpolice.com','127.0.0.2') describe MP_URI_RBL URI's domain appears in MailPolice fraud list tflags MP_URI_RBL net score MP_URI_RBL 2.0 And for SA 3.0 with the URIDNSBL plug-in: urirhsbl URIBL_MP fraud.rhs.mailpolice.com. A header URIBL_MP eval:check_uridnsbl('URIBL_MP') describe URIBL_MP URI's domain appears in MailPolice fraud list tflags URIBL_MP net score URIBL_MP 2.0 Bill

5 16

Re: [SURBL-Discuss] Please test MailPolice Fraud list
by Jeff Chan 12 Nov '04

12 Nov '04

On Thursday, November 11, 2004, 7:03:44 PM, Chris wrote: > On Thursday 11 November 2004 07:41 pm, Jeff Chan wrote: >> urirhsbl URIBL_MP fraud.rhs.mailpolice.com. A >> body URIBL_MP eval:check_uridnsbl('URIBL_MP') >> describe URIBL_MP URI's domain appears in MailPolice fraud list >> tflags URIBL_MP net >> score URIBL_MP 2.0 >> >> Jeff C. > Uh, maybe I should have clarified also :( do I just paste the above into my > local.cf? Yes, but be sure to put your local.cf in /etc/mail/spamassassin and not /usr/share/spamassassin. The former directory is for custom rules. The latter directory is for default rules that come with SA and can get overwritten when versions are updated. Jeff C. -- "If it appears in hams, then don't list it."

1 0

Probable new data source: DNS queries hitting spamhaus lists
by Jeff Chan 10 Nov '04

10 Nov '04

At Daniel Quinlan's suggestion, we've started to check a sampling of SURBL name server queries against sbl and xbl.spamhaus.org. His interest is as a potential replacement for the very time consuming NS record lookups done with uridnsbl. We haven't turned these into a SURBL yet, but probably will eventually. So far this has resulted in about 11k SBL domains with about 60% overlap with existing SURBLs. The fun thing is that this catches at a very early stage spams from scumbags like "Media Dreamland" that has been spamming free computer monitors, etc. lately. Some of these type of operations that reuse the same name server IPs, but register and change domains frequently are caught this way, just like uridnsbl does, but with perhaps a few missed due to sampling effects on the DNS queries. This method also features a much lower global DNS overhead since the lookups are done once in a centralized way, and not repeatedly in a gazillion SpamAssassin installations on the same domains in a very distributed and redundant way. The way this works is that we sample DNS queries from SURBL lookups and compare new wild domains (i.e. domains found in general email URIs), against xbl and sbl and build up lists of the matches. (To be more correct, it's the wild domain name server "NS" record resolved ip addresses which are checked against sbl and xbl.) Along with this will need to be expiration runs, which I haven't built yet. (In other words, domains should come off the lists when they no longer resolve or no longer resolve to name servers in sbl or xbl.) The main downside is that domains matching name servers listed in sbl or xbl definitely has more false positives than our other SURBL lists. We'll want to do some testing, but it may be as high as 1%, so they'd need to be used carefully. Some perhaps other interesting stats after about two weeks: unique queries logged so far about 250k (These are reduced to base domains where easy) SBL matches so far about 11k XBL matches so far about 400 SBL are checked for NS records only XBL are checked for NS, www, base domain against XBL (but not MX) Questions? Comments? Suggestions? Jeff C. -- "If it appears in hams, then don't list it."

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss