Holy cow - 6,000 connections!?! Isn't that going to blow up my server? Well, not if your software is specifically designed to handle high concurrency. For detailed reading on the subject, I suggest you read the literature on the so-called c10k problem ( great summary at kegel.com).
Most mail servers (for example, Postfix, Sendmail, Exim, and qmail) use one operating system process per connection. While this software design is simple and straight forward, it is also resource-intensive. Processes consume huge amounts of memory, and switching between them efficiently is hard to do.
If you have read our Trick Blog Series and have an understanding of what happens to spambots when they are slowed down, you'll know they disconnect, and disconnect very quickly. In fact, more-often-than-not, spambots disconnect before they even receive the whole banner. In those cases you have received zero bytes from them, and all you have had to do for that connection is retain a few bytes for storing the connection information and then every few seconds send out a few bytes of the banner. In a highly-optimized single-threaded C process how many of this type of connection do you think you could handle simultaneously without even putting a dent in the system load?
Even after rejecting connections upfront with RBLs, such as the very accurate Spamhaus RBL, your content-filter would usually have to scan all these messages. Now these messages do not even exist on your system, since the sender chose to disconnect.
It is common to see 75% less rejects by the content-filter due to this behavior. That is 75% less work your content-filter needs to do scanning bad messages. Content-filtering is by-far the number one resource-heavy tool in your email delivery infrastructure. Hopefully, by showing how you can greatly decrease this, we have shown you how traffic-shaping can use less resources, not more.