> my approach is from a different angle - where control stays > with the mailet which really just calls an API.
Surely it would be much better, but as you say about the Norman system, it is be more complex to develop, and could be very OS dependent. > 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 agree, but perhaps the message texts could be optionally ignored. > 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. Also the other way would keep the engine and dat file updates outside of James. > 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 .... You are right, this is the main problem, but suppose we are using a blocking call as with java.lang.Process.waitFor(): I could be wrong (have not seen any James code), but wouldn't just one of the spool threads wait (the one processing the current message)? In the default config.xml file coming with James there are 10 threads defined in the spool manager block, so I am inferring that. If it's not that way, forgive me. Now, taking as example the James system I started in my company, there are about 220 users (not big but not small) and in the peak hours there are about 2 messages per minute going on; probably the load would be very low (I will write a small java routine executing virusscan in a loop scanning some attachments to get an idea of the potential cpu load). > 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. Why per mailbox? Vincenzo --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
