Far be it for me to halt progress... Scott, I can't wait to put in the new TESTSFAILED logic. I've wanted exactly this to keep certain multi-answer ip4r tests in check, and Matt is off to a great start in combining tests...
I also find that CMDSPACE is very handy and has low false positives. Seamless decoding of BASE64 Subjects (and quoted printables?) is also a good thing(tm). SPF testing and the time-based DOW and HOUR features could be very handy. But for my two cents, I have other priorities: Priority #1 (by far) ==================== I want cleaner logs. This has been discussed in the list before, and I'm pretty sure that Pete and Sandy agreed that they'd seen the behaviour elsewhere, i.e. that multiple processes of writing to the same log file are garbling the text file, and that per se, the garbling wasn't strictly declude's doing. I find that I need to run at loglevel HIGH to get the reporting I need on text filtering, which means bigger log files and presumably more time spent by each instance of declude while it or Windows races to the end of the file to append the text. Without good logging, I'm very much put off my log analysis. Filtering the logs when I get a false positive during my mailserver's "morning rush" is a major pain due to all the overlapping loglines. I can think of a couple of techniques, and I'm a lousy programmer. I don't think you'll need my help there... The simplest thing might be to give us a variable in the global.cfg to turn on file locking, so that we can control whether the performance hit is important in our environment. I realize that would likely add a lot of lines of code to your source, but it could also be trivial to implement inside a function. Sending to a syslog server might also be easy to implement, but the only experience I have with using the logs in a resulting syslog server is with Kiwi, and there, I was using the text log it creates rather than any kind of interface to syslog (I don't know if that's the norm, nor what the IMail users with syslog do with their logging.) Ideally, the logs would be sent directly by declude.exe to an ODBC DSN and the particular SQL database of our choosing, but I know that's really a stretch. Priority #2 =========== I get pecked to death by ducks on the small-weight false positives I get on short text matches that are matching the encoded body of BASE64 attachments. I know that you've mentioned several times before that going beyond the current functionality would require a big leap in going to full MIME decoding, but I hope that my aim is lower: I want to skip matching the BASE64 encoding. Sure, it would also be great to skip decoding MIME attachments that aren't text or HTML (I get false positives on the binary contents of decoded .zip files, too), but that would probably be Priority #3. I know that at least one person on the list relies on declude to match text inside the BASE64 attachments to catch viruses, but perhaps matching that could be toggled with a flag, or make it a new test, e.g. instead of specifying BODY x CONTAINS abcdefghij that this would be appropriate: BASE64CODE x CONTAINS s9Zci6Y4 I haven't thought through all the ways in which a decoder would be useful, so that exact testname might not be appropriate, but hey, it's a start. Thanks for reading this all the way through, Andrew 8) --- [This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)] --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type "unsubscribe Declude.JunkMail". The archives can be found at http://www.mail-archive.com.