Thanks for the advice. Just using default configuration, has reduced amount of spam by around 85%. After using policyd-weight to reject spam, I don't see much of a use in having rejection functionality in dspam. It looks like very few spams are coming to dspam.
On Tue, Aug 4, 2009 at 2:27 AM, Steve<[email protected]> wrote: > > -------- Original-Nachricht -------- >> Datum: Mon, 3 Aug 2009 18:22:49 -0700 >> Von: "Michael Watkins" <[email protected]> >> An: [email protected] >> Betreff: Re: [Dspam-user] RBL Configuration > >> On Mon, August 3, 2009 11:00, Steve wrote: >> > btw: Did you use the Geo::IP patch from policyd-weight page or did you >> coded one by yourself? >> >> In fact I was in a hurry (for some reason at the time nerd.dk was failing >> left and right for me) and had used the Geo:IP patch linked from the >> policyd-weight page. >> > The code from the original policyd-weight page has an issue (from my > viewpoint) and I would replace the checking with this here: > --------------- > ## GeoIP check ############################################################### > my $i; > if (($rate < $REJECTLEVEL) && ($ip ne "")) > { > if (scalar(@geoip_score) > 0) > { > my $country = $geoip->country_code_by_addr("$ip"); > if(defined($country)) > { > for($i=0; $i < @geoip_score; $i += 4) > { > if($country eq $geoip_score[$i]) > { > my $score = $geoip_score[$i+2]; > if ($score != 0) { > $RET .= ' IN_'.$geoip_score[$i+3].'='.$score; > $rate += $score; > } > } > else > { > my $score = $geoip_score[$i+1]; > if ($score != 0) { > $RET .= ' > NOT_IN_'.$geoip_score[$i+3].'='.$score; > $rate += $score; > } > } > } > } > } > --------------- > > The two main differences compared to the original code are the two if > conditions at the beginning. The first one ensures that the code only runs if > the score is not already above the reject level and the second one checks if > you have at least one check statement inside @geoip_score. > > Since the check is so fast I really don't see a big problem in running the > Geo::IP stuff even if one should be already above the reject level. So first > condition could be removed but the second should be checked regardless of the > current reject score. I mean: What is the point calling Geo::IP if you are > using no checks at all? > > You told me you are a speed freak so you should add those two conditions to > your original code. Would make IMHO policyd-weight more portable to systems > where one might have Geo::IP installed but not using it. > > >> I'm glad this little discussion of Geo:IP bore some fruit for you Steve. >> > I will look how well this works here and will submit a patch to the > policyd-weight SF page. Maybe they will include it in future releases? > > >> Best regards >> Michael >> > 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 > ------------------------------------------------------------------------------ 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
