A common strategy for increasing the cost of would-be mail abuse uses a technique called tarpitting. Mail servers that tarpit wait a specified period of time before issuing SMTP responses to the client, thus increasing the time investment needed to successfully send a large amount of mail or a constant stream of (usually invalid) SMTP commands. To minimize the impact on the performance of well-meaning senders, servers can tarpit responses only for SMTP errors and allow authenticated clients to bypass the tarpit time.

Tarpitting is a useful countermeasure for:

  • Dictionary harvest attacks (where an attacker is trying to compile a list of valid e-mail addresses from your organization)
  • User account attacks (where an attacker repeatedly attempts to authenticate via username/password guessing)
  • Spam scripts that send more invalid than valid e-mail recipients.

Most of these abuses depend on quick SMTP server responses to complete in an acceptable timeframe. SMTP servers that tarpit slow down the amount of work they can do in a given amount of time, thereby making the abuse less enticing or lucrative.

Until recently, there wasn’t a way to enable tarpitting behavior for Windows/Exchange. Now, you can.

Simply install the KB:842851 package and KB:885881 package. The only requirement is that you’re running Windows Server 2003 with Internet Information Services 6.0. If you’re running Microsoft Exchange, the package automatically integrates with it.

Then, create/set the following registry key:

            HKLM\System\CurrentControlSet\Services\SmtpSvc\Parameters\TarpitTime (DWORD)

The key value is the number of seconds you wish the server to tarpit error responses. You must stop/start the SMTP service for the change to take place.

When used with Microsoft Exchange Server 2003 features like recipient lookup, tarpitting increases the cost of invalid lookups that makes it harder to abuse the feature to launch a dictionary harvest attack.

- Greg Beitler

Not applicable
Excellent work!

I had a discussion almost one year ago with David Lemson (URL points to the post on his weblog) about this specific feature. It fired discussions on how MS decides and knows about user feature requests. Tarpitting was one of those features I requested: now it's here!

I mentioned in previous posts on David's blog there was (and still is) a content scanning gateway in front of our Exchange organisation. I already have plans layed out to change that: have Exchange use IMF (recipient check), tarpit when needed, and then route back to the content scanning gateway. After the content scan messages will flow into the Exchange org again.

Great to see this feature in the SMTP service!
Not applicable

That article is incorrect. Hotfix DOES NOT install Tarpit fix on Windowss 2003 unless _original_ KB842851 was installed.

WindowsServer2003-KB885881-x86-enu.EXE includes two versions of smtp.dll - GDR (for RTM versions) and QFE (for hotfix version). ONLY QFE version of smtp.dll has Tarpit fix. RTM version does not.

If original KB842851 fix (available from MS) was not installed, it is still possible to replace smtp.dll but that is not supported, of cause.

And the way it works is very simple - it times out SMTP response if reply is not in 250 status. Works perfectly with plain SMTP service and some other sink-based spam filters.
Not applicable
Microsoft today released a hotfix for the Windows 2003 SMTP stack that provides tarpitting for SMTP.... The idea is that you install software that intentionally slows down SMTP throughput for bogus requests.
Not applicable
Great! But what value for tar pit would be the best?
Not applicable
This sounds like a good idea but does it really work? Since address harvesting is automated would anyone really notice or care if a certain domain took longer than another?
Not applicable

You are correct - I fixed the main post. Thanks for keeping us honest! :)
Not applicable
Thanks for the feedback, all!

Peter: You are right in that tarpitting is not an end-all technique for stopping attacks. But raising the cost of an attack helps deter some of them and draws out the others such that a diligant administrator may have measures to detect the traffic and block the IP. So to answer your question, I'd argue that a e-mail organization whose accounts are being harvested would indeed care if it took longer to extract useful information, partially because it increases the chance that it can be detected and corrective measures to be taken.

Tarpitting isn't a replacement for, just something to be used in conjunction with other techniques such as limiting the number of connections per IP/Domain, RBL, address filtering, and traffic monitoring. As some of you might have guessed, there are scenarios where harvesting or mail abuse attacks can span multiple connections, sometimes from a distributed source. These scenarios should be considered as well.

Bernd, this is a very good question. A common number is about 5 seconds. However, if you are a gateway and you are confident that a large number of SMTP protocol errors your servers issue are due to one form of other of abuse, this value can certainly be increased. Keep in mind that a lot of mail servers and clients have a time limit associated with a SMTP session after which it may time out, so this should not be a very, very large value.
Not applicable
Not applicable

Thanks for updating post... Would be great if KB article gets updated too ;-)

As for time setting, I'd suggest more like 30 sec. At least MS SMTP connection timeout is 10 min and other servers usually don't have it less then 1 min.

I'm planning to elaborate on this more in my blog soon...
Not applicable
It looks like you only have to install the 885881 hotfix, then follow the directions in 842851 to configure tarpitting. Is that correct, or did I miss something subtle in one of the articles?
Not applicable
I've just installed package 885881, made the modification to the registry & restarted the smtp-servcie.
After that, people from outside the ex-org were unable to sent any e-mail to any ex-recipients. Everybody got an ndr, that states an authenticaion-error.
Does anybody encounter similar troubles?
Not applicable
To the best of my knowledge, the fix in 885881 should not influence authentication behavior. I'd check your existing authentication settings to see if a setting didn't take and was enacted when you recycled the service... otherwise I'd use message tracking to see where the message is blocked and drill in from there.
Not applicable
Greg presented this Technet evening for me last night.&amp;nbsp; The topic was all about fighting spam -...
Not applicable
Kevin&amp;rsquo;s Webcast Resources:
Exchange Server 2003 &amp;ndash; Tips, Tricks, and Shortcuts
Here are...