How does MailChannels protect downstream systems from dictionary attacks?

A Dictionary Attack Explained

When a sender – usually a spammer – connects to an email server and issues a large number of recipient validation commands (for example, "RCPT TO") in order to determine which addresses are valid in the system, the event is described as a dictionary attack. These attacks can disable an email server, and related systems, by flooding the server with requests that take up significant CPU and memory resources to answer, leaving few resources to process legitimate email traffic. See also http://en.wikipedia.org/wiki/Dictionary_attack for a generic discussion of the concept.

Stopping Dictionary Attacks at Server Level

Many email servers provide dictionary attack prevention methods that involve rate limiting of SMTP responses and/or disconnecting SMTP clients when a certain threshold of invalid recipients has been met during an SMTP session. There's a great Q&A on hardening Postfix against dictionary attacks on Server Fault (http://serverfault.com/questions/115956/stop-postfix-from-gobbling-up-resources-during-spammer-dictionary-attacks).

Unfortunately, the system architecture of most email servers leaves vulnerabilities when it comes to reducing the impact of large scale attacks. The process-oriented model, upon which most email server software is based, allows the email server to handle a multitude of clients at a time by spawning handler processes as needed. Sadly, each process consumes a substantial chunk of memory, and switching from one process to another consumes significant CPU cycles.

Because processes are heavy weight, the only viable dictionary attack prevention method for email servers is to disconnect the SMTP client after it has issued too many failed recipient lookups, and/or to prevent further connections from the client after that point, for a period of time. The client is free to attempt new connections as frequently as is desired, and each new connection attempt consumes CPU resources, even if the connection will be quickly rejected by the email server. Note that the email server has to answer the connection request in order to issue a failure notice over the TCP connection.

Real-Time SMTP Multiplexing to the Rescue

In 2005, MailChannels introduced (to the best of our knowledge) the concept of real-time SMTP multiplexing, which involves placing an efficient SMTP proxy between SMTP clients on the Internet and email servers within an organization. The real-time multiplexing SMTP proxy receives connections using efficient asynchronous I/O (non-blocking I/O processing), and intelligently relays SMTP commands to the email server only in so far as this relaying is necessary to transact the SMTP session.

By being careful about which SMTP commands are relayed, and when, the real-time multiplexing SMTP proxy can protect its downstream email servers from the brunt of a dictionary attack – or indeed any form of SMTP connection attack.

Limiting Sender Behaviour

Today, the MailChannels platform tracks sender behaviour in a powerful time-domain database. Each time the sender does something - such as attempt to validate an invalid email recipient – this event is recorded in the database and time stamped. The database is designed in such a way that it can very efficiently store billions of events, and then respond to time-based queries about these events. For instance, you can ask the database how many invalid recipients a sender tried to validate within a specified time frame.

The MailChannels policy system allows an administrator to create rules that query the time-domain database. To stop dictionary attacks, the administrator simply tells the policy system to limit the allowable number of invalid recipient checks from each sender. If a sender breaches this limit, then further connections can be rejected, whether temporarily or with a permanent failure notice. And because the real-time multiplexing SMTP proxy only contacts the downstream email server when absolutely necessary, new connections from a temporarily banned sender won't result in a flood of TCP connection attempts. The email server is thus protected from the dictionary attack, conserving CPU and other resources for legitimate email traffic and email senders.