PMDF System Manager's Guide

Errors encountered during TCP/IP delivery are quite often transient in nature and PMDF will generally retain messages when problems are encountered and retry them periodically. It is quite normal on very large networks to experience periodic outages to certain hosts while other host connections work fine. You can examine the log files for errors relating to delivery attempts. You can see error messages such as "Fatal error from smtp_open". Such errors are not uncommon and are usually associated with a transient network problem. Your TCP/IP package can contain tools such as ping, traceroute, and nslookup to aid in debugging TCP/IP network problems.

One thing to check in your PMDF configuration is that the TCP/IP channel in question has been correctly configured to perform host lookups, according to your needs. If the channel is one that delivers to Internet systems, then it must perform MX lookups using the DNS (nameservers); make sure that your TCP/IP package has been configured to allow MX lookups, and that the TCP/IP channel in question has been marked with a keyword such as mx or randommx , meaning that MX lookups will be performed. If the TCP/IP channel is one delivering to a private network and you want to use local host table lookups rather than consulting a nameserver, make sure that the channel has been marked nodns , meaning that local host table lookups will be performed rather than nameserver lookups.

Example 33-1 shows the steps you might use to see why a message is sitting in the queue awaiting delivery to xtel.co.uk. This example assumes you are using Process Software's MultiNet. The basic idea is to duplicate the steps PMDF uses to deliver SMTP mail on TCP/IP.

If you are using some other TCP/IP package, check with your vendor to see what diagnostics tools are available.

Example 33-1 Tracing TCP/IP Mail Delivery

$ MULTINET NSLOOKUP/TYPE=MX XTEL.CO.UK (1) Server: LOCALHOST Address: 127.0.0.1 Non-authoritative answer: XTEL.CO.UK preference = 10, mail exchanger = nsfnet-relay.ac.uk (2) $ MULTINET PING NSFNET-RELAY.AC.UK (3) PING NSFNET-RELAY.AC.UK (128.86.8.6): 56 data bytes 64 bytes from 128.86.8.6: icmp_seq=0 time=490 ms CANCEL $ TELNET/PORT=25 NSFNET-RELAY.AC.UK (4) Trying... [128.86.8.6] %MULTINET-F-ECONNREFUSED, Connection refused

1. First use the NSLOOKUP utility to see what MX records, if any, exist for this host. If no MX records exist, then you should try connecting directly to the host. If MX records do exist, then you must test by connecting to the designated MX relays since PMDF is required to honor MX information preferentially.
2. In this example, the Domain Name Service returned the name of the designated MX relay for xtel.co.uk. This is the host that PMDF will actually connect to. If more than one MX relay is listed, PMDF would try each in succession.
3. A simple way to test connectivity to the host is with a PING utility. If no response is received, then you have a network routing or configuration problem. If the problem is on some router over which you have no control, there is not anything you can do except to wait until it is fixed.
4. If you do have connectivity to the remote host, the next step is to see if it is accepting inbound SMTP connections by using TELNET to the SMTP server port, port 25. If you use TELNET without specifying the port, you can merely discover that the remote host accepts normal TELNET connections. This by no means indicates that it accepts SMTP connections: many systems can accept regular TELNET connections but refuse SMTP connections or vice versa. Thus, you should always do your testing against the SMTP port. In this example, the remote host is currently refusing connections to the SMTP port. This is undoubtedly why PMDF fails to deliver the message. The connection can be refused due to a misconfiguration of the remote host or some sort of resource exhaustion, again, on the remote host. There is absolutely nothing you can do locally to solve the problem. Typically, you should just let PMDF continue to retry the message.

If you are running on a TCP/IP network which does not use the Domain Name Service, then you can skip steps (1) and (2) and use PING and TELNET directly to the host in question. Be careful to use precisely the host name that PMDF would use, which can be ascertained by examination of the relevant log file from PMDF's last attempt.

Note that if you test connectivity to a TCP/IP host and encounter no problems using interactive tests, it is quite likely that the problem has simply been resolved since PMDF last tried delivering the message. This is not an indication of a problem with PMDF.