This section provides some tips and tools that you can use for troubleshooting problems with the mail services.
Restart sendmail on any system for which you have changed a configuration file.
# pkill -HUP sendmail |
Send test messages from each system by typing /usr/lib/sendmail -v names </dev/null and press Return.
Specify a recipient's email address in place of the names variable.
This command sends a null message to the specified recipient and displays messages while it runs.
Run these tests:
Send mail to yourself or other people on the local system by addressing the message to a regular user name.
If you are on Ethernet, send mail to someone on another system.
Do this in three directions: from the main system to a client system, from a client system to the main system, and from a client system to another client system.
If you have a mail gateway, send mail to another domain from the mail host to ensure that the relay mailer and host are configured properly.
If you have set up a UUCP connection on your phone line to another host, send mail to someone at that host and 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 tell whether the message gets through because it hands the message to UUCP for delivery.
Send a message to postmaster on different systems and make sure that it comes to your postmaster's mailbox.
To verify aliases and whether mail can be delivered to a given recipient:
The command displays the aliases and identifies the final address as deliverable or not.
Here is an example of the output:
% /usr/lib/sendmail -v -bv sandy sandy... aliased to ssmith ssmith... aliased to sandy@phoenix sandy@phoenix... deliverable: mailer esmtp, host phoenix, user sandy@phoenix.eng.acme.com % |
You should take extra care to avoid loops and inconsistent databases when both local and domain-wide aliases are used. Be especially careful when you move a user from one system to another to avoid creating alias loops.
Type /usr/lib/sendmail -bt and press Return.
Information is displayed.
At the last prompt (>) type a 3,0 (zero) and the mail address you want to test.
Type Control-d to end the session.
Here is an example of the output:
% /usr/lib/sendmail -bt ADDRESS TEST MODE (ruleset 3 NOT automatically invoked) Enter <ruleset> <address> > 3,0 sandy@phoenix rewrite: ruleset 3 input: sandy @ phoenix rewrite: ruleset 96 input: sandy < @ phoenix> rewrite: ruleset 96 returns: sandy < @ phoenix . eng . acme . com . > rewrite: ruleset 3 returns: sandy < @ phoenix . eng . acme . com . > rewrite: ruleset 0 input: sandy < @ phoenix . eng . acme . com . > rewrite: ruleset 199 input: sandy < @ phoenix . eng . acme . com . > rewrite: ruleset 199 returns: sandy < @ phoenix . eng . acme . com . > rewrite: ruleset 98 input: sandy < @ phoenix . eng . acme . com . > rewrite: ruleset 98 returns: sandy < @ phoenix . eng . acme . com . > rewrite: ruleset 198 input: sandy < @ phoenix . eng . acme . com . > rewrite: ruleset 198 returns: $# local $: sandy rewrite: ruleset 0 returns: $# local $: sandy |
To verify connections to other systems, you can use the mconnect program to open connections to other sendmail systems over the network. The mconnect program runs interactively. 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 shamira is deliverable.
$ mconnect phoenix connecting to host phoenix (129.144.52.96), port 25 connection open 220 phoenix.Eng.Acme.COM Sendmail 8.9.0+Sun/8.9.0; Tue, 25 Jul 1998 10:45:28 -0700 vrfy sandy 250 Sandy Smith <sandy@phoenix.Eng.Acme.COM> > |
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?
The mail services log most errors using the syslogd program. The default is for syslogd to send messages to the loghost.
You can define a system called loghost in the /etc/hosts file to hold all logs for an entire NIS domain. The system log is supported by the syslogd program. You specify a loghost in /etc/hosts. If no loghost is specified, error messages from syslogd are not reported.
Example 34-1 shows the default /etc/syslog.conf file.
#ident "@(#)syslog.conf 1.3 93/12/09 SMI" /* SunOS 5.0 */ # # Copyright (c) 1994 by Sun Microsystems, Inc. # # syslog configuration file. # # This file is processed by m4 so be careful to quote (`') names # that match m4 reserved words. Also, within ifdef's, arguments # containing commas must be quoted. # # Note: Have to exclude user from most lines so that user.alert # and user.emerg are not included, because old sendmails # have no 4.2BSD based systems doing network logging, you # can remove all the special cases for "user" logging. # *.err;kern.debug;auth.notice;user.none /dev/console *.err;kern.debug;daemon,auth.notice;mail.crit;user.none /var/adm/messages *.alert;kern.err;daemon.err;user.none operator *.alert;user.none root *.emerg;user.none * # if a non-loghost machine chooses to have authentication messages # sent to the loghost machine, un-comment out the following line: #auth.notice ifdef(`LOGHOST', /var/log/authlog, @loghost) mail.debug ifdef(`LOGHOST', /var/log/syslog, @loghost) # # non-loghost machines will use the following lines to cause "user" # log messages to be logged locally. # ifdef(`LOGHOST', , user.err /dev/console user.err /var/adm/messages user.alert `root, operator' user.emerg * ) |
You can change the default configuration by editing the /etc/syslog.conf file. You must restart the syslog daemon for any changes to take effect. You can add these selections to the file to gather information about mail:
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
The following entry 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 it, and a message. The syslog file can log a large amount of information.
The log is arranged as 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 higher than 10 are usually used for debugging. See the "mconnect" in System Administration Guide, Volume 2 for information about loghost and the syslogd program.
For other diagnostic information, check the following sources:
Look at the Received lines in the header of the message. These lines trace the route the message took as it was relayed. Iin the UUCP network many sites do not update these lines, and in the Internet the lines are rearranged. To straighten them out, look at the date and time in each line. Remember to account for time-zone differences.
Look at the messages from MAILER-DAEMON. These typically report delivery problems.
Check the system log that records delivery problems for your group of systems. The sendmail program always records what it is doing in the system log. You might want to modify the crontab file to run a shell script nightly that searches the log for SYSERR messages and mails any that it finds to the postmaster.
Use the mailstats program to test mail types and determine the number of incoming and outgoing messages.