Enabled by default: SMTP Tarpit in Exchange Server 2007

From a recent discussion, and something I've been wanting to post about for a while: SMTP tarpitting is enabled by default on ReceiveConnectors in Exchange Server 2007.

What is tarpitting? It's the process of introducing a delay in SMTP connections from hosts that are suspected of inappropriate SMTP behavior - for instance, by sending messages to non-existent addresses in your domain. (Tarpit is a noun, I use tarpitting as a verb to describe the process. The word probably can't be found in a dictionary, but perhaps appropriate usage to describe the process, just like telnetting, and emailing - Bharat)

If you've used Recipient Filtering on Exchange Server 2003 and selected the option to drop messages for recipients that do not exist in AD, it's a best practice to use SMTP tarpitting to get some level of protection from directory harvesting attacks. Directory harvesting is typically used by spammers to send email to addresses in your domain - which may or may not exist in your directory - to figure out which addresses are valid and which ones are not.

With the option in Recipient Filtering enabled, the SMTP virtual server will respond with a 550 error (550 5.1.1 User unknown) when it comes across an email address in the message's RCPT TO command - before the message body is transmitted. With tarpitting enabled, this response is delayed a few seconds, configurable using a registry setting (in Exchange Server 2003 on Windows Server 2003 SP1 - it is a Windows Server 2003 feature), as described in Microsoft KBA 842851. Most spammers will drop the connection if there's such a delay - it is more expensive for spammers to continue spamming/harvesting with such delays in place.

Does this sound too good to be true? What's the down side? Or are there any? On servers with high volume of SMTP traffic, you may notice more open connections, and open connections consume resources. The trick is to make sure this delay is not too high, resulting in more open connections for much longer, but high enough to make the sending hosts displaying suspicious behavior to drop connections.

Having said that, I've not come across many cases of performance degradation that could specifically be attributed to tarpitting delays, but you'll need to test this in your environment to figure out what works best.

Also note, authenticated connections are not subjected to tarpitting delays. Additionally, tarpitting only makes sense on ReceiveConnectors exposed to internet hosts.

Exchange Server 2007's ReceiveConnectors are configured with a tarpit interval of 5 seconds by default. A good way to observe this behavior is by telnetting to the SMTP port of an Exchange Server 2007 server and first sending a message to a valid recipient, and then trying to send a message to a recipient that does not exist.

To check the SMTP tarpit interval on your ReceiveConnectors, use the following shell command:

get-ReceiveConnector | select name,tarpitinterval

You can set it to a higher value - I have mine set to 10 seconds - using set-ReceiveConnector:

set-ReceiveConnector "Receive Connector Name" -tarpitinterval 00:00:10

The value is in hours:minutes:seconds.

At the time of writing, the documentation for set-ReceiveConnector command says this can be set in days as well (number of days and number of hours separated by a dot), but further it also states the maximum value for tarpitinterval is 10 minutes (00:10:00) - which is confirmed by the shell when you try to set it to a value higher than 10 minutes. (Nevertheless, technically speaking the documentation isn't wrong - you can in fact set it in days - e.g. 00.00:09:00 - as long as the value of days is zero! :) I'm told the doc will soon be changed/corrected).

To disable the tarpit behavior, set the value to 00:00:00.