Re: [Declude.JunkMail] Test based on results of other tests

[Matthew Bramble]

I'm with you on how this would be accomplished, though it would probably be a somewhat laborious rewrite in how scoring was handled in comparison to how it is handled now.  Just guessing of course. This was actually my first feature request to Scott after purchasing the application some time ago, and it's about the 5th time I've seen it talked about in the past few weeks.  While I have almost absolute faith in just a few blacklists (SpamCop for example), I would definitely combine many other blacklists that I have less faith in as one test...in other words if a piece of mail failed both FIVETEN-SPAM and SORBS-SPAM, then I would use the combined test to add on a hefty penalty for an automatic fail.  I could do the same for two different open relay tests, figuring that if two know about it, then it is more likely being used for spam and more likely to be fixed by a responsible administrator rather than having their E-mail blocked over a longer term.  I would probably also apply this multi-test penalty to things like NOABUSE and NOPOSTMASTER because I generally see just one failed unless it is spam and I score them both very low individually.  I might even do something like credit points on two technical tests that are often failed together, SPAMHEADERS and HELOBOGUS for instance, and that would let me increase the scores on each individually (I'd have to research this one more before I could claim it would be effective). Maybe it will be a treat for v2.0 :) And speaking of patents, anyone ever hear of this one? http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/netahtml/srchnum.htm&r=1&f=G&l=50&s1='6,368,227'.WKU.&OS=PN/6,368,227&RS=PN/6,368,227 Matt Karen D. Oland wrote: You actually reminded me of how complex this would be. Both the Global.cfg and appropriate .junkmail file would have to be loaded into memory, some tests run, consult the files, other tests run, consult the files, final tests run, consult the files and so forth. You are trying to make this much more difficult. Yes, declude would have to change --- as it does whenever any new test type is added. But there would be absolutely no need to run tests, consult files, etc. As far as loading the files into memory -- that already takes place (or declude would not work at all). Once loaded, in the part of the program that processes the $junkmail file (whichever one is relevant), a scan could be done for special lines (eg, TWOTESTS COMBINEAND TEST1 TEST2 or TWOTESTS COMBINEXOR TEST1 TEST2 -- since OR is not really necessary, but XOR and AND would be good logical tests). The new tests are added to the list of tests (already in memory) with pass/fail info. Then processing continues as usual. Really, not an extrememly large amount of work. No starting, stopping, etc. All tests would run as they do now -- no need to change that. Adding weights would be different and more flexible for some purposes, but just the above would be an extreme jump forward in setting up tests --- one example: if an email has certain words, we isolate it, as it MAY be porn (they are reviewed and deleted or requeued). There are some ip4r tests that identify possible sporn IP's -- we use these to add weight, but don't hold (due to FP's). But, if the email msg fails both, we would probably delete them outright and hold/review the rest. Certain mailing lists also tend to fail the suspect porn list due to either their subject (for instance, this list) or the users there -- but we would ignore them if we had the ability to combine the two pieces of info. Adding weights: simple here as well. Scan global.cfg - strip out "combine" tests", run all other tests as done now, in parallel or serial, not relevant. when all results are back, before ending the thread, process the combine tests and add weights to them as indicated.then pass control to the part of the program that handles .junkmail. Right now, declude.exe loads the Global.cfg to determine what tests to run, the after tests have been run, consults the appropriate .junkmail file to determine what action to take. Which is exactly what it would continue to do, if the combine tests were done in the $junkmail file. Not to mention, this gives ever more flexibility for combining tests. Karen (who considers this such an obvious solution to a programmer, but suspects the patent office would issue a patent for such a technique, based on "no one else has filed one for it yet!).