Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 1 down vote favorite

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 mail.xxx.com 25)

220 mail.xxx.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.6713 ready at  Fri, 16 Oct 2009 09:42:20 -0500
HELO
250 mail.xxx.com Hello [172.16.128.42]
MAIL FROM: dms@xxx.com
250 2.1.0 dms@xxx.com....Sender OK
RCPT TO: ttheisen@xxx.com

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

250 2.1.5 ttheisen@xxx.com

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

2 Answers

up vote 2 down vote

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 xxx.com.
  • 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
up vote 1 down vote

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 172.16.128.42? If not, that is most likely the reason for the long pause...

share|improve this answer

Your Answer

 
discard

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.