Please let others know how useful this tip is via the rating scale at the end of it. Do you have a useful Exchange...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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:
- In the registry, go to the subkey:
- 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.
- 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 SearchExchange.com: