Sendmail provides a few tools to help you figure out what to do when things go wrong.

One of the first things you might choose to do is to have a look at the following files:

/var/adm/messages
your systemwide dead.letter file

The file, dead.letter, contains any messages that the system has no idea what to do with along with the reason why it doesn't know what to do with it. By carefully looking at the message headers and error messages attached to the top of the message body, you should have enough information to determine why the message wasn't delivered.

Another place you could look is in your /var/adm/messages file. This is the file where Solaris stores most of its system messages. Mail delivery attempts are written to this file. By looking at this file you should be able to determine which user was trying to send a message and who was the intended recipient of that message. Again, error messages are written to this file as well.

In addition, Sendmail offers an interactive way to observe the flow of addresses through its rule sets. This mode is called rule-testing mode. The -bt command line switch is used to enter into this mode. When you enter into this mode, your screen will show:

ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
Enter <ruleset> <address>
>

To see a summary of functions that you can perform here, enter a question mark followed by a return at the > prompt.

You can set macros and classes in this mode similarly to the way they're defined in sendmail.cf. The only difference is that you would precede them with a dot while you're in rule testing mode. For example:

.Cw localhost

would set class w to localhost

To have Sendmail display the current contents of a macros use the dollar sign symbol followed by the name of the macro. If you want to ensure that Sendmail picks up the proper fully qualified host name for the machine, use:

$j

to view the contents of the j macro. To print the contents of a class use a dollar sign followed by an equal sign followed by the name of the class. To see a list of all domains that your host will accept mail for, use:

$=w

to print the contents of class w. If you want to see all the rules that make up a rule set use an equal sign followed by a capital S followed by the name of the ruleset. If you want to see a list of all the mail delivery agents enabled in the configuration file use an equal sign followed by a capital M.

There are some really cool things you can do in rules testing mode. The /canon rule testing command causes Sendmail to lookup the fully qualified host name of the specified host and print the results to your screen. To use it, use:

/canon host

If you want to watch the whole process from the command line, type:

/usr/lib/sendmail -d38.20 -bv alanpae@ilkda.com

To view a domains mail exchange records use:

/mx hostname or domain name

If the host or domain has mx records created for it, Sendmail will look up and print to your screen those records. The mx records are listed in the order in which they would be tried.

You can lookup any item in any database by using:

/map name key

name - the database name
key - the item you're trying to look up

If you were trying to see the alias for root, you would use:

/map aliases root

The /parse and /try commands let you parse addresses or to see which delivery agent will be used for a particular address. Before you can use either /parse or /try you could select the type of information that you want these two commands to act on. You can select the type of information that you want them to act on by first using the /tryflags option.

/tryflags has the following syntax:

/tryflags e <-- for envelope information
/tryflags h <-- for header information
/tryflags hr <-- for header recipient information
/tryflags r <-- for recipient information
/tryflags s <-- for sender information

The /parse rule-testing command is used to pass an address through a predetermined sequence of rules to select a delivery agent. To do this, you would use:

/parse address

The option you selected for the /tryflags option will determine what type of information that the /parse command will return for the address that you asked it to parse. Sendmail will send to your screen a list of all the rulesets that the address flows through as well as what happens to the address as it passes through each rule set.

You will be able to see what happens to the address at the end of traveling through all of its various rule sets. The last line will be the delivery agent as well as the final disposition of the address that you supplied.

The /try command allows you to feed an address to a mailer. The mailer is used to select only the R= or S= rule sets for that address. R rule sets are for recipients and S rule sets are for senders. To use /try, you might use:

/try smtp root

If you want, you could just supply a ruleset name or number along with an address at the > prompt. Sendmail will then run the address through that rule set and will show you what the final disposition is of running that address through that rule set.

Sendmail responds to the following signals:

SIGHUP
SIGINT
SIGTERM
SIGUSR1

