Rob McEwen wrote:
<div class="moz-text-flowed" style="font-family: -moz-fixed">Dallas
Engelken wrote:
Yes, of course, but you're results.txt is biased as it only shows
where imvURI hits.
Based on the last 20k adds to URIBL, it appears to me that imvURI
has less coverage?
<snip>:
Dallas,
Yes, you are right!
URIBL *does* cast a wider net than ivmURI.
So, in general, I agree with your statement that ivmURI has less
coverage than URIBL. But I'm confused about your stats... and they
looks really weird. (but maybe I'm just not understanding them?)
So here is what I did.
I took the last 500 additions to URIBL, (not including geocity and
blogspot items... so that this comparison would compare apples to
apples!) I then ran those against ivmURI.
186 of the 500 latest additions to URIBL were also found in ivmURI.
I then reversed this testing and ran URIBL against the last 500
additions to ivmURI.
328 of the latest 500 additions to ivmURI were listed on URIBL.
So yes, basically, you're right, URIBL does have greater coverage than
ivmURI.
Your point is well made. For the most part, URIBL casts a wider net
than ivmURI. Also, if you were to include geocity and blogspot hits,
of course, that would throw the comparison wildly in URIBL's favor...
but I'm not so sure that would be a fair comparison.
No, you're right, thats not fair. If I compare only recent reactive
listings, minus the subdomain hosters that we list, you hit about 60%
whereas before it was more like 27%.
imvURI stats from last 5000 URIBL black listings
-> 2981 hits
-> 2019 misses
(In both tests, I checked against the 2nd list just about 2-3 minutes
after grabbing the lastest data from first list. This is important as
I was seeing those stats quickly grow for BOTH after my initial
collection of stats... because items not yet in both lists are
continuously getting into the other list fast. So timing is mission
critical in this kind of testing and the time between gathering and
checking MUST be the same both ways.)
However, I think you missed my point about
http://invaluement.com/results.txt
I wasn't saying that this proved that ivmURI is better than URIBL or
SURBL. Only that this proves ivmURI as being *relevant* and *useful*
...even for those who are already using *both* URIBL and SURBL. (and
this is just one such proof!)
you said,
"and ALL 3 catch stuff the other 2 miss... FOR EXAMPLE:
http://invaluement.com/results.txt )"
your EXAMPLE contradicts the statement that precedes it. I can only take it in the context of how I read it.
For example, if ivmURI were only catching stuff already caught by
URIBL and SURBL, ivmURI wouldn't be relevant or helpful to anyone.
Moreover, I believe that URIBL or SURBL could easily create a
similarly impressive page as my http://invaluement.com/results.txt page.
Probably.
Bottom line is that you are correct... AND... I'm sorry you took this
as me dissing URIBL!
I didnt take it that way. I was just pointing out that your statement
didnt match your accompanying example.
Simply put, there are some series of spams that each of the three URI
blacklists are better at catching than the other two. That is ALL that
I meant by this.
Okay, if you would have said that, I would have agreed and never posted :)
--
Dallas Engelken
[EMAIL PROTECTED]
http://uribl.com
