Install sendmail (Part 1/2)

There are two approaches to installing a new sendmail:

  •  If you choose to run the new sendmail in place of the original, you first need to create and install a new configuration file. The m4(1) program is used to automate the process of configuration file creation.
  • If you choose to keep the original and install the new sendmail in parallel (until you can test it), you can proceed with the installation and defer configuration files until later. Note that this choice presumes you customized the file locations.

Beginning withV8.12, installation of sendmail became a bit more complex. You now have the choice of running sendmail as either a set-user-id root or a non-set-user-id root program. Our recommendation, beginning withV8.12, is to run sendmail as a non-set-user-id root. If you wishto install sendmail as a set-user-id root program, despite the potential security risks implied by such an approach, just issue this new special command:

# ./Build install-set-user-id

The preferred way to install sendmail, beginning withV8.12, is to first create three required system changes, and then to run ./Build install as usual:

  • Edit the /etc/passwd file (and possibly companion files suchas /etc/shadow and /etc/master.passwd, or possibly network services suchas Network Information Services [NIS]) to add the user smmsp. The name smmsp can be changed from its default withth e confMSPQOWN build macro.
  • Edit /etc/group file (or possibly network services suchas NIS) to add the new group smmsp. The name smmsp can be changed from its default with the confGBINGRP build macro.
  • Edit the /etc/rc.local file (or a different file depending on your version of Unix, such as /etc/init.d/sendmail or /etc/rc.conf) to change the way sendmail is started and stopped at boot time.

In a non-set-user-id root world, sendmail runs under two guises. In one guise, it is run by root to function as a listening daemon. This listening daemon is just like the listening daemon of earlier versions, except that, instead of running as root no matter who ran it, it now runs as root only if root runs it.

In its second guise, sendmail runs as an ordinary user to collect locally submitted messages. In this mode of operation, sendmail is set-group-id to a special group, so it runs in that group no matter who runs it. That group owns and has write permission to a separate queue into which locally submitted deferred messages are placed.

For this division of labor to work, the two guises need to use different configuration files.  The configuration file used by the locally submitted message sendmail is called submit.cf. Which configuration is used depends on how sendmail is run.

If sendmail is run withth e -bm command-line switch, the -bs command-line switch, or the -t command-line switch, it first tries to open and read submit.cf. If that file does not exist, sendmail falls back to reading its standard configuration file. The -bm command-line switch (sendmail’s default mode) causes sendmail to run as a mail sender, once in the foreground, gathering a list of recipients from the command line and reading the message from its standard input. The -bs command-line switchcauses sendmail to run a single MTP session in the foreground over its standard input and output, and then to exit.

The -t command-line switchcauses sendmail to gather its list of recipients from its standard input rather than from the command line. In addition to determining the use of submit.cf based on sendmail’s mode of operation, sendmail can also be coerced into using or not using submit.cf based on a new command-line switch. The -A command-line switch takes one of two possible arguments. If it is followed by an m character, sendmail uses the sendmail.cf file. If the -A is
followed by a c character, sendmail uses the submit.cf file:

/usr/sbin/sendmail -Am ← use sendmail.cf
/usr/sbin/sendmail -Ac ← use submit.cf