SMTP_EXCMAXHOP

[Edwin Gersbach_2]

In a TCPIP$SMTP_LOGFILE I was made aware of the following error entry:
%TCPIP-E-EXCMAXHOP, maximum number of hops exceeded; mail loop suspected

Is there any way to get some information about the problem? I perfectly understand what has happened here, but in order to narrow down the problem I guess I should at least know what the mail destination was. Not even a timestamp is in the logfile which would allow to check for systems down or the like.

I've just sent several test mails without any problems and the error was logged only on one node of a two-node cluster. It can therefore not be a general problem.

Is there any way to get more information - if not for this occurence so at least for the next time?

Edwin

[Willem Grooters]

It will be hard to trace it down, but it may be worth a try:

1. $ @sys$manager:TCPIP$DEFINE_COMMANDS.COM
setus up a number of commands. VERY helpful...
2. Determine the address of the intended receiving machine. $ TCPIP PING may work, but it will fail if the domain has no DNS entry (purely MX-based). Consider NSLOOKUP or, for MX records, DIG to get this data.
3. Now run TRACEROUTE

and look for a loop. It might be it won't show the IP address or name of routers, but perhaps it will.

(All these (Unix) based commands have a load on options, these are covered under TCPIP> HELP , than choose FLAGS. (As so many, I'm still waiting for a decent, VMS-like DCL interface and HELP for all these TCPIP commands...)

Check route and default gateway on the node where the problem occurs.

[Volker Halle · Accepted solution]

Edwin,

to capture more information - should this error happen again - would mean to enable SMTP logging. See chapter 18.5.1 in the TCPIP Mgmt guide:

http://h71000.www7.hp.com/doc/732final/6526/6526pro_039.html#logicals_sec

To reduce logfile size, consider to enable shapshot logging.

Volker.

[Edwin Gersbach_2]

Willem,

As I mentioned, this is not a permanent problem - it occured only once so far. As I don't know the mail destination I can neither ping or trace.

Volker,

I had some hope that such information is logged somewhere by default. Well then, if/when this problem occures again I will enable snapshot logging.

Many thanks
Edwin

[Edwin Gersbach_2]

It has occured again today, but just produced 15 such errors and was then quiet again. No chance to trace this.