Trends Why Traffic-Shaping Uses Less Resources, Not More By Phil Whelan | 3 minute read What happens when you start slowing down inbound SMTP connections? The assumption is often that the number of connections will go up (a lot) and that the increased connection load will cause an increase in system load, rather than a decrease. Some basic math will help us understand why people have this concern about load: In other words, as the amount of time it takes to process a connection goes up, the number of concurrent connections should also increase. Average connection duration in a modern, busy mail server is on the order of one second or less – that is the amount of time it takes to receive a message and queue it for delivery to a recipient. So if your mail server is receiving 100 connections per second and each of these is processed in one second, you would expect there to be an average of about 100 concurrent connections established with the mail server. Now, let’s introduce traffic shaping on some of the connections. Using real data from MailChannels customers, let’s assume that one third of the connections are slowed down such that it takes 180 seconds to process the connection. The rest of the connections we’ll assume complete in just 1 second. Our average connection duration is now 60 seconds: With an average connection duration of 60 seconds, the number of concurrent connections is now expected to be much higher: 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.