>After reading the archives (thanks all!) for most of the afternoon, I'm >still on the fence with what to expect from Declude. I run an ISP that >gets over 100k emails inbound a day, and the hardware handles it >nicely. SMTP normally never claims more than 20% of available cpus for >both in and outbound traffic. > >Here are the questions I've made sofar: > >Given the above info, what can I expect the overall processor 'hit' to be >on incoming filtering only?
At 100,000 E-mails/day, you shouldn't have a noticeable performance hit. Depending on your settings, you could even see a slight improvement (if spam does not have to actually get delivered to mailboxes). >Does Declude utilize more processing power if I use more checks? Yes, but not much more. The DNS-based spam tests use very little CPU time. >Are checks run simultaneously, or linearly? Each type of test is run simultaneously. So all the ip4r tests (the standard DNS-based spam tests) are run at the same time. >I've read that smtp32.exe is replaced by declude.exe. Not quite. What happens is Declude uses a registry hook to let IMail know to call declude.exe rather than smtp32.exe, and then Declude is responsible for calling smtp32.exe. >Does Declude utilize multi-processors? Yes, it does. >Does declude.exe run as a single process, or in a one-spawned-per-message >sort (similar to smtp32.exe). It's one-spawned-per-message, like SMTP32.exe. >Can I use an "allow this message to process, but save a copy for further >review" type action? No. >Does the HOLD action allow for easy respooling of an offending message? The easy way is to use the Spam Review Software ( http://www.slsoft.com/spamreview.htm ), which helps automated the process of viewing held messages and respooling them. Otherwise, you can copy the D*.SMD and associated Q*.SMD file back to the \IMail\spool directory, and IMail will send it out on the next queue run. >Does an imail serverwide or domainwide filter process the message before >or after declude does? It will process the E-mail after Declude. The IMail SMTP Control Access and Kill List will be processed before Declude. >Do you have (or can you suggest) any suggested configs (paid and non-fee) >that have a low count of 'real' messages being trapped? > >Do you have (or can you suggest) a list of "these hosts must be >whitelisted to keep your users from killing you", or similar? I'll let others comment on these questions. >What (if any) are the known issues with integrating with McAfee's SMTP >Virus Scan (not on same machine) ? The main problem is that many/all versions of McAfee's WebShield SMTP anonymize the IP address of the spammer, removing it from the E-mail headers. If your version does this, your ability to detect spam will be greatly reduced, as the spammer's IP address is one of the most important pieces of information in determining whether or not an E-mail is spam. If you can post a copy of the complete headers of this E-mail (or just all the Received: headers), I can let you know if your version hides the IPs or not. If it does hide the IPs, I would suggest upgrading to see if the latest version fixes the problem. If not, I would suggest complaining strongly to McAfee; I can't see how they can get away with this (theirs is the only mail server I'm aware of that hides the IPs). If that doesn't work, I would be happy to set you up with a 30-day free trial of our Declude Virus software. :) -Scott --- [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". You can E-mail [EMAIL PROTECTED] for assistance. You can visit our web site at http://www.declude.com .
