> All so much hokum. Not hokum to a commercial developer. Let's see: you've already (1) greatly enhanced interoperability with third-party applications in your new version and (2) greatly enhanced the performance of the underlying platform, thus making the combination of your new version+third-party software much more appealing. So do you then (3a) develop and test another new system service, make sure to parameterize everything under the sun, and slow processing; or (3b) get the d**n thing out the door before your competitors eat away your market share with their integrated anti-spam?
On a specific technical level, if you're suggesting that separate services be used for content scanning and delivery, right away you're talking about doubling the disk I/O load even without Declude, since the file would then have to be read and written by two different processes, as well as IPC overhead. That's not something any sane developer would embark on under deadline: "Hey, boss, give us a couple of weeks to make it slower." Yep, there are elegant solutions that could work around the extra resource usage when Declude wasn't installed, but at the expense of more development time basically sunk into somebody else's product, with only break-even performance for yourself. > a hard-coded split in the spam processing There's no hard-coded split if you use IMail alone, which is the by-design deployment method for IMail anti-spam. IMail's anti-spam implementation depends on IMail's rules engine for postprocessing, and as such has no reason to be more open to third parties. What you suggest would be nice, sure, but Ipswitch is under no ethical or licensing obligation to let third parties use their anti-spam logic, especially not if it costs them development and QA time. In either case, with all the complaints people have had about the insufficiency of the IMail anti-spam implementation (no envelope rejection, etc.), don't you think it would make a bit more sense for them to start by making *their own* part of the equation optimal, instead of spending time "opening" their insufficient existing code? First things first: the major problem with IMail anti-spam isn't the process flow for content scanning, it's the process flow for envelope scanning. After *that's* fixed, worry about where the SendName comes into the overall process flow. :) -Sandy ------------------------------------ Sanford Whiteman, Chief Technologist Broadleaf Systems, a division of Cypress Integrated Systems, Inc. e-mail: [EMAIL PROTECTED] ------------------------------------ --- [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.
