How to Verify Connections to Other Systems

The mconnect program opens a connection to a mail server on a host that you specify and enables you to test that connection. The program runs interactively, so you can issue various diagnostic commands. See the mconnect(1) man page for a complete description. The following example verifies that mail to the user name sandy is deliverable.

% mconnect phoenix

connecting to host phoenix (172.31.255.255), port 25
connection open
220 phoenix.example.com ESMTP Sendmail 8.12.0+Sun/8.12.0;Sun, 4 Sep 2001 3:52:56 -0700(PDT)
expn sandy
250 2.1.5 <sandy@phoenix.example.com>
quit

If you cannot use mconnect to connect to an SMTP port, check these conditions.

• Is the system load too high?

• Is the sendmail daemon running?

• Does the system have the appropriate /etc/mail/sendmail.cf file?

• Is port 25, the port that sendmail uses, active?

Logging Error Messages

Your mail service logs most error messages by using the syslogd program. By default, the syslogd program sends these messages to a system that is called loghost, which is specified in the /etc/hosts file. You can define loghost to hold all logs for an entire NIS domain. If no loghost is specified, error messages from syslogd are not reported.

The /etc/syslog.conf file controls where the syslogd program forwards messages. You can change the default configuration by editing the /etc/syslog.conf file. You must restart the syslog daemon for any changes to become active. To gather information about mail, you can add the following selections to the file.

• mail.alert - Messages about conditions that should be fixed now

• mail.crit - Critical messages

• mail.warning - Warning messages

• mail.notice - Messages that are not errors, but might need attention

• mail.info - Informational messages

• mail.debug - Debugging messages

The following entry in the /etc/syslog.conf file sends a copy of all critical, informational, and debug messages to /var/log/syslog.

mail.crit;mail.info;mail.debug			/var/log/syslog

Each line in the system log contains a timestamp, the name of the system that generated the line, and a message. The syslog file can log a large amount of information.

The log is arranged in a succession of levels. At the lowest level, only unusual occurrences are logged. At the highest level, even the most mundane and uninteresting events are recorded. As a convention, log levels under 10 are considered "useful." Log levels that are higher than 10 are usually used for debugging. See the "Customizing System Message Logging" in System Administration Guide: Advanced Administration for information about loghost and the syslogd program.

Other Sources for Mail Diagnostic Information

For other diagnostic information, check the following sources.

• Look at the Received lines in the header of the message. These lines trace the route that the message took as the message was relayed. Remember to consider time-zone differences.

• Look at the messages from MAILER-DAEMON. These messages typically report delivery problems.

• Check the system log that records delivery problems for your group of systems. The sendmail program always records its activities in the system log. You might want to modify the crontab file to run a shell script nightly. The script searches the log for SYSERR messages and mails any messages that it finds to the postmaster.

• Use the mailstats program to test mail types and determine the number of incoming messages and outgoing messages.

Resolving Error Messages

This section describes how you can resolve some sendmail-related error messages that are in the Solaris 9 operating environment. You can also refer to http://www.sendmail.org/faq/.

The following error messages contain two or more of the following types of information.

• Cause: What might have happened to cause the message

• Description: What the user was doing when the error message occurred

• Action: What you can do to fix the problem or to continue with your work

• Technical Notes: Background information that might be interesting or helpful to a technical audience, such as developers

• See Also: Suggests further reading

451 timeout waiting for input during source

Cause: When sendmail reads from any source that might time out, such as an SMTP connection, the program sets a timer to the value of various Timeout options before reading begins. If the read is not completed before the timer expires, this message appears and reading stops. Usually, this situation occurs during RCPT. The mail message is then queued for later delivery.

Action: If you see this message often, increase the value of various Timeout options in the /etc/mail/sendmail.cf file. If the timer is already set to a large number, look for hardware problems, such as poor network cabling or connections.

See Also: For more information about the Timeout option, refer to Changes to the Timeout Option. If you are using online documentation, the term "timeouts" is a good search string.

550 hostname... Host unknown

Cause: This sendmail message indicates that the destination host machine, which is specified by the portion of the address after the at sign (@), was not found during domain name system (DNS) lookup.

Action: Use the nslookup command to verify that the destination host exists in that domain or other domains, perhaps with a slightly different spelling. Otherwise, contact the intended recipient and ask for a proper address.

550 username... User unknown

Cause: This sendmail message indicates that the intended recipient, who is specified by the portion of the address before the at sign (@), could not be located on the destination host machine.

Action: Check the email address and try again, perhaps with a slightly different spelling. If this remedy does not work, contact the intended recipient and ask for a proper address.

554 hostname... Local configuration error

Cause: This sendmail message usually indicates that the local host is trying to send mail to itself.

Action: Check the value of the $j macro in the /etc/mail/sendmail.cf file to ensure that this value is a fully qualified domain name.

Technical Notes: When the sending system provides its host name to the receiving system in the SMTP HELO command, the receiving system compares its name to the sender's name. If these names are the same, the receiving system issues this error message and closes the connection. The name that is provided in the HELO command is the value of the $j macro.

See Also: For additional information, refer to http://www.sendmail.org/faq/section4.html#4.5.

config error: mail loops back to myself.

Cause: This error message occurs if you set up an MX record and make host bar the mail exchanger for domain foo. However, you fail to configure host bar to know that it is the mail exchanger for domain foo.

Also, another possibility is that both the sending system and the receiving system are identifying as the same domain.

Action: For instructions, refer to http://www.sendmail.org/faq/section4.html#4.5.