my approach is from a different angle - where control stays with the mailet which really just calls an API.
also, I wouldn't limit this to attachments but to everything (except encrypted of course) and I would make an arbitrary decision and Ghost the mail. i am looking at a system called Norman - comparable to McAfee and Symantec but not as expensive - which has a rather good SDK kit; but it's C based and a COM bridge would be needed which i am not too keen on. this would, however, keep the engine and dat file updates outside of James which is good. shelling out a process and then 'tracking it' is not as simple as it sounds and will definitely impact performance; in a sense you'd be setting up a 'sub-spool'... for each mail that you run the external process on needs to be matched up with it's response. either that or use a blocking call .... as for the file extension mailet, that would be rather easy; but i am not sure on it's overall usability as it would need to configured per mailbox. > I agree ... > 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. > > > 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. > _______________________ thanks, alan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