SIGHUP is used to tell Sendmail to basically "restart" and reread its configuration file. SIGINT is used to handle Control C interrupts. SIGTERM is used to perform an orderly shutdown of the mail system. Kill -9 should not be used on Sendmail. SIGUSR1 is used to have Sendmail log information such as its file descriptors and connection cache.

Sendmail writes to syslog via the syslog.conf file. Since Sendmail writes error messages to the syslog daemon, it is suggested that you start both daemon's using the -L command line switch and then append a name that you want that daemon to use to log its error messages. Then syslog will log that daemon's name as well as the error message so you'll be able to figure out which daemon threw the error message to syslog. This will look like:

/usr/lib/sendmail -L sm-mta -bd -q1h

There are a couple of options that you have with Sendmail to control the type of logging that happens in a Sendmail environment.

The level of logging can be set for Sendmail. The default using a standard configuration file is level 9. The levels are as follows:

0 - Minimal logging.
1 - Serious system failures and potential security problems.
2 - Lost communications (network problems) and protocol failures.
3 - Other serious failures, malformed addresses, transient forward/include errors, connection timeouts.
4 - Minor failures, out of date alias databases, connection rejections via check_* rulesets.
5 - Message collection statistics.
6 - Creation of error messages, VRFY and EXPN commands.
7 - Delivery failures (host or user unknown, etc.).
8 - Successful deliveries and alias database rebuilds.
9 - Messages being deferred (due to a host being down, etc.).
10 - Database expansion (alias, forward) and authentication information.
11 - NIS errors and end of job processing.
12 - Logs all SMTP connections.
13 - Log bad user shells, files with improper permissions, and other questionable situations.
14 - Logs refused connections.
15 - Log all incoming and outgoing SMTP commands.
20 - Logs attempts to run locked queue files. These are not errors, but can be useful to note if your queue appears to be clogged.
30 - Lost locks (only if using lockf instead of flock).

If you look at the sendmail tarball there is a file called sendmail/TRACEFLAGS. This file will give you the name of the c file and the debugging information that is used in the c filename. In addition to that, Bat has a fairly comprehensive list of debugging numbers and details as you would expect.

Additionally, values above 64 are reserved for extremely verbose debugging output. No normal site would ever set these.

The actual use of the debug options is -d expression.level. The expression can be from 0-99. The higher the level, the more verbose the output will be. -d can be used on the command line by itself.

Some expression.level that you might find useful include:

-d0.20 Prints the version, the compiled with options, $w, $j, $m, $k macros, canonical names of the host machine, location of the configuration and process id files, delivery agents and the network addresses of the network interface cards for the host.

-d6.1 Show failed mail. Allows for detailed analysis of why message delivery was unsuccessful.

-d8.1 Traces DNS resolution

-d11.1 -v - Allows for detailed traces for message delivery

-d11.2 Shows the userid that Sendmail is using during delivery

-d21.1 Traces the rewriting rules

-d27.1 Traces aliasing

If you're having a hard time trying to nail down a problem you could try logging everything to a separate file. You can set traffic logging using the -X flag. For example:

/usr/sbin/sendmail -X /tmp/traffic -bd

will log all traffic in the file /tmp/traffic.

This logs a lot of data very quickly and should never be used during normal operations. After starting up the daemon, have the other site send a message to your host. All message traffic in and out of Sendmail, including the incoming SMTP traffic, will be logged in this file. If you just want to see Sendmail interacting with another SMTP agent without logging all the traffic, simply run:

/usr/lib/sendmail address -v

If you use, sendmail -D, sendmail will then send debugging output to the indicated logfile instead of stdout.

You can ask Sendmail to log a dump of the open files and the connection cache by sending it a SIGUSR1 signal. The results are logged at syslog's LOG_DEBUG priority.

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 man page for a complete description.

If you can't telnet to port 25 of the other machine then that may be where you need to start troubleshooting.

If all else fails make sure name resolution is defined properly in /etc/nsswitch.conf.

Next Section: Security - 21 of 32