Hello Paul, Thursday, February 21, 2008, 7:52:55 PM, you wrote:
> Ie, ideal for processing/serving 10+ million emails per day in an > imail/declude/snf configuration. SNF seems to generally be the big > processor hog (though the new beta has definitely made huge performance > improvements over the prior version). One of our test platforms uses a single 2.6G processor, IMail, and SNF and consistently handles > 4.6 million messages per day. (Typ 2800 - 4500 msg/minute) Of course, that's a special appliation (pre-screening inbound traps) but it does give a rough idea what is possible in your chosen environment. > OK...this is a bit off-topic, but I'm looking for some feedback in how to > plan for handling this type of load (current load is between 1.3m and > 1.8m/day). > Should I just throw more high performance hardware at it? Probably not. > Scale out perhaps by dedicating a server to just the junk mail scanning. > Then have a relatively wimpy server taking care of normal Imail stuff > (recipient of the declude/snf "clean" and/or "tagged" emails). Two key problems with the IMail platform is that it never stops taking messages and it doesn't support any kind of dynamic connection blocking. Fixing these problems allows IMail to scale to numbers like that. One way to go there would be to set up proxy gateways using eWall in front of your IMail servers. Put SNF on eWall and use it to reject dictionary harvest attacks and possibly even some traffic based on SNF. Definitely use SNF truncate events to add sources to the eWall blacklist. Generally this approach alone will kill off a LOT of traffic that would otherwise bog down IMail/Declude without introducing false positives. You would have many additional options with eWall in this configuration - but you wouldn't need them necessarily and since eWall is amazingly inexpensive you would be getting a big bang for your buck. Your IMail servers w/ Declude could sit behind a pair of eWall gateways (for redundancy) and provide all of the flexibility and additional testing you're used to -- so you wouldn't need to re-tool your infrastructure very much. You probably don't want to scale up using heavy hardware. Instead, use cheaper - more generic hardware and increase your redundancy. One good reason for this philosophy is that if you have a pair of very high - end boxes handling *anything* and one of them dies then it is unlikely the remaining box will be able to absorb twice as much *anything* as it normally handles. In contrast, when one of three moderate boxes handling *anything* the remaining two boxes are very likely to be able to absorb 50% more traffic each. > Along that line of thought, can SNF be configured to work directly with the > MS/IIS SMTP server? This combo could work great as a spam-killing gateway. Yes and no. IIRC, ORF uses IIS SMTP and will tie in SNF nicely. Also - if you have some skills you could tie SNF into IIS SMTP using our DLL (not published yet, but available and in use on a number of proprietary systems). Out of the box we don't have an SNF + IIS SMTP solution (yet). > Has anyone assembled this sort of configuration in a load balanced/redundant > environment? It has been done. Most that I know of who have done this eventually moved away from IMail/Declude as they grew beyond the numbers you're talking about and developed their own proprietary filtering platform (using SNF as it's core) on top of a more robust EMail platform (Communigate for example). Others who are comfortable with mixed environments have deployed SNF in their gateways. The general model for scalability is to isolate inbound gateways, user-centered email servers (pop, imap) and outbound gateways into separate layers with their own redundancies. It is also common for each layer to use it's own hardware and software platforms - each best suited to the specific task. Hope this helps, _M -- Pete McNeil Chief Scientist, Arm Research Labs, LLC. ############################################################# This message is sent to you because you are subscribed to the mailing list <sniffer@sortmonster.com>. To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]> To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]> Send administrative queries to <[EMAIL PROTECTED]>
