Discuss

discuss@lists.surbl.org

1864 discussions

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

False Posititive?
by Matt 09 Nov '04

09 Nov '04

I'm getting mail tagged with this URI: 5.0 WS_URI_RBL URI's domain appears in sa-blacklist at http://www.surbl.org/lists.html [www.allhiphop.com is blacklisted in URI RBL at] [ws.surbl.org] The site looks fairly legit to me, and it is being included in a legit newsletter. Any comments on this?

3 2

Webbi`s kleiner Datentoaster?
by Jeff Chan 09 Nov '04

09 Nov '04

Does anyone know: Webbi`s kleiner Datentoaster or why they are trying to zone transfer surbl.org from the following addresses? 83.129.251.245 83.129.247.209 83.129.221.175 83.129.211.136 There is some evidence they maybe crackers. Does anyone know anything about them? These appear to be dynamic tiscali.de DSL addresses. Jeff C.

2 2

RE: [SURBL-Discuss] LT02.NET
by Chris Santerre 09 Nov '04

09 Nov '04

So what was the outcome? That's right, I'm back! For 2 days anyway. I'm much happier and poorer from my vacation! But I did manage to pickup a BFG 6800 OC video card while I was away ;) WOOOT!!! Fragfest! (Yes I did OC the OC a bit more!) --Chris (I firmly believe if Disney shaped dog poo into the Mickey shape, My wife would want to buy it!) >-----Original Message----- >From: Jeff Chan [mailto:jeffc@surbl.org] >Sent: Thursday, October 28, 2004 8:07 PM >To: SURBL Discussion list >Subject: Re: [SURBL-Discuss] LT02.NET > > >On Thursday, October 28, 2004, 1:41:43 PM, Fred Fred wrote: >> Can someone tell me why LT02.NET is whitelisted? (don't >tell me cause it's >> in ham) I would like an example if possible. > >> They use open relays to send their spam, the have 8 nanas >hits, the domain >> is fairly new like 2004-08-06 > >> Hand checked, it does not look like a legit site. (main >page is just a >> remove form.) > >> I played around and found that if you visit: >> http://t.lt02.net/c.asp? >> it will redirect you to www.listrak.com which is also >whitelisted (listrak >> has 31 nanas hits). > >> Their mx record is an open relay, I think this is a very >questionable domain >> to whitelist. > >> http://ordb.org/lookup/?host=66.109.239.150 > >First, we're not an open relay database. Our concern is spam URI >domains. > >Second, lt02.net was whitelisted by Steve Champeon, whose >anti-spam abilities I trust. Steve, would you care to comment >on this one? > >> steve of hesketh.com >> Has whitelisted: lt02.net >> >> Found on SURBL lists: WS OB >> >> Justification is: >> >> 'Found in possibly legit PRNewswire mailing.' >> >> Ticket is: >> >> Timestamp: Tue Sep 14 17:50:25 UTC 2004 > >Regarding listrak.com, I whitelisted it, probably because it >appeared in newsletters from legitimate companies. > >I'm interested in seeing examples of spam and ham mentioning >these domains. > >Jeff C. >-- >"If it appears in hams, then don't list it." > >_______________________________________________ >Discuss mailing list >Discuss(a)lists.surbl.org >http://lists.surbl.org/mailman/listinfo/discuss >

2 1

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