> > Open anti virus (www.openantivirus.org) is the most > > promising thing I know of (it's free, which is nice), but > > it's GPL and kind of cludgy as a server. > don 't think free would be the route to go here - i mean, > it's a virus scanning system based against a dat file which > needs to be updated on a regular basis. okay, if you want to > wait for updates, etc. > > but by and large, a relatively inexpensive server side > system backed by a reputable company is the prefered > soluiton.
I agree with Gerhard that what is needed is the ability to have James interact with some widely used antivirus product, in order to have (automatically) very up to date dat files. Now, as an example, let's imagine that we are willing to use Network Associates / McAfee VirusScan in a company (like mine) to scan mail messages. In such a product, as I suppose in others, there is a plugin support for both mail clients like Microsoft Outlook and mail servers like Microsoft Exchange. We want to use for James a support similar to the second one, as we know the first one is too much related to regular client computer updates to be really safe, and is much more expensive. Unfortunately such plugin is made by the vendor itself, and is not available to James. Nor can we use on the server a memory resident scanner (VShield in this example) to scan the messages because it's a closed product and also it's very much OS dependent. But every antivirus product comes also with a command line utility (scan.exe in this example), and perhaps the following would be feasible, and easy(?) to implement: 1) A mailet is invoked whenever a message with attachments comes through. 2) The mailet writes the attachments into a temporary directory. 3) Invokes the scan utility (using java.lang.Runtime.exec ? - that's why I mentioned it on my first posting - sorry for the misunderstanding :-)) on such temporary directory, creating a java.lang.Process. 4) Does a waitFor() on such process. 5) Gets the exitValue() and behaves accordingly. Things to account for: 1) Performance: I feel at the end it would be acceptable. 2) Spoolmanager threads synchronization: I would run the antivirus not asking to clean the infected files, but just to scan and report back. 3) What to do in case an infection is found. 4) Not willing to support a single antivirus product, the command line executed and the exitValue() analysis should not be inside the mailet code, but in the configuration file: the mailet should be "system independent". 5) I don't think that "the server-side automated update of the virus DAT file and engine" should be managed by the mailet; should be left to the antivirus software service options. Another useful thing, and surely easier to implement, would be to have another mailet that just checks the extensions of the attachments, in order to refuse things like .pif, .vbs, .scr, etc and even .exe and .com, if asked for. The idea behind this is that most infections happen because an end user mistakenly opens some kind of infected executable attachment. You can tell him as many times as you want to be careful etc, but it will happen sooner or later, especially if he relies on his resident antivirus, that may have an outdated dat file. If someone legitimately needs to send one of such attachments, he can zip it. > > > Like Noel said, if someone can figure it out and has the > > time, it'd be nice to have. > > working on it .... > Time as usual is the bottleneck. I would enjoy to help doing something (at least the extension mailet), although I haven't yet even had a look on the mailet APIs (will do it soon - promised!), so I don't have a real feeling of the difficulties behind. Vincenzo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
