Exchange 2007 cannot send mail to many domains

2015 pts.
Tags:
Exchange 2007
Exchange Server 2007
IP address
SMTP transmission failure
Windows Server 2003
Windows Server 2003 administration
I've been having a problem with my Exchange 2007 server (up-to-date on patches) running on Server 2003 R2. About a week ago, it stopped processing mail. I was able to restore teh ability to recieve mail with no problem, but sending mail is still a problem (we do have a work around in place right now). It will successfully contact and connect to the recieving server, however when the RCPT TO: command is issued, it times out, or is not accepted by the recieving server. The same behavior occurs when using TELNET to the same servers. The error issued is 4.4.2 Connection dropped. I first suspected that somehow we had ended up on an RBL. Well, we had but it was one of those that blocks blocks of addresses (in our case the whole Class C we are on) and thus is little used, since it blocks many valid addresses. During this period of discovery, I found our rDNS had vanished, which was requested, and done, to be replaced, but no explanation as to why it had vanished--I suspect a tech made an error. Even so, we are still having the problem. We are now discussing building a new server, but are unsure if this will resolve the issue, and are hesitant to put the time and money into buildin g a new server if we do not have to. We have done, among other things, turned off the A/V even though the Exchange directories were excluded from scanning, changed the public IP address, check to ensure no changes had been made between working and not working (when every one is a tech . . .), scanned everything wxcept the Information Stores, with two A?V products other than what we use (clean), and still no joy. Does anyone have any ideas?

Software/Hardware used:
Exchange 2007, Windows Server 2003 R2

Answer Wiki

Thanks. We'll let you know when a new response is added.

When you test using telnet, do you go from the Exchange server or a client machine? Do you get the same results from a client machine?

Has something changed on your perimeter firewall connection? Try using <a href=”http://www.wireshark.org”>Wireshark</a> or Microsoft’s Network Monitor to capture traffic to/from the Exchange server and see which end of the conversation is dropping the connection.

+++++++++++++++++++++++++++++++++++++++++++++++++

I would verify that your recovered Exchange Server (mailserver.internal.corp) is sending as your public mx record (public.domain.com). The settings should be at your hub transport.

Discuss This Question: 6  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • Stevesz
    TELNET from another machine is generally successful. Fat fingering has an adverse response <g>. RCPT TO: with the address is posted, no reply from the receiving server. Firewall has been checked and refreshed.
    2,015 pointsBadges:
    report
  • Labnuke99
    Do some packet captures during a telnet session test from the Exchange server. See if any RST or FIN FIN/ACK packets come from any hosts along the path to cause the connection to drop. It could also be that the telnet session is being sensed by the remote server as being run by a human, so command timing could be a problem. Consider using some type of SMTP client which can generate the commands faster than a human can type. I have an old application called Genius 3.2.2 that I use for this purpose but I cannot find it on the internet any more and the locations where it looked like it may be available are of questionable integrity. I did find another tool called SMTPTools at Tucows that might fit the bill for this purpose. I tested Popcorn from Ultrafunk (now defunct <g>) and it seems to do the trick for quickly sending messages using SMTP. Neither of these tools require installation and can be used from client or server. Hopefully this will help you track down the issue.
    32,960 pointsBadges:
    report
  • Technochic
    Without DNS you have no MX records, was DNS rebuilt?
    57,010 pointsBadges:
    report
  • Labnuke99
    He was referring to rDNS - reverse DNS. Some systems require a rDNS record to verify a sender is valid for the domain.
    32,960 pointsBadges:
    report
  • Stevesz
    I doubt I'll have the time to do anything that until at least Monday. I just got back in and have a stack of work orders on my desk to enter, as well as the ones I did today, in hope they will be billed by Monday, and I'll be on site most of Saturday. I am sure that the SMTP is coming from the Exchange server public IP address. Checking test mails sent to the few domains I am actually able to get mail through to, the headers show the correct from IP address and checking with several of the online testers shows the correct IP. I've downloaded both of the programs you mentioned, and will log into the server first chance and give them a whirl. I do appreciate your help. To Technochic: the problem was not with DNS, but with the PTR record, which is commonly called rDNS, or reverse DNS. The problem is that I need to rely on Verizon for that record as they normally advertise it as something else. That has been fixed.
    2,015 pointsBadges:
    report
  • Stevesz
    Labnuke99, I did run some packet captures today and it appears that the receiving server for my outgoing messages is sending the timeout to my server. I'll start trying to develop some good Google searches to see what I can come up with to resolve this issue and make my server react faster in response.
    2,015 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following