The other day I wrote an article on why you should consider limiting the session concurrency to RFC established standards if you don’t have decent perimeter security. Your really should get something, but there is quite a bit you can do yourself to help deal with mailbombs.
Mailbombs, you say? Yes, mailbombs. Kind of like how you spec’ed that server for 10 employees and never considered it would have to one day deal with 10,000 messages an hour? Well, it’s happening. The more systems get owned, the more computers get compromised, the larger the broadcast storms become. And yes, you get to hear it first because I run one of the largest mail networks in the world, but don’t think for a minute that these threats aren’t coming down to you. Over the past week I have been hearing from one partner after another that has his or hers appliance on its knees. Why? The volume is explosive.
And even without perimeter security, there is something you can do with Exchange 2003 alone. Let’s look at some Default bafoonery:
Yes, those are Exchange 2003 default settings. The two of particular interest are the limits for the number of messages per connection and number of recipients per message. You can just look at those limits for a second and note their absurdity – 64000 recipients per message?
Another area of interest is the checkbox next to “Perform reverse DNS lookup on incoming messages” – some folks had a bright idea to use this as an antispam measure. Please do not. If you’re being mailbombed the last thing you want to do is reduce your mail flow to a crawl while you run a DNS query for each incoming connection.
Finally, the least likely option to appeal to you: disable IMF. IMF bayesian (SmartScreen) technology is very expensive when it comes to resources and can easilly exhaust your systems resources during the high load averages – so turn it off and let the workstations deal with the issue. Unless you are rejecting fairly low scores, having IMF around during mailbombs will not help you. Don’t think IMF is killing your box? Get some stats:
You can get performance counters. Two of particularly interesting ones are “MSExchange Intelligent Message Filter \ Total Messages Scanned for UCE” and “MSExchangeMTA Connections \ Inbound Messages Total” which given a little bit of time and resources will show you when you are experiencing spikes and whether you’re truely experiencing a problem to begin with.
Obviously, it is fairly difficult to tell if you have an anomaly if you don’t know what your baseline (“known standard metric” or “business as usual”) numbers are so its important to actually manage your servers. Those tasks, and the above settings and defaults explained in detail is of course a subject for a lengthy article…. but if you’re getting swamped right now this ought to help you out just a little bit while you weather the storm.