Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I try to send email through Exchange 2003 via an SMTP connection, I get a strange delay after specifying the recipient. Here is a telnet log, with a redacted domain name: (telnet 25)

220 Microsoft ESMTP MAIL Service, Version: 5.0.2195.6713 ready at  Fri, 16 Oct 2009 09:42:20 -0500
250 Hello []
250 2.1.0 OK

After a delay of a minute or so, (it seems to vary) I get this:

250 2.1.5

Although the exact delay varies, it's always a significant delay.

However, when I repeat this exact same transaction from our intranet server, there is zero noticeable delay. I'm really more of a software developer than an admin, and I just can not figure this out.

Anyone have any idea what could cause this?

share|improve this question
up vote 2 down vote accepted

Are you an admin of this Exchange 2003 server, do you have access to the configuration? It could be a few things:

  • Antispam mitigation, some servers add a delay onto the transaction to slow down spammers. AKA Tarpitting.
  • If domain resolution is being done during this process, it is possible there is a problem with resolving
  • Some other custom program or processing done on the recipient email address.
share|improve this answer
It's not tar pitting, as this is Windows 2k. Since these are all the same internal domain, I don't understand how it could be name resolution, but I'll check on the other two. Thanks for the good leads. – recursive Oct 16 '09 at 15:11
Exchange 2003 includes a tarpitting option (regardless of underlaying OS). What you stated sounds exactly like tarpitting, I would really check there first. Might be under some sort of "anti directory harvesting" option. – Dave Drager Oct 16 '09 at 15:20
Thanks for the direction. Not positive it's tar pitting yet, but I have found that authenticating the session eliminates the delay. – recursive Oct 16 '09 at 15:23

Another possibility is that Exchange is doing a reverse DNS lookup (PTR) on your client address to check that you are who you say you are. Using NSLOOKUP from the exchange server, can you get a PTR record returned from If not, that is most likely the reason for the long pause...

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.