Windows-based SMTP Tar Pitting Explained
Introduction to the SMTP Tar Pitting Feature
SMTP Tar Pitting is by no means a new technology, well it’s relatively new for Windows-based SMTP servers. It was first introduced as an update (see MS KB article 899492), but is also included with Windows 2003 Server Service Pack 1. A similar method has been used in *NIX environments for many years, here it primarily goes under the term “teergrube” which is “tar pit” in German.
SMTP Tar Pitting can be considered a primitive form of “teergrubing” as it doesn’t offer all the meat and potatoes of “teergrubing”. Basically a SMTP Tar Pit is nothing more than a SMTP transaction delay, a “teergrube” is more than that as it, amongst other things, also can be a server that directs spammers to it, and thereby lets them waste precious time talking to it. You can read more about “teergrubing” here.
Enough “teergrubing” talk! As mentioned SMTP Tar Pitting is a method with which you can delay or slow down server responses for certain SMTP communication patterns, more specifically, responses containing 5.x.x error codes (for a list of 5.x.x error codes see MS KB article 284204). These error codes are typically associated with spam traffic or other unsolicited commercial e-mail (UCE). The intention for the SMTP Tar Pitting feature is to delay or slow down spam sent to a large number of non-valid e-mail addresses for a specified number of seconds. What this means is that it prevents a SMTP server from processing large amounts of unnecessary spam mail, for example from a directory/dictionary harvest attack, SMTP Auth attack, spam bots/scripts, or a list of possible e-mail addresses (all widely used techniques in the spam community).
If you rely on the e-mail filtering features in Exchange server 2003, chances are you have enabled the Filter recipients who are not in the Directory feature, which is both good and bad. Good because the server filters messages sent to non-existing recipients early in the SMTP conversation (meaning you don’t have to return an NDR to the sender who, if speaking to spammers often, uses a spoofed domain anyway). Bad because spammers may discover valid e-mail addresses in your Exchange Server organization (when recipient filtering is turned on it reveals whether an e-mail address is valid or not during the SMTP conversation). So you can see why using the SMTP Tar Pitting feature in conjunction with the Exchange 2003 Recipient filtering feature can be a good idea right? Okay for those of you who still don’t, take a look at Figure 1 and 2 below.
Figure 1: E-mail address harvest attack without SMTP Tar Pitting enabled
Figure 2: E-mail address harvest attack with SMTP Tar Pitting enabled
Some of you might think it would be better to simply turn off recipient filtering, rely on your 3rd party antispam product, and suppress NDRs (as spammers typically use spoofed domains anyway). This is possible but unfortunately doing so breaks RFC 2821, which states that a NDR must be returned if an e-mail message for an invalid recipient is accepted. In addition it also means normal users that perhaps make a typo in an e-mail address will never receive an NDR informing them of the issue.
It’s important to understand that enabling the SMTP Tar Pitting feature does not prevent an attacker from attacking your environment, although it does slow down the rate of processing considerably, which results in the attack becoming much less worthwhile or troublesome for the spammer. SMTP Tar Pitting is also NOT a security hotfix that should be installed by each and every Exchange Administrator around the world, instead consider it a feature that, depending on your Exchange environment, may or may not be useful. In other words, don’t rush out and enable the feature unless you have a valid reason for doing so.
If you’re relying on the native Exchange 2003 recipient filter, implementing the SMTP Tar Pitting feature will, in most situations, be beneficial to you.
Implementing SMTP Tar Pitting
As the SMTP Tar Pitting feature was introduced as a separate update as well as included with Windows 2003 Server SP1, you first need to apply SP1 before you can enable the feature. Administrators who for some reason haven’t applied Windows 2003 Server SP1 yet (and still don’t want to in order to implement SMTP Tar Pitting) can still obtain the separate update (read more about the update in MS KB article 899492) by contacting Microsoft Support Services.
The SMTP Tar Pitting feature is not specific to Exchange Server 2003, which means you can implement it on regular Windows 2003 Server SP1 servers that perhaps have been setup as SMTP gateways relaying messages to your Exchange 2000/2003 Servers. Bear in mind too that enabling the SMTP Tar Pitting feature only effects anonymous SMTP connections; this means you only have to enable the feature on the SMTP servers facing the Internet.
Enabling the SMTP Tar Pitting feature can slow down legitimate traffic as well, so be sure to keep an eye on the performance of the SMTP/Exchange server.
In order to enable the SMTP Tar Pitting feature you need to add a new DWORD Value key named TarpitTime to the registry, to do so click Start > Run and type Regedit, then navigate to the below registry subkey:
Here you should right-click the Parameters subkey, then select New > DWORD Value. Name the DWORD Value TarpitTime and click Enter. As the TarpitTime key now has a value of 0, it means it's disabled therefore you should right-click on it and select Modify in order to change the Data value. The number you specify in the Value data box is the number of seconds the SMTP service should delay responses that contain SMTP 5.x.x error codes (for example SMTP address verification responses for addresses that do not exist in your organization). As 20 seconds is a good starting point type 20 in decimal (as shown in Figure 3 below) then click OK.
Figure 3: Adding the SMTP Tar Pitting Registry Key
Now close the registry editor and restart the SMTP Service.
In order to give you a better understanding of the SMTP Tar Pitting features efficiency, I thought it would be a good idea to provide you with an example. Imagine a spammer sends a message to 15000 recipients in your organization, you have enabled a Tar Pit time of 20 seconds. This means there will be a 20 second delay between each message, try multiplying that with 15000 (recipients), yes that’s 300000 seconds. Now divide 300000 with 60, we get 5000 minutes. 5000 minutes divided by 60 is close to 85 hours! Now talk about a delay! Wouldn’t that make even the most patient spammer in the world think the connection had stalled or something, and then give up? I believe so.
By enabling the SMTP Tar Pitting feature which is available as a separate update (see MS KB article 899492) as well as being included in Windows 2003 Server Service Pack 1, some organizations can reduce the amount of spam and other unsolicited commercial e-mail (UCE) they receive as the feature delays or slows down server responses for certain SMTP communication patterns, more specifically 5.x.x error codes. The feature becomes especially useful if you’re already using the Exchange Server 2003 recipient filtering capabilities such as the Filter recipients who are not in the Directory functionality as this feature has the drawback of enabling directory lookup for recipients during the SMTP conversation. This means senders of spam and other unsolicited commercial e-mail (UCE) may be able to discover valid e-mail addresses in your organization. Enabling SMTP Tar Pitting makes it much longer to, for example, perform a directory harvest attack, of course depending on the amount of seconds you specify in the TarpitTime DWORD registry key. This will, in most situations, result in having even the most patient spammer in the world give up on your servers and move on to the next target.
As always I hope you found the article useful. If you have any questions, comments or other feedback please post them to the thread below on the MSExchange.org Message boards:
SMTP tar pit feature for Microsoft Windows Server 2003:
A software update is available to help prevent the enumeration of Exchange Server 2003 e-mail addresses:
SMTP Session Tarpitting for Windows 2003 and Exchange: