Re: [Declude.Virus] EXITSCANONVIRUS

[Darin Cox]

Hi Matt,   I think most of us always consider the "greater good" before making requests... and by their nature, most requests from one person have benefit to many others.   I think the recommendation you outlined below is fairly good...but again, I would not like to see potentially valuable tests removed.  Defaulting to off is good, but removing doesn't make sense when there's value in the test.  Other than an occasional Partial vulnerability, I see no false positives with vulnerabilities from our user base.   I do think your point about moving the code from Virus over to Junkmail is a good one when it is no longer an active vulnerability.  I would just hate to see a valuable test removed, and again, we see a decent amount of spam caught by Virus that doesn't get caught by our Junkmail config.   Code can easily be broken in moving from one place to another (Virus to Junkmail), so this may be a maintenance problem that it is desirable to avoid.  However, deprecated vulnerabilities could potentially be more valuable there for use in weighting or combo tests to identify particular spammers and assist with detecting their payloads.   I think this all falls under the "The more info we have about a message, the better we can classify it" category.  Indeed, one of the main reasons we haven't migrated to SmarterMail is the unavailability of the CMDSPACE test.  We find much of the strength in Declude is due to the variety of special tests Scott was able to come up with.   So, with the caveat of not performing Item 3 in your list (Removal), it sounds very good to me.   It's nowhere near #1 on my list either...just didn't want anything useful to disappear. Darin.     ----- Original Message ----- From: Matt To: Declude.Virus@declude.com Sent: Sunday, May 29, 2005 4:22 PM Subject: Re: [Declude.Virus] EXITSCANONVIRUS Darin, I think there are many different ways to define "retire" in this context. Personally, I have already 'retired' the functionality on my system where I feel that it appropriate, but when I share my opinions and recommendations, I am often thinking of the greater good.  I tend to not ask for things from Declude that would not also be of benefit to a good number of it's users.  While having the switch alone might be good enough for the majority of us on these lists, the majority of Declude's customers don't pay attention to the lists, release notes, or many other things...they tend to run default configurations with very little in the way of tweaks.  These people are most in need of a solution, though they probably mostly don't recognize the issue, and likewise wouldn't recognize the solution.  By Declude providing this functionality and not working it into the overall approach for the best standard config and practices, it really only serves the few of us that are paying very close attention. So in this perspective, the best global approach in my opinion would be to establish a system for depricating such functionality.  I would suggest the following: 1) Active Vulnerabilities - Default to ON, and patch known exceptions that could be triggered by standard E-mail clients.  I would expect that such things would stay in this category for at least a year following a patch being released for the affected E-mail clients. 2) Inactive Vulnerabilities - Default to OFF, don't necessarily patch issues when found (judgment call).  I would expect that this category would include things that were between 1 and 3 years following a patch being issued for the affected E-mail clients. 3) Removal - Remove the code from the executable.  Depending on the conditions related to the vulnerability; i.e. commonality in exploit, potential for false positives, seriousness of flaw, etc., it would be prudent to remove the code that detects such things after 2 or more years.  Note that some of these vulnerabilities have never been actively exploited by viruses.  Being conservative about leaving the code in for long periods I think is fine because they would give people peace of mind and choice, but there is always going to be a legitimate extent to which being conservative about things reach. Regarding their use in blocking some spam, I personally would rather Declude JunkMail tag such things, that way we could handle this as spam, as well as the potential false positives, within the systems that we have built to handle spam instead of the one built to handle viruses.  Active Vulnerabilities are a different story, but I wouldn't object to seeing code added to BADHEADERS/SPAMHEADERS or another built-in test to show that something failed a depricated check within the context of Declude JunkMail.  Some of these vulnerabilities are presently less than 90% accurate on my system in judging between spam and ham, though the viruses associated with them might well be deleted if they do exist and were detected by one of my scanners (I've based this on a review of the spam folder and I delete viruses on my system).  The Outlook CR Vulnerability blocks the most spam, but it also has the highest number of false positives by far.  Web mail generated messages from Comcast, Excite, 126.com/263.com (Chinese equivalent of Hotmail) will all fail Outlook CR in Declude. Does that sound reasonable?  Would it provide for all of what you desire in this respect?  I do get that the folks at Declude do read this stuff and they seem to be embracing our logic and popular opinion on the lists lately, so I would guess that what you think does count for something.  Personally this isn't by far my #1 issue since I have already solved it with other new functionality, but I think the process is just as if not more important as the functionality to the product and the customer base as a whole. Matt