How are queue management and statistical content filtering even remotely related to each other? Name some other mail servers that you know combine these processes.
How is it that you can speak so authoritatively about this subject? Unless you tell me that you consulted with IPSwitch on this product, or that you were a design engineer for them, your response is again all so much hokum and mere unsubstantiated mumbo jumbo. Bill ----- Original Message ----- From: "Sanford Whiteman" <[EMAIL PROTECTED]> To: "Bill Landry" <[EMAIL PROTECTED]> Sent: Friday, June 27, 2003 12:30 AM Subject: Re[4]: [Declude.JunkMail] Test on Imail X-header > > 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. > --- [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.
