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

Wierd DNS like issue...

I have several messages in my Exchange Server 2003 queue.  A lot of them have wierd messages like:

Connection was dropped by remote host

I've determined for some we're being blacklisted.  Ok that's fine.  Figured that one out.

But one is really strange.

Since it's not my domain in question I'll put it out there.  It's public info anyway.

thecolumbiabank.com the nslookup MX record reports:  name class type data time to live
clb-mail2.thecolumbiabank.com IN A 77316s (21h 28m 36s

However when I do a message tracking on the message destined for thecolumbiabank.com our Exchange server reports
it's trying to deliver to:

name class type data time to live
clb-mail12.thecolumbiabank.com IN A 77316s (21h 28m 36s


So where is my exchange server getting this other server information from which is why it can't deliver the message.  

I suspect this is the case with various email servers which is why my queue is growing.  

Please help!  

1 Solution
Perhaps they changed their dns records. Your server could have gotten the old answer right before it switched and cached it. The TTL on the MX record is 86400 (1 day) so after 24 hours check your exchange to see if it is still reporting the clb-mail12 host.

I think this can be becuase that ur exchange server is opened for relaying , Do the following steps  for the domain name that is coming in the error .

follow the article for the steps

. More u can try sending the mail from the command prompt to see wether the mail is going , if it is still sending the same error then the problem is not with ur server . since sending mail from command prompt bypasses ur mail servers fro the delivery .
And if the error does not come then definately the server is opened for relaying , otherwise how can the records be in ur server for a foriegn domain.And this is the reason why ur queue is growing as the server list in severs is growing .

I think only these can be the possible causes . if u find ur mail server relaying them u have to stop it and clear the entries from ur server .

Follow the article for  stopping relay on ur excahge server .

This can be exact solution for ur problem . because if the mx records for the foriegn domain are there in ur sever then somebody is relaying his messages by using your exchange . ok

TheBrothaULuv2H8Author Commented:
Guys, I do not have an open relay.  This I know.  I've also tested to confirm.

I think the aforementioned item about our DNS caching may be on the right track.  4:30 EST TODAY would be exactly 24hrs, I guess I'll check again then.  

PS:  I exaggerated that my queue is growing.  Some are incorrect spellings, some domains have us blacklisted on an RBL, but others worry me.  Like HOTMAIL, MSN, COMCAST, AOL.  

For example, COMCAST.NET has 57 message in queue.  It's a problem when our messages can't make it to large domains like that.

Any ideas on those?  I'm sure that issue is not a DNS cache wrong/old MX record issue.  
Easily manage email signatures in Office 365

Managing email signatures in Office 365 can be a challenging task if you don't have the right tool. CodeTwo Email Signatures for Office 365 will help you implement a unified email signature look, no matter what email client is used by users. Test it for free!

TheBrothaULuv2H8Author Commented:
One additional note...I also added a SMARTHOST which I thought meant ALL mail would be dumped to my ISPs mail server (which they have added us to the allowed list) and let their server deliver the messages (QWEST).  Since we seem to be having an issue.  Yet and still these messages remain in queue.  new messages to the same domain also remain in queue.
It looks very much like they may be the same machine as when you telnet to clb-mail2.thecolumbiabank.com on smtp it identifies itself as clb-mail12.thecolumbiabank.com so clb-mail12 may be the NETBIOS name of the box. Readons why they may do this are unclear however I have often renamed the external address of an internal machine when migrating it from one location to another. Either way the MX record points to a valid host and I have used telnet to successfully connect to it via SMTP however there is a DNS entry for clb-mail12.thecolumbiabank.com which hangs if you try to connect to it. I would flush the DNS cache on your DNS boxes and do an IPCONFIG /flushdns before trying  to force another connection.


It is not unusual for the MX record and what the server announces itself as to be different.

Take Microsoft.
Their MX records state that one of their servers is maila.microsoft.com
Telnet to port 25 and you actually get this:

220 IGT-IMC-02.redmond.corp.microsoft.com Microsoft ESMTP MAIL Service <Inbound
SMTP Virtual Server> Fri, 16 Jun 2006 14:43:04 -0700

Message tracking records the name in the banner of the server the message was delivered to. In my example above it would record "IGT-IMC-02.redmond.corp.microsoft.com"

As for the email delivery problem. The messages will not use the smart host until the retry time on the SMTP queue takes affect. Try right clicking on the queues and chose retry now.

Does your ISP require authentication to use their SMTP server?

Put your domain in to dnsreport.com and see if it flags any errors.

Another possibility: If you are sending an awful lot of email to these large domains, they may be only temporarily blocking you by replying to your server's smtp sessions with a 4.x.x error which your Exchange server will interpret as "try again a little later." Sites that route a ton of email often have dynamic blocking in place so they may, for instance, block an IP address if it submits a ton of email in a short period, assuming that host is a spammer or performing a directory harvest attack. In those cases, it will respond with a 4.x.x error and Exchange will queue the messages and retry on whatever schedule you have configured. Because the error they give you is a 4.x.x, Exchange will just keep on retrying until it meets your configured limit and NDRs the message. If you only route normal real messages you don't usually have this problem. However, if you don't have good antispam measures in place and a fair amount of spam is making it through to your Exchange server, many of those messages will be destined for usernames that you don't actually host and you will then generate an NDR and since the spammer spoofed the sending domain, you're sending the NDR off to someone and you're sending a ton of them and they understandably don't like all of that traffic but don't want to drop you permanently.

Try sending a complete message to that host via a telnet session and make sure your telnet session is coming from the same IP as the mail (you should be logged onto the server in question at the moment). Do they accept the message? Keep trying, especially when a batch of messages are scheduled to be retried by Exchange, and see if they every give you the dreaded 4.x.x.

If your ISP is willing to route your outbound email on your behalf, I would take them up on that service permanently. Outbound delivery is costly, lots of DNS lookups and lots of queued mail. If you can push that work off on someone else, all the better.
TheBrothaULuv2H8Author Commented:
Thank you all for your assistance.  The problem was actually a known issue with Symantec Anvirus Corp edition and Exchange Server 2003.

The problem has sense been resolved.  Thank you all for your assistance.
Clearly Sembee and myself deserve the points split between us!
Closed, 500 points refunded.

Community Support Moderator
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

Free tool for managing users' photos in Office 365

Easily upload multiple users’ photos to Office 365. Manage them with an intuitive GUI and use handy built-in cropping and resizing options. Link photos with users based on Azure AD attributes. Free tool!

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