This chapter describes IRIX sendmail, a facility for routing mail across an intranet. This chapter is for system administrators who set up and maintain the mail system on a station or network. It provides the information necessary for a straightforward implementation of sendmail. The following topics are covered:
IRIX sendmail supports Internet Version 6 (IPv6). All IPv6 addresses must be prefixed by IPv6:. If you specify IPv6 addresses in your access database, local-host-names file, and/or relay-domains file, the files may need to be updated.
For more information on IPv6, see “Internet Protocol Version 6” in Chapter 2.
For additional information on IRIX sendmail, see Appendix B, “IRIX sendmail Reference”.
The mail system is a group of programs that you can use to send messages to and receive messages from other users on the network. You can send mail through either UUCP or TCP/IP. The IRIX operating system uses Netscape Mail, System V /bin/mail, 4.3BSD /usr/sbin/Mail, and the sendmail application for its mail implementation.
The process of delivering mail involves these elements:
| User Interface | The user interface creates new messages and reads, removes, and archives received messages. Netscape Mail, System V /bin/mail, and 4.3BSD /usr/sbin/Mail are the user interfaces provided with IRIX. Man pages are available to fully describe the features of these interfaces, and Netscape has an online help system. | |
| Submission | When a mail is sent locally from a Mail User Agent (MUA ), the mail is handled by the Mail Submission Agent (MSA). The MSA is responsible for communicating the mail to the Mail Transfer Agent (MTA), that is, the local sendmail daemon running on the local host.
| |||
| Mail Routing | A mail router examines each message and routes it through the network to the appropriate station. The sendmail program not only routes messages, but also formats them appropriately for their recipient stations. | |||
| Mail Transfer | A mail transfer program transmits messages from one station to another. The sendmail application implements the Simple Mail Transfer Protocol (SMTP) over TCP/IP. For TCP/IP mail, sendmail acts as an integrated routing and transfer program. In all cases, mail transfer has a counterpart: mail reception. In most cases, a single program provides both functions. UUCP is a mail transfer program that uses its own protocols and runs over serial lines. | |||
| Mail Delivery | A mail delivery program deposits mail into a data file for later perusal by a user or another program. The /bin/mail -d program delivers local mail. |
After you compose a message by using Netscape Mail, /bin/mail, or /usr/sbin/Mail, the message is sent to sendmail, which attempts to determine the destination of the message. The sendmail application either calls /usr/bin/mail.local (for mail to a user on the local station) or passes the message to the appropriate mail transfer program (for mail to a user on a remote station).
When sendmail receives a message from another station, it analyzes the recipient address; then, it either calls /usr/bin/mail.local to complete the delivery if the local station is acting as a relay, or passes the message to the mail transfer program. For TCP/IP SMTP, sendmail also performs the mail transfer.
When you send a mail message on a network that uses TCP/IP, several layers of network software are involved. Figure 9-1 shows the layers of TCP/IP mail network software.
The Transmission Control Protocol (TCP) layer supports SMTP, which sendmail uses to transfer mail to other TCP/IP stations. The sendmail application is responsible for calling local delivery programs, mail routing, and TCP/IP mail transfer; it may also call other mail transfer programs. For example, sendmail uses the UUCP transmission program to handle messages sent to UUCP stations.
The sendmail implementation features aliasing, forwarding, automatic routing to network gateways, and flexible configuration.
In a simple network, each node has an address, and resources can be identified with a host-resource pair. For example, a mail system can refer to users with a host–user-name pair. Station names and numbers must be administered by a central authority, but user names can be assigned locally to each station.
In an intranet, multiple networks with different characteristics and management must communicate. In particular, the syntax and semantics of resource identification change. You can handle certain simple cases by using improvised techniques, such as providing network names that appear local to stations on other networks. However, the general case is extremely complex. For example, some networks require point-to-point routing, which simplifies the database update problem, because only adjacent stations are entered into the system tables; others use end-to-end addressing. Some networks use a left-associative syntax; others use a right-associative syntax, causing ambiguity in mixed addresses.
Intranet standards seek to eliminate these problems. Initially, these standards proposed expanding the address pairs to address triples, consisting of network, station, resource. Network numbers must be universally agreed upon; stations can be assigned locally on each network. The user-level presentation was quickly expanded to address domains, composed of a local resource identification and a hierarchical domain specification with a common static root, as defined in RFC 1034. The domain technique separates the issue of physical versus logical addressing. For example, an address of the form jane@iris1.company.com describes only the logical organization of the address space.
The sendmail application bridges the gap between the world of totally isolated networks that know nothing of each other and the clean, tightly coupled world of unique network numbers. This application can accept old arbitrary address syntaxes, resolving ambiguities by using heuristics specified by the network administrator, as well as domain-based addressing.It helps guide the conversion of message formats between disparate networks. In short, sendmail is designed to assist a graceful transition to consistent intranet addressing schemes. This version of sendmail has the ability to connect to servers running on named sockets.
The design goals for the sendmail application included the following:
Message delivery should be reliable, guaranteeing that every message is correctly delivered or at least brought to the attention of a human for correct disposal; no message should ever be completely lost.
Existing software should be used to do actual message delivery whenever possible.
The sendmail application should be easy to expand to fairly complex environments.
Configuration should not be compiled into the code.
The sendmail application should let various groups maintain their own mailing lists, and let individuals specify their own forwarding, without modifying the station's alias file.
Each user should be able to specify the mailer to execute to process mail being delivered. This feature allows users with specialized mailers that use a different format to build their environments without changing the system, and facilitates specialized functions (such as returning an “I am on vacation” message).
To minimize network traffic, addresses should be batched to a single station where possible, without assistance from the user.
Figure 9-2 illustrates the sendmail system structure that is based on the original design goals for sendmail.
The sendmail application neither interfaces with the user nor does actual mail delivery. Rather, it collects a message generated by a user agent program such as Berkeley Mail, edits the message as required by the destination network, and calls appropriate mailers to do mail delivery or queueing for network transmission. The exception is mail sent to a file; in this case, sendmail delivers the mail directly. This discipline allows the insertion of new mailers at minimum cost.
Because some of the senders may be network servers and some of the mailers may be network clients, sendmail can be used as an intranet mail gateway. The sendmail application supports multiple queues.
For security reasons, sendmail is no longer implemented as a setuid-root program. Rather, it is implemented as a setgid-sgismmsp program. The sendmail functionality is now split between MTA and MSA programs and requires new account and group categories both named sgismmsp. See “sendmail Accounts”.
Understanding the sendmail programs requires understanding a variety of components. Some of these components are daemons, scripts, files, and commands. This section describes the various sendmail components :
For sendmail to process incoming mail, several daemons must be running. The sendmail daemon is the sendmail program with specific flags. (Appendix B, “IRIX sendmail Reference” describes the sendmail command-line flags in detail.) The daemon is automatically started by the /etc/init.d/mail script at station startup. Controlling parameters are read from /etc/config/sendmail.options file. If this file does not exist, use the following command:
/usr/lib/sendmail -bd -q15m |
The -bd flag causes sendmail to run in daemon mode. The -q15m flag causes sendmail to fork a subdaemon for queue processing every 15 minutes. The -bd and -q flags can be combined in one call. sendmail runs the queue(s) in the background when invoked with the -q option unless the -qf option or -v are used.
The /etc/init.d/mail script also starts the following daemon:
/usr/lib/sendmail -L sendmail.mspqueue -Ac -q15m
This daemon is responsible for clearing the mail queued by the Mail Submission Agent. It does not listen to port 25. It is invoked with the -q15m argument read from /etc/config/sendmail.options file.
The sendmail program requires the following entries in the /etc/passwd and /etc/group files. When you upgrade to IRIX 6.5.19 (and later), these entries are added automatically to the /etc/passwd and /etc/group. If /etc/shadow password exists, it also updates this file using the pwconv command see the pwconv(1M) man page for more information.
If these entries need to be recreated, perform the following command as root:
/etc/mail/passwd.add
Add entries to the appropriate files as follows:
Add the following entry to /etc/passwd:
sgismmsp:*LK*:25:25:Sendmail Mail Submission Account:/dev/null:/dev/null
Add the following entry to /etc/group:
sgismmsp:*:25:sgismmsp
Add the following entry to /etc/passwd.sgi:
sgismmsp:noshow
Several scripts provided with your system perform common functions in sendmail. Use the following scripts whenever possible, because they have been tested and are known to perform the task correctly:
Under rare circumstances, a user may need to stop or start the sendmail daemon manually. For example, to implement changes to the configuration file, you must stop all running sendmail processes and restart the sendmail daemon before the new configuration will take effect. To simplify the task of starting and stopping sendmail, IRIX provides a shell script called /etc/init.d/mail.
This script takes a single argument, either start or stop, which starts or stops the sendmail daemon respectively. You must be superuser (root) to use this script. For example, to stop sendmail, use the following command:
/etc/init.d/mail stop |
When /etc/init.d/mail is called with the start argument, it verifies the existence and permissions of various sendmail related files and directories (see “sendmail Related Files and Directories”,). If a required component such as the /var/spool/mqueue directory is missing, the script creates it. For more complex components, such as /etc/aliases, the script exits with a message.
If the sendmail_cf chkconfig flag is on, new /etc/sendmail.cf and /etc/mail/submit.cf files are generated from the /etc/sendmail.mc and/etc/mail/submit.mc files, respectively.
When the /etc/init.d/mail script is called with the stop argument, it kills all running sendmail processes with a SIGTERM signal.
 | Note: Station start-up includes an automatic call to the /etc/init.d/mail script with the start argument. If station start-up runs in verbose mode (that is, /etc/chkconfig verbose on), the following message displays, verifying that sendmail has been started: |
