HPlogo Installing and Administering Internet Services: HP 9000 Networking > Chapter 4 Installing and Administering sendmail

Troubleshooting sendmail

» 

Technical documentation

Complete book in PDF

 » Table of Contents

 » Index

This section describes the following techniques for troubleshooting sendmail:

Almost all sendmail troubleshooting must be done as superuser.

Keeping the Aliases Database Up to Date

The aliases database must be rebuilt if changes have been made to the aliases text file.

You must restart sendmail after you change the configuration file or the aliases database.

Issue the following commands, on a standalone system or on the mail server, to rebuild the aliases database and restart sendmail:

/sbin/init.d/sendmail stop
/sbin/init.d/sendmail start

Updating Your NIS or NIS+ Aliases Database

If you are using NIS or NIS+ to manage your aliases database, see Installing and Administering NFS Services.

Verifying Address Resolution and Aliasing

In order to deliver a message, sendmail must first resolve the recipient addresses appropriately. To determine how sendmail would route mail to a particular address, issue the following command:

/usr/sbin/sendmail  -bv  -v  -oL10  address [address...]

The -bv (verify mode) option causes sendmail to verify addresses without collecting or sending a message.

The -v (verbose) flag causes sendmail to report alias expansion and duplicate suppression.

The -oL10 (log level) option sets the log level to 10. At log level 10 and above, sendmail -bv reports the mailer and host to which it resolves recipient addresses.

For hosts that resolve to IPC mailers, MX hosts are not reported when using verify mode, because MX records are not collected until delivery is actually attempted.

If the address is not being resolved as you expect, you may have to modify one or more of the following:

  • The sendmail configuration file.

  • The files or programs from which file classes are generated.

  • The name server configuration.

  • The UUCP configuration.

More detailed information about how the configuration file is rewriting the recipient addresses is provided by address test mode:

/usr/sbin/sendmail  -bt

Verifying Message Delivery

You can observe sendmail's interaction with the delivery agents by delivering the message in verbose mode, as in the following example:

/usr/sbin/sendmail -v  myname@cup.hp.com

sendmail responds with the following information:

myname@cup.hp.com... aliased to myname@mymachine.cup.hp.com

sendmail is now ready for you to type a message. After the message, type a period (.) on a line by itself, as in the following example:

This is only a test.
.

sendmail responds with the following information:

myname@cup.hp.com... Connecting to local host (local)...
myname@cup.hp.com... Executing "/bin/rmail -d myname"
myname@cup.hp.com... Sent

sendmail has interfaces to three types of delivery agents. In verbose mode, sendmail reports its interactions with them as follows:

  • Mailers that use SMTP to a remote host over a TCP/IP connection (IPC mailers):

    In verbose mode, sendmail reports the name of the mailer used, each MX host (if any) to which it tries to connect, and each internet address it tries for each host. Once a connection succeeds, the SMTP transaction is reported in detail.

  • Mailers that run SMTP (locally) over pipes:

    The name of the mailer used and the command line passed to exec() are reported. Then the SMTP transaction is reported in detail. If the mailer returns an abnormal error status, that is also reported.

  • Mailers that expect envelope information from the sendmail command line and expect message headers and message body from standard input:

    The name of the mailer used and the command line passed to exec() are reported. If the mailer returns an abnormal error status, that is also reported.

Contacting the sendmail Daemon to Verify Connectivity

It is possible to talk to the sendmail daemon and other SMTP servers directly with the following command:

telnet  host  25

This can be used to determine whether an SMTP server is running on host. If not, your connection attempt will return "Connection refused."

Once you establish a connection to the sendmail daemon, you can use the SMTP VRFY command to determine whether the server can route to a particular address. For example,

telnet furschlugginer 25
220 furschlugginer.bftxp.edu SMTP server ready
vrfy aen
250 Alfred E. Newman <aen@axolotl.bftxp.edu>
vrfy blemph@morb.poot
554 blemph@morb.poot: unable to route to domain morb.poot
quit
221 furschlugginer.bftxp.edu SMTP server shutting down

Not all SMTP servers support the VRFY and EXPN commands.

Setting Your Domain Name

If sendmail cannot resolve your domain name, you may see the following warning message in your syslog file:

WARNING: local host name name is not qualified; fix $j in  config file

