2.5 System Setup

In almost all cases, the Build system included in the sendmail distribution does an excellent job of ensuring that the sendmail installation and system setup coincide to allow email to work properly on the server. Mostly, this effort involves selecting the right Local Delivery Agent (LDA) and assigning proper permissions to the mail spool and queue(s). Under some scenarios, manual intervention might be warranted or required. This section covers some of these situations.

First, let's consider the way things are set up under a typical installation using either the stock sendmail that comes with the system or an Open Source installation using version 8.11 or earlier. Two distinct strategies for email delivery exist that are typically aligned with either the Berkeley or System V flavor of UNIX.

2.5.1 The Queue

In both cases, the message queue, /var/spool/mqueue, is owned by the root user and readable and writable only by root. In most cases, non-root users have no reason to access anything in the queue. Anyone who wants information about queued messages should use the mailq command. The mailq command is just a link to the sendmail binary. Invoking mailq works the same way as running sendmail -bp. A system administrator may prevent unprivileged users from seeing the contents of the queue by setting the restrictmailq variable in sendmail's privacy options in the .mc file:

 define('confPRIVACY_FLAGS', 'restrictmailq') 

Starting with sendmail 8.12, things work a bit differently. Namely, sendmail is no longer installed as set-user-ID root by default. Under this configuration, the sendmail daemon still runs as root at system start-up time. As a consequence, however, sendmail invoked by a non-root user on the command line will not have root permission. This result presents a dilemma. Should we then allow non-root access to the queue, or should we prevent the sending of email from the command line? The answer is "neither." The sendmail 8.12 default installation process creates two configuration files and two queues. The sendmail process started as a daemon by root at system start-up uses /var/spool/mqueue accessible by root only as its queue and /etc/mail/sendmail.cf as its configuration file. A sendmail process started by a non-root user for an interactive email session uses the directory /var/spool/clientmqueue as its queue directory and /etc/mail/submit.cf as its configuration file. Before the installation of sendmail 8.12, a new user and group both named smmsp by default must be created. The sendmail binary is installed as set-group-ID smmsp, and the /var/ spool/clientmqueue directory is owned by the owner and group smmsp, with its permissions set to be owner and group writable; it is inaccessible to everyone else.

When upgrading a computer with sendmail 8.11 or earlier to 8.12, the smmsp user name and group are created first. Then an 8.12-compatible /etc/mail/ sendmail.cf file is installed. The sh ./Build install process will do the other necessary tasks: install the binaries with the correct permission, install a submit.cf file, and create the clientmqueue directory with the proper permissions.

A non-set-user-ID sendmail installation is a very good thing. It strongly reduces the chances that a local security attack will involve the sendmail binary in the future. However, one should be aware of a couple of side effects. For example, non-root users can no longer use the mailq command to view the contents of /var/spool/mqueue. Sites should resist the temptation to "fix" this problem by allowing world read and execute permission on the queue directory itself. In addition, sendmail -bv, used to verify user names, may give misleading information as it may no longer be able to read .forward files in non-world readable directories.

Those sites that still wish to run sendmail set-user-ID root that is, using version 8.11 and earlier behavior may do so by running the Build script with the following argument: sh ./Build install-set-user-id.

2.5.2 The Message Store

Under Berkeley-derived UNIX systems, the default message store, /var/mail or /var/spool/mail, is owned and writable by root and readable and executable by everyone. Each person's mailbox will have the same name as its ownership; that is, the mailbox named npc will be owned by the user npc. It will be readable and writable by the owning user and unreadable and unwritable by everyone else.

On Berkeley-based systems, the LDA runs as root so it will always have permission to put email in a user's mailbox. It is typically called either mail or mail.local and is usually located in either /bin or /usr/libexec.

On some System V-based operating systems, the mail spool (typically /var/mail) will be owned by the user root and the group mail. This directory will be writable by both the owning user and the group, or the directory will be world writable but with the "sticky" bit set (mode 01777). When the sticky bit is set on a directory, anyone may create any file in that directory, but users may remove or rename only files that they themselves own. Using the sticky bit is not a good way to control file permissions in the message store, however. It means that when a new account is created on that server, the account creation process should create a stub mailbox in /var/mail for that user. If not, because the directory is world writable, some malicious user could come along and create a file using someone else's user name. If the LDA doesn't check the ownership of the file before delivering messages, the wrong person could read someone else's email. If it does check the file ownership, which it should, it will prevent that user from receiving any email. While this antisocial behavior shouldn't be tolerated for very long, it would be better if this possibility didn't exist.

In the spool, each mailbox is owned by its user, just as it is on a Berkeley-based system, except that the group of the file will be mail and the mailbox will be writable by both the owning user and the group. The LDA will run with its GID as group mail, which will allow it to deliver messages to any mailbox. Today the System V message store flavors seem to be falling out of favor, with Berkeley-style message stores predominating in the UNIX world.

2.5.3 Modifying Permissions in the Spool

Other programs built for a particular operating system, including email readers such as mutt or mush, automatically adapt themselves to the expected behavior of a particular operating system during compilation. Obviously, other vendor-supplied programs that access mailboxes, such as the Solaris mailtool or elm on HP-UX, also expect the files and directories to have certain permissions associated with them. If these sorts of programs will access users' mailbox files, permissions and ownership of files in the mail spool should not be modified in a manner inconsistent with these programs' expectations.

On many larger, centralized email servers, the only programs that access mailboxes might be the LDA, a POP daemon, and maybe an IMAP daemon. In such a case, the users with mailboxes on this machine need not log in to the mail server itself, so they won't have access to programs such as elm or mailx. In fact, they don't need valid login shells or home directories listed in the /etc/passwd files. In these cases it isn't as dangerous to modify permissions in the message store, as long as the LDA and POP and/or IMAP daemons remain compatible with the changes. The bottom line is that all programs that access the message store need to agree on its location, layout, permissions, ownerships, and locking mechanisms.

While most recent operating systems allow for billions of unique UIDs (user identifiers), some operating systems limit UIDs to a maximum value of 65,536; others limit this number range even more strictly. Many email servers exist that support a far greater number of users, but how? As long as the users don't have direct access to the server, it can suffice to use a single UID for all email-access-only accounts on the system. This strategy can simplify UID management considerably. Further, if every account that accesses email from the system does so using POP or IMAP, then all mailboxes could be owned by this single UID, which might be assigned to a suggestive-sounding account name such as mailadm. Then /var/mail could be owned and readable only by this account, the LDA would run as this account, and the POP daemon could change its EUID (effective UID, the UID under which it performs most of its operations) to that of the user in question. Note that on UNIX systems the POP server still needs to run as root when it binds to port 110. These changes are not required, but on a remote access-only email server with a very large number of active accounts, such a change may simplify operation.

More sweeping changes, such as bypassing the /etc/passwd file altogether, are also possible. Some of these ideas will be considered in Section 4.2.



sendmail Performance Tuning
sendmail Performance Tuning
ISBN: 0321115708
EAN: 2147483647
Year: 2005
Pages: 67

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net