Mailer daemons: sendmail -bd -q15m ... sendmail.mspqueue -q15m |
For more information, examine the /etc/init.d/mail script.
The /usr/etc/configmail script provides an interface between command line input and the sendmail.mc file. The configmail parameters are maintained in the sendmail.mc file. The configmail script migrates configmail parameter changes to the sendmail.mc file.
Historically, the configmail script has been used as the primary way to manage the sendmail.cf configuration file. You can use configmail to generate the /etc/sendmail.cf file from the parameters that are stored in the sendmail.mc file by using the following command:
configmail mc2cf
Because the /etc/sendmail.mc file offers more flexibility than configmail, you should modify sendmail.mc directly. Direct editing of the /etc/sendmail.cf file is not supported.
A new /etc/mail/submit.cf file is generated from the /etc/mail/submit.mc file. Direct editing of the /etc/mail/submit.cf file is not supported.
The sendmail configuration files and directories are as follows:
The sendmail application also can be tailored with flags and options from the command line. For more information, see the sendmail(8) man page.
At the heart of the sendmail program is the sendmail configuration file, /etc/sendmail.cf. The sendmail.cf file is an ASCII file that contains most of the configuration information and is read at run time. This file encodes options, header declarations, mailer declarations, trusted user declarations, message precedences, address-rewriting rules, macro definitions, and class definitions.
To successfully set up sendmail, the mail administrator must know which sendmail.cf macros and variables to change.
The submit.mc file is the configuration file used by the MSA portion of sendmail. Normally, you are not required to change it. It is written for the m4 processor and is also handled by the configmail mc2cf command. The result of this conversion is the submit.cf file.
The sendmail.mc file contains a series of commands that will be used to build a sendmail.cf file. The sendmail.mc file is also used to enable various features of the sendmail.cf file. The sendmail.mc file is written for the m4 macro processor. Thus, all quoted strings use both open and close quotes (`example'). For details on configuring sendmail.mc, see “Configuring sendmail”.
To generate a sendmail.cf file from a sendmail.mc file, use the following command:
configmail mc2cf
The sendmail program expects all configuration information to reside in the /etc/mail directory, making it easier to access all sendmail configuration-related files. Because of this, /etc/init.d/mail script will make the appropriate symbolic links from old locations onto the /etc/mail location. For example, /etc/mail/sendmail.cf is linked to /etc/sendmail.cf. The details of these operations can be found in the mail startup script in the function make_symlinks_893. Also note that no files in /etc/mail directory are overwritten.
The sendmail.hf file is the Simple Mail Transfer Protocol (SMTP) help file. It contains some brief information about the various SMTP commands.
The sendmail.st file collects statistics related to sendmail. By default, the file is not present. You can create the file using the touch command. If the file is present, sendmail automatically updates the file with relevant sendmail statistics.
The aliases file contains the text form of the alias database used by the sendmail program. The alias database contains aliases for local mail recipients. For example, the following alias delivers mail addressed to jd on the local station to johndoe@company.com:
jd:johndoe@company.com |
| Note: The newaliases program must be run after modifying the alias database file. For more information about building the alias database, see “Building the sendmail Aliases Database”. |
The mail queue, /var/spool/mqueue, is the directory in which the mail queue and temporary files reside. The messages are stored in various queue files that exist under the /var/spool/mqueue directory. Queue files take the following forms:
qf*—control (queue) files for messages
df*—data files
tf*—temporary files
nf*—a file used when a unique ID is created
xf*—transcript file of the current session
Normally, a sendmail subdaemon processes the messages in this queue periodically, attempting to deliver each message. (The /etc/init.d/mail script starts the sendmail daemon so that it forks a subdaemon every 15 minutes to process the mail queue.) Each time sendmail processes the queue, it reads and sorts the queue, then attempts to run all jobs in order.
| Note: Any mail queue files generated this way cannot be read by previous versions of sendmail. |
This is the mail queue directory used by the MSA portion of sendmail. Files in this directory have the same format as described for the /var/spool/mqueue directory. By default, as defined in the configmail.options file, this directory is cleaned every 15 minute by a second daemon invocation of sendmail (for more information, see “sendmail Daemon”).
The /usr/lib/sendmail.cf_m4 directory contains the data that is used to generate the sendmail.cf file. The contents of this directory are similar to the cf subdirectory from the sendmail source distribution. The sendmail.mc file selects settings and features implemented by the files in the /usr/lib/sendmail.cf_m4 directory. Use the following command to generate a new sendmail.cf file from these files:
configmail mc2cf
This section explains how the aliases database for sendmail runs, and indicates possible problems and errors. Sections are as follows:
The aliases database is a NEWDB database that contains mail aliases that are used by the sendmail program. The text form of the database is maintained in the /etc/aliases file. The aliases are of the following form:
name: name1 [, name2, ...] |
For example, the following command delivers mail addressed to jd to johndoe@company.com:
jd:johndoe@company.com |
| Note: Only the local part of an address can be aliased. For example, the following command is wrong and does not have the desired effect: |
jd@big.university.edu:jd@company.com
The sendmail application consults the alias database only after deciding that the message (as originally addressed) should be delivered locally, and after it has rewritten the address to contain only the local part.
An alias continuation line must start with a space or a tab. Blank lines and lines beginning with the number sign (#) are treated as comments.
At startup, sendmail automatically uses the newdb library to process the /etc/aliases file into the /etc/aliases.db files. Using these files to resolve aliases improves performance.
When using the NEWDB version of the database to maintain aliases, sendmail uses the /etc/alias.db file. When building the NEWDB version of the database, sendmail checks the left-hand side of each entry to make sure that it is a local address. Then sendmail issues a warning for each entry in /etc/aliases with a non-local left-hand side. Such entries are not entered into the NEWDBversion of the database.
Previous versions of IRIX sendmail looked for the keyword +:+ in the /etc/alias file and enabled NIS lookups for you. You must now to do this explicitly. By default, IRIX sendmail uses the /etc/aliases database and the NSD map, mail.aliases, for lookups. If you have configured nsd to use NIS, you do not need to do anything more. If you have not done this configuration, you can place the following line in the sendmail.mc file:
define (ALIAS_FILE',/etc/aliases,nsd:mail.aliases') dnl |
If the configuration or the command line specifies the D option, sendmail automatically tries to rebuild the alias database when it is out of date.
The sendmail application rebuilds the alias database if either of the following conditions exists:
The NEWDB version of the database is in mode 666.
sendmail is running setuid to root.
Note: Auto-rebuild can be dangerous on heavily loaded stations with large alias files. If it takes more than 5 minutes to rebuild the database, there is a chance that several processes will start the rebuild process simultaneously.
The newaliases program is used to rebuild the NEWDB version of the aliases database. This program must be run any time the text version of the aliases file is modified. If newaliases is not run after making changes to the aliases file, the changes are not incorporated into the NEWDB alias database and are not seen by the sendmail program.
To rebuild the NEWDB version of the database without restarting sendmail, enter the following command:
newaliases |
Executing the newaliases command is equivalent to giving sendmail the -bi flag, as in the following example:
/usr/lib/sendmail -bi |
You can test the aliases database with the -bv flag of the sendmail program. For more details, see Appendix B, “IRIX sendmail Reference”.
Problems can occur with the aliases database, especially if a sendmail process accesses the NEWDB version before it is completely rebuilt. Two circumstances can cause this problem:
One process accesses the database while another process is rebuilding it.
The process rebuilding the database dies because it has been killed, or a station crash has occurred before completing the rebuild.
The sendmail application has two techniques for trying to relieve these problems. First, to avoid the problem of a partially rebuilt database, sendmail ignores interrupts while rebuilding the database. Second, at the end of the rebuild it adds an alias of the following form (which is not normally legal):
@: @ |
Before sendmail accesses the database, it ensures that this entry exists. For this action to occur, the configuration file must contain the -a option.
If the @:@ entry does not exist, sendmail waits for it to appear. After the specified waiting period elapses, sendmail itself forces a rebuild. For this action to occur, the configuration file must include the D option. If the D option is not specified, a warning message is generated and sendmail continues.
If an error occurs when mail is sent to a certain address (x, for example), sendmail looks for an alias of the following form to receive the errors:
owner-x |
This scheme is typically useful for a mailing list where a user mailing to the list has no control over the maintenance of the list itself; in this case the list maintainer would be the owner of the list. For example, the following would cause jd@1company.com to get the error that occurs when someone sends mail to unix-hackers, and sendmail finds the phony user nosuchuser on the list.
unix-hackers: jd@company1.com, ed@big.university.edu,nosuchuser, jane@company2.com owner-unix-hackers: jd@company1.com |
This section provides sendmail configuration information. It does not attempt to be a complete reference for programming the sendmail.cf file and all of its features. For details of sendmail configuration, see the following resources:
sendmail, 2nd Edition by Bryan Costales & Eric Allman. This book, considered the definitive sendmail authority, is available from O'Reilly & AssociatesInc. (ISBN: 1-56592-222-0) (URL: http://www.oreilly.com/catalog/sendmail2)
The sendmail.org website (http://www.sendmail.org) has a large amount of sendmail information.
The /usr/lib/sendmail.cf_m4/README file includes detailed information on the sendmail.mc file and the m4 macro processor features and configuration. This file includes define statements that you can make to change parameters.
The sendmail.cf file is read in real time by each copy of sendmail. There is no frozen version of this file, which previous versions of IRIX sendmail supported. This section does not provide details of the sendmail.cf file. Instead, it describes how to configure and generate it by using the sendmail.mc file
The sendmail.mc file is a set of definitions, configurations, and commands to enable various features. Use this file to create the sendmail.cf file from the prototype files located in the /usr/lib/sendmail.cf_m4 directory.
To create a sendmail.cf file from the definitions in sendmail.mc file, use the following command:
configmail mc2cf
By using the defines and features in the following sections, you can implement a number of complex features, including, but not limited to those in the following list:
Masquerading and relaying
Controlling anti-spam configuration
Adding new mailers or rulesets
Using non-smtp based configurations
Using mailer tables
Using userdb to map full names
The /usr/lib/sendmail.cf_m4/README file describes the sendmail configuration files and explains how to create a sendmail.cf file for use with sendmail. This section shows the headings and describes the contents of the README file and covers the following topics:
The sendmail application uses the m4 macro processor (simply known as m4) to “compile'' the configuration files. M4 is stream-based, that is, it does not understand about lines. For this reason, in some places you may see the word ``dnl'', which stands for ``delete through newline''; essentially, it deletes all characters starting at the ``dnl'' up to and including the next newline character. In most cases, sendmail uses this only to avoid unnecessary blank lines in the output. Other important directives are define(A, B) which defines the macro``A'' to have value ``B''. Macros are expanded as they are read, so one normally quotes both values to prevent expansion. For example, define(`SMART_HOST', `smart.foo.com') One word of warning: M4 macros are expanded even in lines that appear to be comments. For example, if you have See FEATURE(`foo') above it will not do what you expect, because the FEATURE(`foo') will be expanded. This also applies to And then define the $X macro to be the return address because ``define'' is an M4 keyword. If you want to use them, surround them with directed quotes, `like this'. For more information on M4, see /usr/lib/sendmail.cf_m4/README file.
This section of the README file describes the /etc/mail configuration directory for sendmail related files. For a list of files, see the/usr/lib/sendmail.cf_m4/README file.
You must define an operating system environment, or the configuration file build will fail. There are several environments available; look at the ostype directory for the current list. This macro changes things like the location of the alias file and queue directory. For more information on the ostype directory, see the/usr/lib/sendmail.cf_m4/README file.
You will probably want to collect domain-dependent defines into one file, referenced by the DOMAIN macro. For example, the Berkeley domain file includes definitions for several internal distinguished hosts. For more information on the DOMAIN macro, see the/usr/lib/sendmail.cf_m4/README file.
This section of the README file describes the mailers available with this release. As a general rule, put the MAILER definitions last in your.mc file. For more information on sendmail mailers, see the /usr/lib/sendmail.cf_m4/README file.
Special features can be requested using the FEATURE macro. For more information on the FEATURE macro, see the /usr/lib/sendmail.cf_m4/README file.
There are four UUCP mailers available. For more information, see the /usr/lib/sendmail.cf_m4/README file.
For more complex configurations, you can define special rules. The macro LOCAL_RULE_3 introduces rules that are used in canonicalizing the names. For more information, see the /usr/lib/sendmail.cf_m4/README file.
You can have your host masquerade as another. For more information, see the /usr/lib/sendmail.cf_m4/README file.
The primary anti-spam features available in sendmail are:
Relaying is denied by default
Better checking on sender information
Access database
Header checks
For more information on anti-SPAM features, see the /usr/lib/sendmail.cf_m4/README file.
Sometimes you may need to add entirely new mailers or rulesets. They should be introduced with the constructs MAILER_DEFINITIONS and LOCAL_RULESETS, respectively. For more information, see the /usr/lib/sendmail.cf_m4/README file.
Sendmail supports mail filters to filter incoming SMTP messages according to the Sendmail Mail Filter API documentation. For more information, see the /usr/lib/sendmail.cf_m4/README file.
In addition to the queue directory (which is the default queue group called mqueue), sendmail can deal with multiple queue groups, which are collections of queue directories with the same behavior. For more information, see the /usr/lib/sendmail.cf_m4/README file.
If your host is known by several different names, you need to augment class {w}. This is a list of names by which your host is known, and anything sent to an address using a host name in this list will be treated as local mail. For more information, see the /usr/lib/sendmail.cf_m4/README file.
To use mailertables feature, you have to create an external database containing the routing information for various domains. For more information, see the /usr/lib/sendmail.cf_m4/README file.
The user database was not originally intended for mapping full names (for example., Eric.Allman => eric), but some sites are using it that way. It is recommended that you set up aliases for this purpose instead since you can specify multiple alias files. For more information, see the /usr/lib/sendmail.cf_m4/README file.
Sometimes it is convenient to merge configuration on a centralized mail machine, for example, to forward all root mail to a mail server. In this case it might be useful to be able to treat the root addresses as a class of addresses with subtle differences. You can do this using plussed users. For more information, see the /usr/lib/sendmail.cf_m4/README file.
There are a large number of configuration options that you do not normally need to change. For a list of M4 variables that can tune your configuration, see the /usr/lib/sendmail.cf_m4/README file.
The purpose of the message submission program (MSP) is explained in the sendmail security section. For a list of caveats and a few hints how tune the default configuration (which is installed as submit.cf), see the /usr/lib/sendmail.cf_m4/README file.
Files that define classes, for example, F{classname}, consist of lines each of which contains a single element of the class. For an example of /etc/mail/local-host-names file, see the /usr/lib/sendmail.cf_m4/README file.
This section describes the subdirectories in the directory. For more information, see the /usr/lib/sendmail.cf_m4/README file.
These aspects of managing the sendmail environment are covered in the following sections:
Further aspects of managing the sendmail environment are covered in Appendix B, “IRIX sendmail Reference”.
After customizing the sendmail.cf files and modifying the aliases database, you are ready to start sendmail.
By default, IRIX automatically starts sendmail at station startup by using the shell script /etc/init.d/mail. However, if you are configuring and testing sendmail and do not want to reboot the station, you can run the /etc/init.d/mail script manually. You should always use the mail script to stop and start sendmail. It processes and checks sendmail related files and programs in the correct order.
Start the sendmail daemon:
/etc/init.d/mail start |
If you need to stop sendmail, enter the following command:
/etc/init.d/mail stop |
You can list the contents of the queue by using the mailq command or by specifying the -bp flag on the sendmail command. The list includes a listing of the queue IDs, the size of each message, the date the message entered the queue, and the sender and recipients.
The -q flag (with no value) forces sendmail to process the queue. It is sometimes useful to use the -v flag (verbose) also when running the queue manually, as follows:
/usr/lib/sendmail -q -v
|
In verbose mode, sendmail displays the SMTP chatter with other stations as well as messages indicating any delivery errors and final message disposition.
Because of the locking algorithm, it is impossible for one job to freeze the queue. However, an uncooperative recipient station or a program recipient that never returns can consume many station resources. Unfortunately, there is no way to resolve this situation without violating the SMTP protocol that sendmail uses.
In some cases, if a major station goes down for a couple of days, a prohibitively large queue may be created. As a result, sendmail spends an inordinate amount of time sorting the queue. You can remedy this situation by moving the queue to a temporary location and creating a new queue. The old queue can be run later when the offending station returns to service.
Use the following commands to move the entire queue directory. The mail queue should be owned by root and belong to the mail group.
Change to the /var/spool directory.
cd /var/spool
Give the old mail queue another filename.
mv mqueue omqueue
Make another directory for the new mail queue.
mkdir mqueue
Change permissions so that the directory is owned by root.
chmod 755 mqueue
Then kill the existing sendmail daemon (because it will still be processing in the old queue directory) and create a new daemon:
Stop the sendmail daemon that is currently running.
/etc/init.d/mail stop
Start a new sendmail daemon.
/etc/init.d/mail start
To run the old mail queue, use the following command:
/usr/lib/sendmail -oQ/var/spool/omqueue -q
The -oQ flag specifies an alternate queue directory, and the -q flag causes sendmail to run every job in the queue once and then return. Use the -v (verbose) flag to watch what is going on. It might be necessary to run the old mail queue a number of times before all of the messages can be delivered.
When the queue is finally emptied, the directory can be removed with the following command:
rmdir /var/spool/omqueue
As an alternative to the alias database, users can put a file with the name .forward in their home directories. If the .forward file exists in a user's home directory, sendmail redirects mail for that user to the list of recipients in the file. The recipients are separated by commas or new lines. For example, if the home directory for user jane has a .forward file with the following contents, any mail arriving for jane is redirected to the specified accounts:
zippy@state.edu bongo@widgets.com |
The .forward file also allows the user to redirect mail to files or programs. A .forward file with the following contents redirects any incoming messages to jd@company.com, appends a copy of the message to the file /var/tmp/mail.log, and pipes a copy of the message to stdin of the /usr/bin/mymailer program:
jd@company.com /var/tmp/mail.log | /usr/bin/mymailer |
In general, file-type recipients must be writable by everyone. However, if sendmail is running as root and the file has setuid or setgid bits set, the message is written to the file.
Users can redirect mail to themselves in addition to sending it to other recipients. This feature is particularly useful if the users want to continue to receive mail in their own mailboxes while passing copies of each incoming message to some alternative destination. For example, if the home directory for user john contains a .forward file with the following contents:
\john, |/usr/sbin/vacation |
The sendmail program behaves as follows:
It sends each incoming message to john's regular mailbox; the backslash (\) preceding the name indicates that no further aliasing is to occur.
It pipes a copy of each message to stdin of the /usr/sbin/vacation program. (The vertical bar [|] is the standard UNIX pipe symbol.)
MX records are resource records in the BIND database. Each record contains the name of a target station, a preference level, and the name of an exchanger station that handles mail for the target station. (The exchanger station may be the target station itself.)
The BIND database can contain several MX records for each target station; the record with the lowest preference level is tried first.
MX records provide a way to direct mail to alternative stations. Using MX records lets you eliminate static routes from your sendmail configuration file.
For each destination station contacted by means of an IPC-type mailer (P=[IPC] in the mailer definition line), sendmail queries the DNS database for MX records associated with the destination station. If the MX query succeeds, mail will be routed through the appropriate exchanger station found among the returned MX records as described in RFC 974 and required by RFC 1123.
The result is that this version of sendmail and previous versions may use different methods to route mail to stations for which MX records are available. See Appendix B, “IRIX sendmail Reference”, for information regarding mailer definitions.