To resolve this problem, do one of the following:

  • In the /etc/mail/sendmail.cf file, uncomment the following line by deleting the pound sign (#) at the beginning of the line:

    Dj$w.Foo.COM

    Change "Foo.COM" to the name of your domain (for example, "HP.COM").

  • Modify the /etc/hosts file, making sure that the fully-qualified name of the system is listed first. For example, the entry in the file should be "255.255.255.255 dog.cup.hp.com dog" and not "255.255.255.255 dog dog.cup.hp.com."

Attempting to Start Multiple sendmail Daemons

If you attempt to start sendmail when there is already a sendmail daemon running, the following message may be logged to both the syslog file and to the console:

NO QUEUE: SYSERR (root) opendaemonsocket: cannot bind:
Address already in use

This message means that a sendmail daemon is already running. You can use either /sbin/init.d/sendmail stop or killsm to stop the running daemon.

Configuring and Reading the sendmail Log

sendmail logs its mail messages through the syslogd logging facility.

The syslogd configuration should write mail logging to the file /var/adm/syslog/mail.log. You can do this by adding the following line in /etc/syslog.conf:

mail.debug  /var/adm/syslog/mail.log

You can use the HP mtail utility to look at a specified number of the last lines of the log file:

mtail 15

By default, mtail displays the last 20 lines of the log file. For more information on the mtail utility, type man 1M mtail at the HP-UX prompt.

For more information about configuring syslogd, see Chapter 2 “Installing and Configuring Internet Services”.

Setting Log Levels

You can set the log level with the -oL option on the sendmail command line or on the OL line in the sendmail configuration file. At the lowest level, no logging is done. At the highest level, even the most mundane events are recorded. As a convention, log levels 11 and lower are considered useful. Log levels above 11 are normally used only for debugging purposes. We recommend that you configure syslogd to log mail messages with a priority level of debug and higher. sendmail's behavior at each log level is described in Table 4-6 “sendmail Logging Levels”.

Table 4-6 sendmail Logging Levels

Logging Level

Behavior

0

No logging.

1

Major problems only.

2

Message collections and failed deliveries.

3

Successful deliveries.

4

Messages being queued (due to a host being down, and so on).

5

Messages being added to the queue in routine circumstances.

6

Unusual but benign incidents, such as trying to process a locked queue file.

9

Log internal queue ID to external message ID mappings. This can be useful for tracing a message as it travels between several hosts.

10

The name of the mailer used, the host (if non-local), and the user name passed to the mailer are logged. If the log level is 10 or higher, sendmail also reports this information in -bv (verify) mode.

11

For successful deliveries to IPC mailers, the MX (mail exchanger) host delivered to (if any) and the internet address used for the connection are logged.

12

All incoming and outgoing SMTP commands and their arguments are logged at LOG_INFO.

13

Log bad user shells, world-writable files, and other questionable situations.

14-98

Debugging information. This information should be interpreted by your HP service representative.

 

Understanding syslog Entries

sendmail logs the following:

  • Failures beyond its control (SYSERR).

  • Administrative activities (for example, rebuilding the aliases database, and killing and restarting the daemon).

  • Events associated with mail transactions.

Log entries marked SYSERR indicate either system failures or configuration errors and may require the attention of the system administrator.

Each system log entry for a mail transaction has a queue ID associated with it. All log entries for the same input message have the same queue ID. Log level is normally set to 10 in the configuration file. At this level, the following information is logged for each delivery:

message-id=

If a message had a Message ID header line when it was input to sendmail, this is logged. sendmail can also be configured to add a Message ID header line if none is present. This ID uniquely identifies a message and can be used to trace the progress of a message through mail relays.

from=

The sender of the message and the message size are logged.

to=

The recipient of the message. One message may have multiple recipients. sendmail logs a separate entry for each separate delivery attempt it makes, so multiple recipients on the same host may appear on the same line, but multiple recipients on different hosts will appear on different lines. The delivery status of the message (whether message succeeded, failed, or was queued), the mailer, and the host used are logged.

Queued messages and SYSERRs are also logged.

Storing Off Old sendmail Log Files

At typical logging levels, every piece of mail passing through sendmail adds two or three lines to the mail log. A script to manage the growth of the mail log could be run nightly, at midnight, with an entry in root's crontab file. Following is an example of a crontab entry for a script called newsyslog:

0 0 * * * /var/adm/syslog/newsyslog

The following example shows what the script /var/adm/syslog/newsyslog might contain. The script assumes that syslog is configured to direct mail logging to /var/adm/syslog/mail.log.

#!/usr/bin/sh
#
# NEWSYSLOG: save only the last week's sendmail logging
#
cd /var/adm/syslog
mv mail.log.6 mail.log.7
mv mail.log.5 mail.log.6
mv mail.log.4 mail.log.5
mv mail.log.3 mail.log.4
mv mail.log.2 mail.log.3
mv mail.log.1 mail.log.2
cp mail.log mail.log.1
kill -1 `cat /var/run/syslog.pid`

Printing and Reading the Mail Queue

The current contents of the mail queue can be printed with the following command:

mailq

The output looks similar to this example:.

            Mail Queue (3 requests)

---QID--- --Size-- ----Q-Time---- ----Sender/Recipient-----

AA15841 86 Wed Feb 9 07:08 janet

(Deferred: Connection refused by med.hub.com)

ees@vetmed.umd.edu

ebs@surv.ob.com

AA15794 1482 Wed Feb 9 07:57 carole

bja@edp.cloq.potlatch.com

vls@ee.cmu.edu

AA15792 10169 Wed Feb 9 07:57 chuck

hrm@per.stmarys.com

sys6!sysloc!njm

vls@ce.umd.edu

The first entry is a message with queue ID AA15841 and a size of 86 bytes. The message arrived in the queue on Wednesday, February 9 at 7:08 a.m. The sender was janet. She sent a message to the recipients ees@vetmed.umd.edu and ebs@surv.ob.com. sendmail has already attempted to route the message, but the message remains in the queue because its SMTP connection was refused. This usually means that the SMTP server is temporarily not running on the remote host, but it also occurs if the remote host never runs an SMTP server. sendmail attempts to deliver this message the next time the mail queue is processed.

Two other messages in the queue are also routed for delivery the next time the mail queue is processed.

If mailq is run in verbose mode (with the -v option), then when it prints the queue, it will also show the priority of each queued message.

The Files in the Mail Queue

The files that sendmail creates in the mail queue all have names of the form zzTAAnnnnn, where zz is the type of the queue file and TAA is an identifier used to distinguish separate queue entries that happen to have the same process ID. sendmail starts with TAA and loops through TAB, TAC, and so on, until it is able to form a unique ID. The five-digit number (nnnnn) is the process ID of the process creating the queue entry.

A file whose name begins with df is a data file. The message body, excluding the header, is kept in this file.

A file whose name begins with qf is a queue-control file, which contains the information necessary to process the job.

A file whose name begins with xf is a transcript file. This file is normally empty while a piece of mail is in the queue. If a failure occurs, a transcript of the failed mail transaction is generated in this file.

The queue-control file (type qf) is structured as a series of lines, each beginning with a letter that defines the content of the line. Lines in queue-control files are described in Table 4-7 “Lines in Queue-Control Files”.

Table 4-7 Lines in Queue-Control Files

Initial Letter

Content of Line

B

The message body type (either 7bit or 8bitmime).

C

The controlling user for message delivery. This line always precedes a recipient line (R) that specifies the name of a file or program name. This line contains the user name that sendmail should run as when it is delivering a message into a file or a program's stdin.

D

The name of the data file. There can be only one D line in the queue-control file.

E

An error address. If any such lines exist, they represent the addresses that should receive error messages.

H

A header definition. There can be many H lines in the queue-control file. Header definitions follow the header definition syntax in the configuration file.

P

The current message priority. This is used to order the queue. Higher numbers mean lower priorities. The priority decreases (that is, the number grows) as the message sits in the queue. The initial priority depends on the message precedence, the number of recipients, and the size of the message.

M

A message. This line is printed by the mailq command and is generally used to store status information (that is, the reason the message was queued). It can contain any text.

R

A recipient address. Normally this has already been completely aliased, but it is actually re-aliased when the queue is processed. There is one line for each recipient.

S

The sender address. There can be only one sender address line.

T

The job creation time (in seconds since January, 1970). This is used to determine when to time out the job.

 

The following example is a queue-control file named qfAA00186. The sender is david, and the recipient is the local user carolyn. The current priority of the message is 17. The job creation time, in seconds since January, 1970, is 515 961 566. The last seven lines describe the header lines that appear on the message.

P17
T515961566
DdfAA00186
Sdavid
Rcarolyn
Hreceived: by lab; Thu, 8 May 86 12:39:26 mdt
Hdate: Thu, 8 May 86 12:39:26 mdt
Hfrom: David <david>
Hfull-name: David
Hreturn-path: <david>
Hmessage-id: <8605081839.AA00186@lab.HP>
Happarently-to: carolyn
© 2000 Hewlett-Packard Development Company, L.P.