Extremely slow RCPT TO on Exhange 2003 SP2 causing 421 errors on emails
I have an Exchange 2003 SP2 server on Server 2003 standard, that the RCPT TO is taking over 30 seconds to respond which in turn is causing "421 Timeout reading command response" NDR's. I have eliminated the SMTP proxy on the firebox by chaning it to a simple packet filter and turned off GFI MailEssentials. I eliminated the Internet connection also.
I am testing the response with Telnet to port 25. Telnets from the outside and inside both take upwards of 30 seconds to respond to RCPT TO commands. I turned off port 25 on the firewall so there were no external connections to the SMTP virtual server when I tested telnet from the server itself to itself. It still takes 30+ seconds to respond. I checked for the tarpitting registry entries but they don't exist so that can't be the problem.
I've eliminated down to the Exchange server itself. There aren't external speedbumps causing this.
HELP!!!!
I am testing the response with Telnet to port 25. Telnets from the outside and inside both take upwards of 30 seconds to respond to RCPT TO commands. I turned off port 25 on the firewall so there were no external connections to the SMTP virtual server when I tested telnet from the server itself to itself. It still takes 30+ seconds to respond. I checked for the tarpitting registry entries but they don't exist so that can't be the problem.
I've eliminated down to the Exchange server itself. There aren't external speedbumps causing this.
HELP!!!!
LeeDerbyshire
Just a guess, but do you have 'Filter Recipients who aren't in the Directory' enabled in Message Delivery/Recipient Filtering ? If so, then maybe the directory lookup is slowing it down.
ASKER
No, its not enabled
ASKER
I solved my own problem. Symantec Mail Security was installed and there was a problem with having many RBLs installed. I removed them and it works like a charm.
Saratoga -
Thanks for posting your self discovered solution. It helped me find a similar problem in SMS. My issue was DNS related, but that caused SMS to fail resolving the RBL addresses which caused a long delay in RCPT TO response.
As soon as I eliminated all RBL's from SMS mail started to flow.
Give yourself 500 points on me!
JR
Thanks for posting your self discovered solution. It helped me find a similar problem in SMS. My issue was DNS related, but that caused SMS to fail resolving the RBL addresses which caused a long delay in RCPT TO response.
As soon as I eliminated all RBL's from SMS mail started to flow.
Give yourself 500 points on me!
JR
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I'm having same issue and the "solution" was the same. After removed SME everything works fine. What is funny is guys use to relate same producer products issues to Microsoft only... This one appear to be one Symantec only issue :-(