 |
» |
|
|
|
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 DatabaseIf 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.
More detailed information about how the configuration file
is rewriting the recipient addresses is provided by address test
mode: 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: 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: 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: 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: 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”. 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 Entriessendmail 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 FilesAt 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: 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 QueueThe 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 |
|
