Troubleshooting Procedures and Tips for Mail Services
This section provides some procedures and tips that you can use for troubleshooting problems
with mail services.
How to Test the Mail Configuration
To test the changes that you make to your configuration file, follow these instructions.
- Restart sendmail on any system that has a revised configuration file.
# svcadm refresh network/smtp:sendmail
- Send test messages from each system.
# /usr/lib/sendmail -v names </dev/null
- names
Specify a recipient's email address.
This command sends a null message to the specified recipient and displays the message
activity on your monitor.
- Send mail to yourself or other people on the local system by addressing the message
to a regular user name.
- (Optional) If you are connected to a network, send mail in three directions to someone
on another system.
From the main system to a client system
From a client system to the main system
From a client system to another client system
- (Optional) If you have a mail gateway, send mail from the mail host to
another domain to ensure that the relay mailer and host are configured properly.
- (Optional) If you have set up a UUCP connection on your phone line to
another host, send mail to someone at that host. Have that person send mail
back or call you when the message is received.
- Ask someone to send mail to you over the UUCP connection.
The sendmail program cannot detect whether the message is delivered because the program passes
the message to UUCP for delivery.
- From different systems, send a message to postmaster and ensure that the message is
delivered to your postmaster's mailbox.
How to Check Mail Aliases
The following example shows you how to verify an alias.
% mconnect
connecting to host localhost (127.0.0.1), port 25
connection open
220 your.domain.com ESMTP Sendmail 8.13.6+Sun/8.13.6; Tue, 12 Sep 2004 13:34:13 -0800 (PST)
expn sandy
250 2.1.5 <[email protected]>
quit
221 2.0.0 your.domain.com closing connection
%
In this example, the mconnect program opened a connection to a mail
server on a local host and enabled you to test that connection. The program
runs interactively, so you can issue various diagnostic commands. For a complete description, see
the mconnect(1) man page. The entry, expn sandy, provided the expanded address, [email protected]. Thus,
you have verified that mail can be delivered when using the alias sandy.
Remember to avoid loops and inconsistent databases when both local and domain-wide aliases are used.
Be especially careful to avoid the creation of alias loops when you move a
user from one system to another system.
How to Test the sendmail Rule Sets
To check the input and returns of the sendmail rule sets, follow these instructions.
- Change to address test mode.
# /usr/lib/sendmail -bt
- Test a mail address.
Provide the following numbers and address at the last prompt (>).
> 3,0 mail-address
- mail-address
Use the mail address that you are testing.
- End the session.
Press Control-d.
Example 13-5 Address Test Mode Output
The following is an example of the output from the address test mode.
% /usr/lib/sendmail -bt
ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
> 3,0 sandy@phoenix
canonify input: sandy @ phoenix
Canonify2 input: sandy < @ phoenix >
Canonify2 returns: sandy < @ phoenix . example . com . >
canonify returns: sandy < @ phoenix . example . com . >
parse input: sandy < @ phoenix . example . com . >
Parse0 input: sandy < @ phoenix . example . com . >
Parse0 returns: sandy < @ phoenix . example . com . >
ParseLocal input: sandy < @ phoenix . example . com . >
ParseLocal returns: sandy < @ phoenix . example . com . >
Parse1 input: sandy < @ phoenix . example . com . >
MailerToTriple input: < mailhost . phoenix . example . com >
sandy < @ phoenix . example . com . >
MailerToTriple returns: $# relay $@ mailhost . phoenix . example . com
$: sandy < @ phoenix . example . com . >
Parse1 returns: $# relay $@ mailhost . phoenix . example . com
$: sandy < @ phoenix . example . com . >
parse returns: $# relay $@ mailhost . phoenix . example . com
$: sandy < @ phoenix . example . com . >
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.13.1+Sun/8.13.1; Sat, 4 Sep 2004 3:52:56 -0700
expn sandy
250 2.1.5 <[email protected]>
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 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.
