We've been on record for some time as liking spam control defenses that operate at the protocol level -- IP, TCP, and/or SMTP -- as opposed to those that operate solely by analyzing message content. This is one of a series of bulletins that talks more about this, and examines two technologies that implement such controls.
MailChannels' Traffic Control represents another approach to anti-spam defense at the protocol level. It differs from the Symantec Mail Security 8160, both in being a Unix (Linux, BSD, Solaris) software-based solution (as opposed to being an appliance), and operating at the SMTP level (as opposed to the IP packet level). As such, it constitutes "another way to skin a cat."
One or more Traffic Control instances augment an organization's existing boundary MTAs by becoming the target of TCP connections from remote SMTP senders. Unlike the 8160, no TCP connection to port 25 is ever rejected, but like the 8160, boundary MTAs are blissfully unaware (at least initially) that this has occurred. Stated another way, Traffic Control can support a very large number of simultaneous connections, while boundary MTAs support only a few.
Both the bandwidth allocated to that connection and the speed at which SMTP responses are returned will be varied. This is dependent on the reputation and behavior of the SMTP sender (detected operating system, protocol compliance, etc.). The underlying assumption is that when slowed down in this way spam sources will simply give up -- especially zombies. Meanwhile, misclassified SMTP clients -- which may otherwise be false positives -- will persist.
Traffic Control interacts with an organization’s existing boundary MTAs in two separate ways. We'll call these command mode and data mode. Both command and data mode interactions take place over a pool of persistent TCP/IP SMTP sessions that Traffic Control maintains with a boundary MTA.
Command mode is necessary because Traffic Control is unable, on its own, to validate SMTP source (MAIL FROM) and recipient (RCPT TO) addresses. It requires a boundary MTA to do so. To achieve this, Traffic Control plays (EHLO, MAIL FROM, RCPT TO, ... , QUIT) command sequences to a boundary MTA in a rapid command burst. It then both relays the responses, with suitable delay, to an initiating SMTP client, and takes any subsequent action required.
Next comes data mode. Once SMTP source and recipient addresses have been validated, an SMTP DATA transfer can take place. This occurs solely between an SMTP client and Traffic Control and may be subject to bandwidth limitations -- depending upon the reputation and behavior of the SMTP client. Only once an entire message has been received by Traffic Control is it relayed in message mode as a complete (EHLO, MAIL SMTP, RCPT TO, ..., DATA ..., QUIT) command sequence to a boundary MTA.
Traffic Control software can either run on its own hardware platform or be co-located on the same hardware platform as a boundary MTA.
On a personal note, I am able to report that I have been running an instance of Traffic Control in my own network for four months, and that it has reduced the volume of spam hitting my boundary MTAs on most days by approximately 95%.
... Nick Shelness