How do I trace the route from my machine to the smtp server?

GoDaddy uses smtpout.secureserver.net as the smtp server for all email clients.  So your command line would be:  tracrt smtpout.secureserver.net

you can also use ping smtpout.secureserver.net -t to run an infinate ping test to help detect packet loss.

On a side note, GoDaddy accoutns commonly require smtp authentication prior to sending emails.  There is a common exceoption in email servers that bypasses the requirement when email has just been retrieved, which may explain the interrmittance of your problem.  either way, I would check the smtp auth settings in your email client.

also, you'll need to access the command line using Berge's instructions, and I meant to type tracert, not tracrt.  Good luck

Hi all,

tracert smtpout.secureserver.net wont even get me out o my own home network.
I can get only up to the modem I use to connect to the web. (192.168.254.254)

Seems like the modem will block any kind of tracert attempt.
Is there some kind of configuration that will allow me to get through the modem?
Its a speedstreem 5.200 from Siemens.

Now, regarding authenticating the sender, yes, all account are configured so that authentication is applied.

And this issue began about ten days ago, up to then, everything and all accounts were fine.
I opened a ticket at my ISP so they could verify whether there is a block on my network.
But if I only could trace all the way up, I might be able to get to the point where its failing.

Running telnet "smtpout.secureserver.net 25" will take me a few nods up my ISP's rooters and servers, but then it will stop.  I dont believe that is a precise way of doing it as my email client is able to reach the server most of the time, even when I only get a couple nods up my ISPs network.

So I wonder If theres some command that will get pass the modem and keep going up the network till it really finds a failing point.

I appreciate everybody's help!

Eder

You are getting past your modem.
If you can get to your ISP and something on their end is timing out, you need to raise the priority with them.
If you can actually talk to a human with your ISP (good luck on that one), keep them on the line until you can talk with someone who actually understands the problem.
Most level one "Help" types are at a pretty basic level, so you will probably need to move up a notch or two to get any real assistance.

You are right.

I have gotten them to send a "technician" over to my office, but he dismissed the problem by running a tracert to the IP address of my email server. As I was not present at the time, my employee was convinced that no problem was present.

But running a tracert to the ip address will get through, however if you run a tracert to the smpt, specifying a port at the end, most of the time the connection will time out at one of the rooters/servers belonging to my ISP.

Can you tell me if the procedure below would show me exactly where the smtp request is being interrupted, showing where the problem is?

These are the three ports I have available from my email server.

tracert smtpout.secureserver.net 25
tracert smtpout.secureserver.net 3535
tracert smtpout.secureserver.net 80

If I log to a dedicated server I have at godaddy also, the tracert will get all the way through to the email server. But connecting from a local machine at my office, it has a hard time to get through all the routers and arrive at the server, so email can be sent.

Thanks again for all the help.

Eder

You may want to take half a step back and look at what details are available from the email failures. If the email software on the workstations is getting failures, see whether you can turn on some additional logging and see what the specific error is - server not responding at all, connection interrupted, authentication failure, etc.

pings and tracert and other network tests are low priority requests, and can be ignored by servers and intermediate stops in favor of "real" requests, and you can get stuck on false problems when tracking errors in those commands. Focus on the specific errors, and also see whether the intermittent-ness is really somewhat random, or maybe corresponds to times of day, or particular workstations, or something else that might help you find and solve the problem.

Most likely is a DNS error.
The clients are not resolving the DN of the SMTP server.
Check your DNS server settings.