> From: Malte S. Stretz > Sent: Monday, 5 July 2004 6:03 p.m. Hi Malte,
> I'm not against adding an option to make those tests run > serially instead of > parallelly. But with your reasoning you contradict yourself a > bit: As an > optimization you want to short-cut the net tests if they are > not needed -- > but above you say you don't need that speed. So what do you want that > feature for? > > As we're talking only about the DNS tests here, those don't > generate much > traffic in the first place so the advantage you get here is > negligible too. My reasoning was based on unnecessary traffic and DNS server loads, initially. Anyway I have done some very quick tests... My measurements for the traffic lookups were approx 5 to 15k each message with RBL, SURBL and DCC. (This wouldn't include packet headers), but the interesting thing was that with all net tests disabled, the scan time was always 0 seconds (less than 1 sec?) - however with the default SA RBLS + DCC + 3 SURBL tests, the scan time was 2 to 4 seconds. Although more testing would need to be done, it would appear (at least in my environment) running net tests after local tests would not incur much of a performance hit. My local tests and bayes are working quite well with tweaking and although all spam would have been rejected, a few would have required net tests to send them over an example "Dont_run_net_tests" score of say +15. This machine is running SA2.63 and is a 2.8Ghz Xeon. Net tests: SA RBL defaults, DCC, 3 x SURBL Local tests: SA defaults, Bayes, SARE additional rules (bayes and some SA rules scores modified) I simply "bounced" these spam from another server which sends us legitimate email so this may have thrown bayes. > On the other hand can they block your mail delivery for quite > some time if > one or more of them times out. As you'd have to run the net > tests in many > cases anyway (for me not much spam scores high enough based > only on the > local tests), running the tests parallelly is not "balzing > performance" but > the only thing which will most probably not affect your > overall performance > (counted over several days/weeks) negatively. Another thought, on top of not running net tests on high scoring emails, would be to have the option not to run net tests on greatly negated emails, like whitelisted scores. That way resource conservation and speedups would be conserved against ham also. Again, these ideas would not suit every Tom and Dick (can I say that here?), but I see it has applications. > Patches are welcome :) How did I know someone was going to say that :) Cheers Scott
