Administering Your Mail Configuration
The following sections describe how to keep mail services running smoothly.
Duties of Postmaster
As postmaster, your responsibilities for administering mail include the following tasks.
Check the mail queues to make sure that mail is flowing in and out.
Check any down systems where mail is backing up. If the system is not needed, delete it from the mail system or bring it up to keep mail moving.
Fix personal aliases, as requested.
Administer the Aliases 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, broken .forward files, and mail alias loops. Fix the problem or tell people how to fix it.
Answer questions about mail delivery problems from outside of the company.
Truncate log files periodically.
The Mail Queue
Under high load or temporary failure conditions, sendmail puts a message into a job queue in the /var/spool/mqueue directory instead of delivering it immediately. Ordinarily, the mail queue is processed automatically. Sometimes, however, you may have to intervene manually. For example, if a major host is down for a period of time, the queue may become clogged. Although sendmail ought to recover gracefully when the host comes up, you may find performance unacceptable in the meantime.
Printing the Mail Queue
Format of Queue Files
The sendmail program stores temporary queue files in /var/spool/mqueue. All such queue files have the form xAA99999, where AA99999 is the ID for the file and x is the type. Table 20 shows the types of queue files.
| Type | Description |
|---|---|
| d | A data file. The message body (excluding the header) is kept in this file. |
| l | A lock file. If this file is present, the job is currently being processed, and running the queue will not process it. For this reason, an extraneous lock file can make a job seem to disappear. |
| n | This separate file is created whenever an ID is created. It ensures that no mail can ever be destroyed because of a race condition. This file should not exist for more than a few milliseconds at any given time. |
| q | The 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 | A transcript file that exists during the life of a session and shows everything that happens during that session. |
The qf file contains a series of lines, each beginning with a code letter, as shown in Table 21. See Chapter 2, “Customizing sendmail Configuration Files,” for more information about qf file codes.
| Code | Description |
|---|---|
| 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 sits in the queue. The initial priority depends on the message class and the size of the message. |
| T | The job creation/submission time in seconds, which is used to compute the time when the job times out. |
| D | The name of the data file. |
| M | A message. This line, which is printed by sendmail with the -bp flag, is generally used to store status information. It can contain any text. |
| S | The sender name. |
| E | Error recipient name. Error messages are sent to this user instead of to the sender. This line is optional. |
| H | A header definition. Any number of these lines can be present. The order is important: It represents the order in the final message. The syntax is the same as in the header definitions in the configuration file. |
| R | A recipient name. Each recipient has one line. The recipient name normally is completely aliased, but it is actually re-aliased when the job is processed. The recipient name must be at the end of the qf file. |
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 by message priority, and then sendmail tries to process all jobs in order. The sendmail program first checks to see if a job is locked. If locked, it skips the job; if not locked, sendmail processes it.
If a major host goes down for several days, the queue may become prohibitively large, and sendmail spends lots of time sorting the queue. You can fix this problem 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.
 | Forcing the Queue |
To process the mail in the queue now, type /usr/lib/sendmail -q -v and press Return. The queue is forced and the progress of the jobs in the queue is displayed as the queue is cleared.
Moving the Mail Queue
Use the following steps to move the mail queue.
1. |  Become superuser on the mail hub. |
2. |
Type /etc/init.d/sendmail stop and press Return. The sendmail daemon is stopped to keep it from trying to process the old queue directory. |
3. |
Type cd /var/spool and press Return. |
4. |
Type mv mqueue omqueue; mkdir mqueue and press Return. The mqueue directory and all of its contents are moved to the directory omqueue, and a new empty mqueue directory is created. |
5. |
Type chmod 755 mqueue; chown daemon.daemon mqueue and press Return. Permissions of the directory are set to read/write/execute by others and read/execute by group and by others. Owner and group are set to daemon. |
6. |
Running the Old Mail Queue
Use the following steps to run the old mail queue.
1. |
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. |
2. |
When the queue is finally emptied, type rmdir/var/spool/omqueue and press Return. The empty directory is removed. |
You can run a subset of the queue at any time with the -Rstring option (run queue where any recipient name matches string) or with the -Mnnnnn option to sendmail. (Run just one message with queue ID nnnnn.)
To run a subset of the mail queue, type /usr/lib/sendmail -Rstring and press Return. In the following example, everything in the queue for recipient wnj is processed.
oak% /usr/lib/sendmail -Rwnj
The System Log
The mail service uses the syslogd program to log most errors. The default is for syslogd to send messages to a system identified as the log host.
Just as you define a system called mailhost as a mail hub to handle mail relaying, 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 can specify a loghost in the Hosts database. If you specify no loghost, then error messages from syslogd are not reported.
The following example shows the default /etc/syslog.conf file.
#ident "@(#)syslog.conf 1.5 98/12/14 SMI" /* SunOS 5.0 */ # # Copyright (c) 1991-1998 by Sun Microsystems, Inc. # All rights reserved. # # 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. # *.err;kern.notice;auth.notice /dev/sysmsg *.err;kern.debug;daemon.notice;mail.crit /var/adm/messages *.alert;kern.err;daemon.err operator *.alert root *.emerg * # 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/sysmsg user.err /var/adm/messages user.alert `root, operator' user.emerg * )
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
When the syslogd daemon starts up, it creates the file /etc/syslog.pid, which contains its process ID number. The following example shows a syslog.pid file.
oak% more /etc/syslog.pid
179
oak%
The following example shows the end of a system log file.
oak% tail /var/log/syslog Apr 4 09:47:41 oak sendmail[14192]: AA14190: to=<uucp>, delay=00:00:01, stat=Sent Apr 4 09:47:50 oak sendmail[14195]: AA14195: message-id=<9304041647 [email protected]> Apr 4 09:47:50 oak sendmail[14195]: AA14195: from=<uucp>, size=378, class=0, received from ignatz (129.144.52.69) Apr 4 09:47:51 oak sendmail[14197]: AA14195: to=<uucp>, delay=00:00:01, stat=Sent Apr 4 10:44:27 oak sendmail[14280]: AA14280: message- id=<[email protected]> Apr 4 10:44:27 oak sendmail[14280]: AA14280: from=<winsor@castle>, size=892, class=0, received from zigzag (129.144.1.38) Apr 4 10:44:27 oak sendmail[14282]:AA14280: to=lautner@oak, delay=00:00:01, stat=Sent Apr 4 10:52:43 oak sendmail[14307]: AA14307: message- id=<[email protected]> Apr 4 10:52:43 oak sendmail[14307]: AA14307: from=<nixed@pigglet>, size=918,class=0, received from piglet (129.144.154.7) Apr 4 10:52:44 oak sendmail[14309]: AA14307: to=lautner@ oak, delay=00:00:01, stat=Sent oak%
NOTE
Because of the length of each entry, space has been added between entries in this example to improve readability.
Each line in the system log contains a timestamp, the name of the system that generated it, and a message. syslog 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.