• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 467
  • Last Modified:

Exchange 550 'mailbox unavailable'

Here is the scenario:
We are running one Exchange 2003 server in a small network; server has been running without any issues for years. Server is not blacklisted. Internal email and incoming email are working fine.

The MX record is not the same as the PTR record because the server is collocated and there are 2 outside addressing schemes, one for the LAN, and one for the ISP that controls the pipe to the colo.

Problem:
The PTR record resolves correctly; but suddenly outgoing mail stopped working. The PTR record was established to make SMTP work.  I have an explanation for this that I could post.

I noticed after the outgoing emails stopped, that the machine that holds to PTR record is not reachable by tracert or ping.
The ISP, controller of the PTR record server, claims that the machine does not need to be reachable, as long as the PTR record is resolving on the internet. (really??) MXtoolbox shows the PTR resolution is good and the MX record is good, but the SMTP test there fails.

What I did:
I added 8.8.8.8 to the Exchange servers sender ID and filtering section as external DNS, and most mail now goes out.  (this tells me that the path usually used for SMTP was dead i.e.. (no tracert to the server whose address I was using before this started).  
I looked for answers all over forums but found nothing definitive.

However, some emails are still failing to go out unless I add an SMTP connector for each failed domain recipient.  So far I have added a dozen.   This is getting old. Many of the required additional SMTP resolve to outlook.com.

Question:  what is the real cause of the failure message #5.5.0 smtp;550 Requested action not taken: mailbox unavailable>  Why does adding an SMTP record work, is there a better way, a final fix?
0
quaybj
Asked:
quaybj
  • 4
  • 2
2 Solutions
 
Will SzymkowskiSenior Solution ArchitectCommented:
Take a look at the below link which is the great table for 2003 and NDR's.
http://www.computerperformance.co.uk/exchange2003/exchange2003_NDR.htm

Will.
0
 
footechCommented:
SMTP delivery is possible without a PTR record, it's just that many recipients do a check of the PTR record as an anti-spam check.  Many recipients will also check the sending IP's PTR record and verify that for the name referenced by it, there is an A record with the same name which resolves to the same IP.

It's not necessary for the the sending server to respond to pings.

To me it sounds a bit like you're having name resolution problems.  I would verify name resolution for a variety of domains from the Exchange server.
0
 
quaybjAuthor Commented:
Footech,

I  accept that the sending server does not have to respond to pings.  Does the same go for tracert even after 80 hops?  

Through dcdiag, I did find an internal  DNS replication issue, and invalid root hints.  which  I have to deal with before I can move forward.  The Exchange server is trying to talk to an AD server that is slow and far away (and not replicating), instead of to the one right next to it in the rack.  This might be the issue, but.....

Meantime, I also found that just about all of the SMTP errors are coming from a server hosted by Microsoft.  the full message is The remote host "65.55.92.168", responded to the SMTP command "rcpt" with "550 Requested action not taken: mailbox unavailable ".  Why is this particular server involved and the one causing all the issues?  It's giving this response and failing spam as well as legitimate messages.

I used smtpdiag and dnsdiag and found that the server is resolving on external email  domains 100%, but email sent to those domains is still failing. I continue to create connectors for each failed domain and this continues to work every time.

I found the Exchange 2003 routing document and am reading it.  

Further thoughts?
0
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

 
footechCommented:
I don't understand the question about tracert.  Tracert essentially tries to ping all the routing points along a network path.  80 hops is a lot.  I don't ever remember seeing one over 20.  I don't use tracert much but if I remember right it can generate a lot of "request timed out" entries when something isn't responding.

Unfortunately I don't have an answer as to why it's failing, or why creating a connector would allow it to succeed.  The only time creating a connector solved an issue for me was when the MX record wasn't resolving properly for some reason.  A quick search also suggests that the SMTP error can be seen when your IP is blacklisted, but then in that case I wouldn't expect that creating a connector would change anything.
0
 
quaybjAuthor Commented:
Still working this problem.  SMTP seemingly fixed itself.  Now I have to remove the connector or the messages are stuck in the queue.  more later....
0
 
quaybjAuthor Commented:
This righted itself.  I beleive it was because replication between the 2 DC's stopped.  Now that replication is OK again, the SMTP issue went away.  I don't like mystery solutions, but I can only see this as the cause of the problem.
0
 
quaybjAuthor Commented:
I did not select my own reason for accepting the comment, so i don't know why i have to comment on my comment.  However, Will Szymkowski's comment led me deeper into SMTP logs than i have ever been - very interesting.  and Footech's mention of name resolution led me to the deep DNS probe, which i think was the solution to the problem.

Thanks to you both.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Easily Design & Build Your Next Website

Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.

  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now