Install sendmail (Part 2/2)

Add smmsp to /etc/passwd

When sendmail is run as non-set-user-id root, it is run either as root when it is invoked by the root user, or as another user when it should not run as root. The sendmail distribution clearly cannot divine ahead of time what user you wish to use when not running sendmail as root. It could have chosen nobody, for example, but the user nobody does not exist under all versions of Unix.

You can choose your own username by using the confMSPQOWN build macro to place a line such as this into your build m4 file:

 define(`confMSPQOWN´, `nullmail´)

If you change the username, you will also have to build and install your own submit.cf file, and include in the mc file, for that creation, a definition for the new users with the RunAsUser option like this:

FEATURE(`msp´)
define(`confRUN_AS_USER´, `nullmail´)

If you don’t change the name, sendmail will use the name smmsp, which stands for SendMail Message Submission Program

Whether your keep the username chosen by the sendmail distribution, or choose a name of your own, you will need to add that name to your system’s passwd services. Here we show how to do this with the traditional Unix passwd file.

nullmail:*:32764:32764:Null Mail:/no/such/directory:/bin/false

In this example of a line from a traditional Unix passwd file, we have elected to create the user named nullmail. The line is divided into five fields by colons. The first ield is the name of the new user. The second field is the user’s password. But
because this user is not an actual person, we disable the password with an asterisk. On some systems you will need to put an x in this field, or the word NOPASSWORD. ee your system documentation for what to use in this field to disable a password for this new user.

The third and fourth fields are the user and group ID for the user. Here, we chose high numbers that are unlikely to conflict with actual user numbers. Some versions f Unix restrict the size of the numbers you can use. See your system’s  documentation. The fifth field is called the gecos field. It contains the full name of the users. We chose Null Mail, but you can choose any name you desire.

The last two fields are the home directory and shell for this user. The home directory should not exist, nor should it have the potential of ever existing. The shell hould be a program that will never successfully run. We chose /bin/false because
that program always exits with a nonzero (failure) value.

Add smmsp to /etc/group

When sendmail is run as non-set-user-id root, it is run either as root when it is invoked by the root user (in which case it can read all files), or as another user when t should not run as root. To enable the sendmail program to read and write its queue
when it is not root, it needs to always run as a predefined group. It does this by having its set-group-id permission set, and by running under an appropriate group. The sendmail distribution clearly cannot divine ahead of time what group you wish to use when not running sendmail as set-group-id. It could have chosen nogroup, for example, but the user nogroup does not exist under all versions of Unix.

You can choose your own group by using the confGBINGRP build macro to place a line suchas the following into your build m4 file. But don’t chose a group that is shared by any other user. For security reasons, the group you choose should be used only by sendmail:

define(`confGBINGRP´, `nullgroup´)

If you change the group, you will also have to build and install your own submit.cf file, and include in the mc file, for that creation, a definition for that new group with the RunAsUser option like this:

FEATURE(`msp')
define(`confRUN_AS_USER', `:nullgroup')

Note that the same option sets both the user and the group. A combined declaration might look like this:

 FEATURE(`msp')
define(`confRUN_AS_USER´, `nullmail:nullgroup´)

If you don’t change the group, sendmail will use the group smmsp.

Whether you keep the group name chosen by the sendmail distribution, or choose a name of your own, you will need to add that name to your system’s group services.

 nullgroup:*:32764:

In this example of a line from a traditional Unix group(5) file, we have elected to create the group named nullgroup. The line is divided into four fields by colons. The first field is the name of the new group. The second field is the group’s password. Because this group is not used by actual people, we disable the password with an asterisk. On some systems you will put an x in this field, or the word NOPASSWORD.  The third field contains the group number. That number should match the number used in the group field of the passwd(5) file. The last field contains the usernames of those that should also belong to this group. Generally, this will be an empty field.

Modify init Files

In a non-set-user-id root world, you run sendmail differently than the traditional manner to which you have become accustomed. There are two differences that you should attend to before installing the new non-set-user-id root setup. First, you need to decide how to drain the local message submission queue. Second, you need to decide on a name to differentiate the two roles with the syslog(8) facility

For local mail submission, sendmail will use a separate queue, one that is group read/write by the group discussed in the previous section. The sendmail program, in local message submission mode, sends a message and then exits. As a consequence, there is nothing running that can drain that separate queue of any messages that might be deferred there. The best way to drain it is with a queue processing daemon, such as this:

 /usr/sbin/sendmail -Ac -q30m

Here, the -Ac command-line switchtells sendmail to use the configuration file named submit.cf. This is the special message submission configuration file that knows about the second queue. The -q30m command-line switchcauses sendmail to wake up once each 30 minutes and process any deferred messages it finds in the second queue.

To differentiate one sendmail from another in the logs created by the syslog(8) facility, you can use the -L command-line switch. One suggestion looks like this:

/usr/sbin/sendmail -L mta-daemon -bd -q30m
/usr/sbin/sendmail -L msp-queue -Ac -q30m

The first line is the invocation of sendmail that is most common (with the -bd -q30m). The second line has been added to drain the second (mail submission) queue. The first will contain the identifier mta-daemon in its syslog(8) logfiles. The second will contain the identifier msp-queue. These identifiers are only suggestions, and you might prefer something more suitable to your site’s needs.

The sendmail program is usually started from a script in the etc directory. On System-V-based versions of Unix, that file is usually found in the /etc/init.d directory. On other versions of Unix, that file could live directly in the etc directory, and might be called rc or rc.local. Whichever file contains the commands to start sendmail on your system, look at it and determine how sendmail is currently started and stopped. You might, for example, find lines such as this, from a FreeBSD 4.0 sendmail startup file called rc:

case ${sendmail_enable} in
[Yy][Ee][Ss])
if [ -r /etc/mail/sendmail.cf ]; then
echo -n ' sendmail'; /usr/sbin/sendmail ${sendmail_flags}
fi
;;
esac

To modify this setup for use in a non-set-user-id root scheme, you would need to add the following line to your /etc/rc.conf file:

sendmail_flags="${sendmail_flags} -L mta-daemon"

Then create the file /etc/rc.local (if it does not already exist), and add the following lines to it:

case ${sendmail_enable} in
[Yy][Ee][Ss])
if [ -r /etc/mail/sendmail.cf ]; then
echo -n ' msp-queue'; /usr/sbin/sendmail -L msp-queue -q30m
fi
;;
esac

Take the time, now, to investigate how sendmail is started and stopped on your system. The new non-set-user-id root scheme will doubtless require special modifications on your part. Beginning withSolaris 7, for example, the pkill(8) command, as it is set up in /etc/init.d/sendmail, will not stop a sendmail that is running other than as root

 The submit.cf File

The submit.cf file is built for you automatically when you install sendmail. When you run make install, the following is one of the commands executed:

 cd ../../cf/cf && make install-submit-cf

This command will create and install a default /etc/mail/submit.cf file if that file does not already exist. For most sites, this default will be suitable for your use as is. If you customize at all, however, you will need to create your own submit.cf file. If, for example, you changed the user and group names for the non-set-user-id root version of sendmail with the following in your build m4 file:

define(`confMSPQOWN´, `nullmail´)
define(`confGBINGRP´, `nullgroup´)

you will need to create a custom submit.cf file. You create a custom submit.cf file just like you create a sendmail.cf file. You begin by creating a file called submit.mc. You can use the file cf/cf/submit.mc as a template for your own, or you can edit that file directly. If you edit that file directly, you will need to copy your changes to the same directory each time you upgrade sendmail to a new version.

Note that the name submit.cf is hardcoded and cannot be changed. When sendmail runs, unless you have built it to do otherwise, it will look for submit.cf in the same directory that it looks for its standard configuration file. If you change the location of the standard configuration file with the _PATH_SENDMAILCF build-time macro, you will also want to change the directory in which the submit.cf file is located. That directory is defined with the _DIR_SENDMAILCF
build-time macro.* For example, your build m4 file might look, in part, like this:

APPENDDEF(`confENVDEF´, `-D_PATH_SENDMAILCF=\"/opt/sendmail/sendmail.cf\"´)
APPENDDEF(`confENVDEF´, `-D_DIR_SENDMAILCF=\"/opt/sendmail/\"´)

Here, the first line changes the location of the sendmail.cf file. The second line is necessary so that sendmail will look for submit.cf in that same directory. Without this second line, sendmail would look for sendmail.cf in /opt/sendmail, but would look for submit.cf in the default location, /etc/mail.

Note that a Build install will always try to place the submit.cf file into a directory that begins with /etc/mail. But you can prefix this directory with another directory name, as shown here:

 # ./Build -E DESTDIR=/opt/sendmail install

This will cause the submit.cf file to be installed in the /opt/sendmail/etc/mail directory. If you have changed the location of your configuration files, as shown earlier, you will have to manually move the submit.cf file from its default installed location to your chosen location

Finally, note that by renaming or relocating the queue directory with the confMSP_QUEUE_DIR Build macro, the MSP_QUEUE_DIR mc macro must also be updated so that a correct submit.cf file will be created.