Traceroute on port 25

[#1]

Hi all Does anyone know of a program that can do a tracert on port 25? The amount of times I have been troubleshooting SMTP flow problems where I wish I could see where it was failing... Thanks in advance! Hong

[UkWizard]

would be exactly the same as a traceroute to the mail recipients email server ip address. You cannot traceroute an port ..... If you are talking about tracing the flow of an email through multiple email servers (relays) then you would look at the received email and look at its header contents, it should show all mailserver ' relays' that it took.

[#3]

Well the point I am getting at is if there is a path to the IP of mail server, it does not necessarily mean port 25 is open. And although the headers would indicate the replays used, if we are in a situation where all mail has suddenly stopped flowing and several appliances could be at fault...there would be no headers to look at. Anyways, I finally found a *nix tool that looks like it may do the trick, called hping2 Opinions welcome!

[#4]

A much simpler way to tell if mail server is running on a machine is by telnetting to the mail port. example: type this from the dos prompt. replace with real address of the mail server: telnet 192.168.1.1 25 If you get an email banner, then SMTP server is running. If not, then it' s not. Remember not to use a colon : before the port number. just a space.

[#5]

Ok, let me make this a little clearer!! Recently mail flow stopped just like that at a client site. The mail flow went like this: Internet --> FG500 --> Proofpoint SPAM Filter --> Exchange BH The FG500 had a history of being ' buggy' at times. So we didnt rule that out to have fallen ove again. The proofpoint was exhibiting signs of not working properly also, though minor. A telnet connection to Port 25 to the clients external IP fails. If I had a tool that could trace on port 25, then I could easily work out if it is indeed even hitting the Proofpoint box, or if its failing at the firewall. In the end I had to trawl through logs and do TCP dumps to detemine if any traffic was reaching the Proofpoint box. I have had other similar scenarios like this where I think that kind of tool would be handy, and speeding up the process. I know you can accomplish this in other ways but its just something I thought someone might have already done!

[abelio]

A telnet connection to Port 25 to the clients external IP fails ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .

doesn' t makes sense; dsheldon suggested you must telnet SERVER' s 25 port (not client..) to test smtp availability.

If I had a tool that could trace on port 25

doesn' t makes sense either ukwizard explained to you that you can' t " traceroute a port"

then I could easily work out if it is indeed even hitting the Proofpoint box, or if its failing at the firewall. In the end I had to trawl through logs and do TCP dumps to detemine if any traffic was reaching the Proofpoint box.

Simpler: first: disable your proofpoint filter and test internet->FG500->Exchange Test also with/without FG500 spamfilter if everything works as required, enable your proofpoint in the middle and retest. second: sniff your interfaces diagnose sniffer packet internal (or dmz) " host <your_Exchange_IP> and tcp port 25" third: if you cannot get a picture of what' s happening, try diagnose debug application smtp 1

I have had other similar scenarios like this where I think that kind of tool would be handy, and speeding up the process.

I think that you' ve several " handy" tools as above to try to follow the traffic

[#7]

dsheldon suggested you must telnet SERVER' s 25 port (not client..) to test smtp availability.

Thats what I meant, typo

ukwizard explained to you that you can' t " traceroute a port"

This hping2 tool claims it can? Unless I am misinterpreting it?

Simpler: first: disable your proofpoint filter and test internet->FG500->Exchange Test also with/without FG500 spamfilter if everything works as required, enable your proofpoint in the middle and retest. second: sniff your interfaces diagnose sniffer packet internal (or dmz) " host <your_Exchange_IP> and tcp port 25"

Good plan, dont know why I didnt think of that. Guess its down to inexperience. Not familiar with the CLI commands, again down to inexperience. Didnt even know it had a built in sniffer!

third: if you cannot get a picture of what' s happening, try diagnose debug application smtp 1

I dont think I would know how to interpret the results! See above!

I think that you' ve several " handy" tools as above to try to follow the traffic

You can never have too many...