Great! Of course, this "feature" could also be used to determine if a specific RBL is causing to many false-positives too...
Running all the checks simultaneously certainly will negate the need to order them in any specific order and should make the overall process that much faster, especially if you're using multiple RBL's. What kind of effect will that have on server load? Many RBL lookups sequencially versus many RBL lookups simultaneously? Seems like the process might be faster, but will take more resources on the server? Which would likely mean a basic "Push" with the net result being faster handling of the session? Thanks again! Mike > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sam > Clippinger > Sent: Monday, April 14, 2008 9:40 AM > To: spamdyke users > Subject: Re: [spamdyke-users] let qmail decide if it accepts > a recipient before doing RHSBL? > > Yes, this is certainly possible. Right now spamdyke > identifies the RBL in its message to the remote server but > not in the logs. Good idea! > > What would be a good way to log this information (preferably > without breaking existing scripts)? I'm thinking as I type > here, but spamdyke already follows the rejection reason with > parenthesis (when the log level is high enough) to indicate > which file/line matched for file-based filters... perhaps the > same could be done for RBLs/RHSBLs. Something like this: > DENIED_RBL_MATCH(rbl.example.com) > > As for reordering the RBLs to put the often-matched ones > first, the next version of spamdyke will make that less > necessary. By default, it will query all RBLs > simultaneously, regardless of their order. (That behavior > can be prevented with a new flag -- ordering would be > important in that case.) > > -- Sam Clippinger > > Michael Colvin wrote: > > > >> To find real numbers, you would have to consider how many > connections > >> are accepted, how many are rejected and for what reasons. > Then look > >> at the popularity of different spamdyke features and > specifically the > >> popularity of different DNS RBLs. Use all that to find out what > >> percentage of rejected connections could avoid the DNS > queries due to > >> local tests. > > > > Along those lines, is it possible, or can it be possible, to have > > spamdyke's logs indicate which DNS RBL caused a message to be > > rejected? I'm assuming that once a reason for rejection is > found, IE, > > the IP is listed in a particular RBL, further tests against other > > RBL's in the list are not performed? Knowing, statistically, which > > ones have a higher rejection rate, and queuing those first > in the list of RBLS might save some time. > > > > Or course, multiple RBLS could reject the same message, and the one > > first in line would have the higher percentage, but this > would give us > > a way to move them around and check the results... > > > > Just a thought from a newbie to spamdyke. > > > > BTW, I LOVE Spamdyke! What a difference it has made in my system's > > ability to filter spam and save resources! It's a God send! > > > > Mike > > > > > > > > _______________________________________________ > > spamdyke-users mailing list > > spamdyke-users@spamdyke.org > > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ > spamdyke-users mailing list > spamdyke-users@spamdyke.org > http://www.spamdyke.org/mailman/listinfo/spamdyke-users > _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
