-------- Original-Nachricht -------- > Datum: Mon, 3 Aug 2009 01:11:20 -0700 > Von: "Michael Watkins" <[email protected]> > An: [email protected] > Betreff: Re: [Dspam-user] RBL Configuration
> On Mon, August 3, 2009 00:51, Steve wrote: > > btw: Since you are using Geo-IP... I could extend the Geo-IP patch to > > allow scoring by distance. I came to that idea after reading about SNARE > > (http://www.technologyreview.com/communications/23086/). > > Neat idea. > > > I have not added that jet to policyd-weight but I am really tempted to > add > > it. What I don't know jet is how to make the lookup table? The problem I > > see with the lookup table is that I just have the distance and I need to > > score if a certain distance is reached but look at this example: > > ---- > > @distance_score = ( > > # DISTANCE IN KM, NO MATCH, MATCH, LOG NAME > > "1000", -0.50, 0.50, "1000_KM", > > "2000", -0.50, 1.00, "2000_KM", > > "4000", -0.50, 1.50, "4000_KM", > > "8000", -0.50, 2.00, "8000_KM", > > "16000", -0.50, 2.50, "16000_KM", > > ); > > > What should the score be for a distance of 2500 Km? Probably 1.00? Or > > should it be 1.50 since it matches the 1000 Km AND it matches 2000 Km? > Or > > should it be 0.00 since it matches the 1000 Km AND it matches 2000 Km > but > > it DOES NOT match the 4000 Km and the 8000 Km and the 16000 Km? > > > > How would you expect the matching to work? > > Cumulative is ok provided anyone who uses this understands that. No doubt > there will be some who look for > < == tests instead. > Then maybe adding something like that here could help to satisfy most users: @distance_score = ( # MINIMUM DISTANCE IN KM, SCORE, LOG NAME "1000", -0.50, "1000_KM", "1000", 0.50, "1000_KM", "2000", -1.00, "2000_KM", "2000", 1.00, "2000_KM", "4000", 1.50, "4000_KM", "8000", 2.00, "8000_KM", "16000", 2.50, "16000_KM", ); And then check of score is positive then compare (computed distance >= matching distance) and prefix LOG NAME with "ABOVE_" in case of compare match and if score is negative then compare (computed distance < matching distance) and prefix LOG NAME with "BELOW_" in case of positive compare. So a distance of 2500 Km would result in: + 0.50 + 1.00 ------ + 1.50 A distance of 1500 Km would result in: + 0.50 - 1.00 ------ - 0.50 Ach! Reading that now already tells me that most users would not be able to handle that. Better to go with the commutative approach. Or what do you think? > > Since I have as well the continent data I could do a scoring by > continent > > as well. Maybe something like that: > > @continent_score = ( > > # CONTINENT, NO MATCH, MATCH, LOG NAME > > 'AF', 0.00, 0.50, 'Africa', > > 'AS', 0.00, 2.00, 'Asia', > > 'EU', -1.00, 0.00, 'Europe', > > 'NA', 0.00, 1.00, 'North_America', > > 'OC', 0.00, 0.50, 'Oceania', > > 'SA', 0.00, 0.50, 'South_America', > > ); > > > > That might be another additional benefit in using the Geo-IP module. > > What do you think? Could that be something useful? > > Indeed, that looks like a winner to me. I'd rank certain continents with a > high match value and then reward certain countries within those continents > with a negative value. > So you think I should take the time to quickly add the scoring by distance and scoring by continent into policyd-weight? // Steve -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Dspam-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspam-user
