Mail Administration Guide

Administering the Mail Configuration

This section describes how to keep the mail service running smoothly.

Postmaster Duties

As postmaster your responsibilities for administering mail include the following tasks:

Check the mail queues to be sure mail is flowing in and out.
Check any downed systems where mail is backing up. If the system is not needed, delete it from the mail service or restart the system to keep mail moving.
Fix personal aliases, as requested.
Administer alias databases as people move in and out of the domain.
Set up temporary forwarding files.
Contact owners of mailing lists and help them fix mailing list problems.
Go through postmaster mail daily and look for problems, like broken .forward files and mail alias loops.
Answer questions outside the company.
Truncate log files periodically.

Mail Queue

Under high-load or temporary-failure conditions, sendmail puts a message into a job queue instead of delivering it immediately. The mail queue usually is processed automatically, but sometimes you might have to intervene. For example, if a major host is down for a period of time, the queue could become clogged. Although sendmail ought to recover gracefully when the host restarts, you could find performance unacceptably bad in the meantime.

Queue File Format

The sendmail program stores temporary queue files in the queue file /var/spool/mqueue. All such queue files have the form xfAA99999, where AA99999 is the ID for the file and x is the type. Table 2-3 shows the types of queue files.

Table 2-3 Types of Queue Files


Type	Description
`d`	Data file. The message body (excluding the header) is kept in this file.
`q`	Queue control file. This file contains the information needed to process the job.
`t`	A temporary file. This file is an image of the `qf` file when it is being rebuilt. When the rebuild is complete, the file is renamed `qf`.
`x`	Transcript file that shows everything that happens during that session.

A qf file contains a series of lines, each beginning with a code letter. Not all lines are included with each message, but a complete list is shown in Table 2-4.

Table 2-4 Codes for the qf File


Code	Description
`$`	A macro definition. The values of certain macros (currently `$r` and `$s`) are passed through to the queue run phase.
`B`	The body type. This line defines the body type. Legal values are 7BIT and 8BITMIME.
`C`	The controlling address. The syntax is localuser:aliasname. Recipient addresses following this line will be flagged so that deliveries will be run as the localuser (a user name from the password file or database); aliasname is the name of the alias that expanded to this address (for printing messages).
`D`	The name of the data file. There might only be one of these lines.
`E`	The error recipient name. Error messages are sent to this user instead of the sender. This line is optional.
`F`	Flag bits. This can be `r`, indicating that this is a response message and `w`, indicating that a warning message has been sent announcing that the mail has been delayed.
`H`	A header definition. There might be any number of these lines. The order is important: it represents the order in the final message. The syntax is the same as header definitions in the configuration file.
`L`	Information to compute the content length.
`M`	A message line, which is printed by using `sendmail` with the `-bp` flag and is generally used to store status information. It can contain any text.
`P`	The current message priority, which is used to order the queue. The higher the number, the lower the priority. The priority increases as the message stays in the queue. The initial priority depends on the message class and the size of the message.
`R`	A recipient name. There is one line for each recipient. The recipient name is normally completely aliased, but its aliases are redone when the job is processed. The recipient name must be at the end of the `qf` file.
`S`	The sender name. There might be only one of these lines.
`T`	The job creation or submission time in seconds, which is used to compute when the job times out.

See Chapter 3, Customizing sendmail Configuration Files for more information.

The queue is automatically run at the interval specified in the sendmail.cf file (the default is every hour). The queue is read and sorted, and then sendmail tries to process all jobs in order. The sendmail program first checks to see if a job is locked. If the job is locked, sendmail ignores the job; if the job is not locked, sendmail processes it.

If a major host goes down for several days, the queue may become prohibitively large and sendmail will spend time sorting the queue. You can fix this by moving the queue to a temporary place and creating a new queue. You can run the old queue later when the host is returned to service.

How to Print the Queue

You can print the contents of the queue with mailq.This command is equivalent to specifying the -bp flag to sendmail.

Type /usr/bin/mailq | more and press Return.

A list of the queue IDs, the size of the message, the date the message entered the queue, the message status, and the sender and recipients are displayed.

How to Force the Queue

Type /usr/lib/sendmail -q -v and press Return.

This forces the processing of the queue and displays progress of the jobs as the queue is cleared.

How to Run a Subset of the Mail Queue

Type /usr/lib/sendmail -qRstring and press Return.

You can run a subset of the queue at any time with the -qRstring (run queue where any recipient name matches string) or with -qInnnn (run just one message with queue ID nnnnn).

This example processes everything in the queue for recipient wnj.

# /usr/lib/sendmail -qRwnj

How to Move the Queue

Become root on the mail host.

Type /etc/init.d/sendmail stop and press Return.

This kills the old sendmail daemon to keep it from trying to process the old queue directory.

Type cd /var/spool and press Return.

Type mv mqueue omqueue; mkdir mqueue and press Return.

This moves the directory, mqueue, and all its contents to the omqueue directory and then creates a new empty Rmqueue directory.

Type chmod 755 mqueue; chown daemon.daemon mqueue; and press Return.

These commands set the permissions of the directory to read/write/execute by owner, and read/execute by group and others; these commands also set the owner and group to daemon.

Type /etc/init.d/sendmail start and press Return.

This starts a new sendmail daemon.

How to Run the Old Mail Queue

Type /usr/lib/sendmail -oQ/var/spool/omqueue -q and press Return.

The -oQ flag specifies an alternate queue directory and the -q flag says to run every job in the queue. Use the -v flag if you want to see the verbose output displayed on the screen.

When the queue is finally emptied type rmdir /var/spool/omqueue and press Return.

This removes the empty directory.

System Log

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, then error messages from syslogd are not reported.

Example 2-1 shows the default /etc/syslog.conf file:

Example 2-1 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
mail.debug--Debugging 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 time stamp, 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 System Administration Guide for information about loghost and the syslogd program.