The MailChannels TrafficControl product reduces spam by throttling the sender so that a spammer will eventually give up. If I explain this to a system administrator it’s commonly met with the question “Doesn’t Sendmail already Throttle?”
I can understand where the confusion arises since the term “throttle” is quite generic and can be applied to any type of restriction or limiting to a resource. So I thought it might be worthwhile explaining things further.
In the case of TrafficControl the entire SMTP conversation is drastically slowed down in both directions to emulate a slow connection. This means that a never before seen zombie sending an image spam e-mail of around 20kB could expect to transfer data at a rate of 15 bytes per second (configurable) which could mean having to hang around for 20 minutes or so. Since the system is designed with SMTP multi-plexing in mind from the ground up it can handle thousands of concurrent connections and legitimate connections are given a fast track to the MTA since they have a good reputation.
In the case of Sendmail, it’s a much different story. In the situation described above, the message from the zombie sender would be delivered in the same way as legitimate mail. The difference is that TrafficControl limits the data rate and Sendmail limits the connection rate which are two very different things. So what exactly does Sendmail throttling do? The following rate limiting features are explained:
ratecontrol – provides a per minute connection rate window that limits the number of connections, usually from a single server. If a connecting server exceeds this quota, sendmail then returns a 4xx response indicating it is temporarily unavailable. This is somewhat useful during a Denial of Service attack from a single machine but not useful against a distributed attack.
conncontrol – whereas ratecontrol limits the rate of connections, it’s still possible for an attacker to gradually build up a pool of connections with Sendmail and eventually exhaust it’s resources. The conncontrol feature therefore provides a limit on the total number of concurrent connections an individual host is allowed to maintain.
ConnectionRateThrottle – is similar to the ratecontrol feature but instead it provides a global per minute connection rate window that isn’t specific to an individual host. This is more useful in the case of a distributed attack. However, it’s still possible for the machines to continually build up connections over a long period of time and exhaust resourcess without hitting this quota.
greet_pause – as the name suggests is the addition of a brief pause in milliseconds before sending the banner greeting message. If a sender attempts to send additional commands without listening for the greeting the connection can be marked bad. This is easily circumvented by most spammers using sending software that actually listens for SMTP replies.
I hope this helps explain the difference between rate limiting connections versus slowing down an entire SMTP conversation to force a spammer to quit. If you’d like more information you can read the following description.