Problem solve Get help with specific problems with your technologies, process and projects.

Fighting spam with SMTP 'tar pits'

Windows Server 2003 Service Pack 1 has a built-in tarpitting function that works with the included SMTP server or Exchange Server 2003. Learn how you can use it to reduce spam and spam-related attacks on your network.

Please let others know how useful this tip is via the rating scale at the end of it. Do you have a useful Exchange or Outlook tip, timesaver or workaround to share? Submit it to our tip contest and you could win a prize.

"Tarpitting" is a way of reducing spam or spam-related attacks (such as directory harvesting). It involves delaying SMTP communications with remote servers suspected of sending unsolicited e-mail. This slows down mail processing on the spammers' end, so they can't bombard you as quickly or perform dictionary attacks as efficiently.

Windows Server 2003 Service Pack 1 now has a built-in tarpitting function that works with the included SMTP server or Exchange Server 2003.

The tar pit delay kicks in whenever an SMTP conversation with a remote server (i.e., whenever Exchange receives SMTP-relayed e-mail) produces a 5.x.x-type error code on your end. For instance, if a remote server tries to send e-mail to a nonexistent user, your server delays any further conversation with that server for a predetermined length of time.

Enabling tarpitting in Windows Server 2003 is simple:

  1. In the registry, go to the subkey:


  2. Add a new DWORD value with the name TarpitTime and a decimal value registered in seconds. This is the length of time to wait when an error takes place, as described above. For example, if you set TarpitTime to 5, wait time will be five seconds.

  3. Stop and restart the SMTP Service.

Since most mail systems use a one-minute timeout for mail conversations, some administrators use delays of up to 90 seconds. But 20 seconds is a good starting point and shouldn't create too many adverse side effects.

Not everyone should enable tarpitting though.

If you use third-party antispam products that do a good job, tarpitting may do more harm than good.

Using tar pits may also make things difficult for legitimate users. For instance, if someone misspells the e-mail address of an acceptable message sent to you, and the tar pit time is set way above the timeout threshold tolerated by the sender, the mail in question will never even get a non-delivery report from your server.

The sender should get a problem report from their own SMTP server telling them that the mail in question could not be delivered -- but with a slightly misleading "Recipient timed out" error, rather than the proper "Username not found" error. (This could cause the administrator of the remote host to wonder, incorrectly, if there's something wrong with his network or the routing to the remote host.)

Tarpitting also works best when both recipient filtering and authenticated sessions are in use.

Recipient filtering lets you immediately reject e-mail that doesn't match anyone in your organization (which protects against dictionary attacks). It's useful when combined with tarpitting, since the majority of SMTP sessions trapped with tarpitting usually involve sending to invalid addresses.

Since tarpitting only works on anonymous SMTP sessions, if you exchange mail with other servers that authenticate, they can avoid any problems associated with tarpitting.

About the author: Serdar Yegulalp is editor of the Windows Power Users Newsletter.

Do you have comments on this tip? Let us know.
Related information from

  • Learning Center: The spamfighter's toolbox
  • Step-by-Step Guide: How to use ISA Server as an SMTP filter
  • Reference Center: Tips and resources on spam prevention and management

  • Dig Deeper on Legacy Exchange Server versions

    Start the conversation

    Send me notifications when other members comment.

    Please create a username to comment.