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
ASKED:
April 16, 2010 2:02 PM
UPDATED:
April 19, 2010 9:34 PM
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.
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.
Without DNS you have no MX records, was DNS rebuilt?
He was referring to rDNS – reverse DNS. Some systems require a rDNS record to verify a sender is valid for the domain.
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.
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.