Odd Message Tracking Error: Message transerred to computer through SMTP

I've got an Exchange 2003 server sitting on a W2K3 Server behind a Hotbrick firewall on SBC DSL.

A user reported that her e-mail messages where not being recieved at an outside destination. I checked on the problem e-mail messages in the Message Tracking Center and found the final line:
  Message transerred to computer through SMTP

A message that got through had the final line:
  Message transerred to mta.snet.net through SMTP

I'm checking the event logs and see the System Event
Source: DCOM
Event ID: 10009
DCOM was unable to communicate with the computer computer using any of the configured protocols.

I also see
Source: DCOM
Event ID: 10009
DCOM was unable to communicate with the computer mta5.snet.net using any of the configured protocols.

I've Googled and didn't find any relevent articles, or articles that apearded relevent. But I've been wrong before. :-)

Is something setup incorrectly on my Exchange Server or is this an outside DNS issue?
Who is Participating?
SembeeConnect With a Mentor Commented:
An SMTP Connector will send all email to your ISPs email server rather than trying to deliver it directly. Like giving a package to a courier rather than taking it across town yourself. The ISPs server then has to worry about delivering it.
If you setup a connector for this one domain then all the other mail will continue to be delivered normally (direct) while email for this one domain is sent via the ISP.
I am having to use SMTP connectors more often as clients use DSL lines which some ISPs block delivery from (AOL for example).

What is snet.net? Is that your domain, the sender or recipient of the email messages?

If it is external to you, then it looks like it could be a dns issue.

TerrellITCAuthor Commented:

Sorry, I thought is was obvious...

A MX lookup shows "snet.net" is the mail domain for the receiver.

And "computer" is...?

I too assume its a DNS issue, but I'm unclear whether its internal or external.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

In this game you cannot presume anything.

Does your firewall inspect or do anything with SMTP traffic at all? I am wondering if it or something else is interfering. Cisco PIX are notorious for doing it with certain combinations.

Quickest solution? Setup and SMTP connector for this one domain to send email via your ISP.

TerrellITCAuthor Commented:
I don't believe that the Hotbrick firewall is doing anything on the SMTP traffic. I've seen some non-SMTP related funkiness, but I'm trying to determine if it's a problem with our ISP.

I'm learning about Exchange 2003 as I go. Can you give more detail to your solution? I've got the book Exchange Server Unleashed and it has the steps on making a SMTP connector. But I'm unclear on why I need to setup one here...

TerrellITCAuthor Commented:
Okay, that makes sense. It sounds like I'll have to check on the relay policies of my ISPs. (I've got two "business-class" DSL connections.)

The only thing I don't like about that is that I would losing the ability to tell my users "I see that the Exchange Server delivered the message to the recepient's e-mail server. So it's their problem, not mine." With a connector to the ISP, I would have to go figure out what my ISP is up too... :-)

First comment so bear with me.
Just installed Exch 2k (Enterprise) on W2k.
I see the DCOM 10009 errors when tracking a message that was delivered externally. I've tried the fix suggested in MS KB 245197 - I only have Connection orientated TCP/IP in the default protocols tab now - no effect.
In this case the 10009 error appears after the message is tracked - the messages are delivered OK.
Is the error a result of Message Tracking attempting to interrogate a server outside of our domain??
Anyone any more ideas?

Simon (another one ;-))
simply make the test.

track a message an have a look on system log. when you get a dcom error after you tracked a message, the external mailserver, may not support tracking and quits the connection.

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.

All Courses

From novice to tech pro — start learning today.