2.6 Install sendmail

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. See Chapter 4 for a full description of this process.

  • 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.

After you have compiled sendmail (and if the configuration file is ready and tested ), you can install it as your production version. If you are already running a sendmail and will be overwriting that binary, you will need to kill that version first (Section 1.7.1.2).

2.6.1 Pre-V8.12 Installation

For versions prior to V8.12, installing sendmail looks like this:

 #  ./Build -n install  

You use -n to be sure that the installation caused is, in fact, correct for your site. A typical such run, for example, might look like this:

 Configuration: pfx=, os=SunOS, rel=4.1.4, rbase=4, rroot=4.1, arch=sun4, sfx= Making in ../obj.SunOS.4.1.4.sun4/sendmail if [ ! -d /etc/mail ]; then mkdir -p /etc/mail; fi install -c -o bin -g bin -m 444 helpfile /etc/mail/helpfile if [ ! -d /etc/mail ]; then mkdir -p /etc/mail; fi install -c -o root -g bin -m 644 statistics /etc/mail/statistics install -c -o root -g bin -m 4555 sendmail /usr/lib for i in /usr/ucb/newaliases /usr/ucb/mailq /usr/ucb/hoststat /usr/ucb/purgestat; do \         rm -f $i; \         ln -s /usr/lib/sendmail $i; \ done install -c -o bin -g bin -m 444 sendmail.0 /usr/share/man/cat8/sendmail.8 install -c -o bin -g bin -m 444 aliases.0 /usr/share/man/cat5/aliases.5 install -c -o bin -g bin -m 444 mailq.0 /usr/share/man/cat1/mailq.1 install -c -o bin -g bin -m 444 newaliases.0 /usr/share/man/cat1/newaliases.1 

If all looks good, you can install sendmail with this command:

 #  ./Build install  

But be aware that the new sendmail might not work properly with your old configuration file. See Chapter 4 for guidance in creating a new configuration file.

Notice that Build will not create the queue directory even if it does not exist. If you have never run sendmail on your machine before, you will need to create that queue directory:

 #  mkdir /var/spool/mqueue  #  chmod 700 /var/spool/mqueue  

See Section 1.6.3 for a description of the QueueDirectory option and information about how sendmail locates its queue directory.

2.6.2 Installation with V8.12 and Above

Beginning with V8.12, installation of sendmail has become 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. The recommendation, beginning with V8.12, is to run sendmail as a non- set-user-id root . If you wish to 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 with V8.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 such as /etc/shadow and /etc/master.passwd , or possibly network services such as Network Information Services (NIS)) to add the user smmsp . The name smmsp can be changed from its default with the confMSPQOWN build macro (confMSPQOWN). The specifics of adding a new user will vary based on the version of Unix you are running.

  • Edit /etc/ group file (or possibly network services such as NIS) to add the new group smmsp . The name smmsp can be changed from its default with the confGBINGRP build macro (confGBIN...). The specifics of adding a new group will vary based on the version of Unix you are running.

  • 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 listening daemon is the traditional sendmail.cf file discussed throughout this book. [7] The configuration file used by the locally submitted message sendmail is called submit.cf . [8] Which configuration is used depends on how sendmail is run.

[7] The name sendmail.cf can be changed with the _PATH_SENDMAILCF build macro (_PATH...).

[8] The name submit.cf is hard-coded and cannot be changed.

If sendmail is run with the -bm command-line switch (-bm), the -bs command-line switch (-bs), or the -t (-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 switch causes sendmail to run a single SMTP session in the foreground over its standard input and output, and then to exit. The -t command-line switch causes 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  

In the following sections we first discuss the three system file modifications, then present a discussion of how to create and configure a submit.cf file.

2.6.2.1 Add smmsp to /etc/passwd

When sendmail is run as non- set-user-id root , it is either run 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 (confMSPQOWN) 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 (RunAsUser), like this:

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

If you don't change the name, sendmail will presume to use the name smmsp , which stands for S end M ail M essage S ubmission P rogram.

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 (5) services. Here we show how to do this with the traditional Unix passwd (5) file. Consider the lessons taught here, and apply them to your passwd (5) services in the manner most suitable to your Unix system:

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

In this example of a line from a traditional Unix passwd (5) file, we have elected to create the user named nullmail . The line is divided into five fields by colons. The first field 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. See 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 of 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 should be a program that will never successfully run. We chose /bin/false because that program always exits with a non-zero (failure) value.

2.6.2.2 Add smmsp to /etc/group

When sendmail is run as non- set-user-id root , it is either run as root when it is invoked by the root user (in which case it can read all files), or as another user when it 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 (confGBIN...) to place a line such as 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 chose 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 (Section 10.8.2.2), 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 presume to use the group smmsp , which stands for S end M ail M essage S ubmission P rogram.

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 (5) services. Here we show how to do this with the traditional Unix group (5) file. Consider the lessons taught here, and apply them to your group (5) services in the manner most suitable to your Unix system:

 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. See your system documentation to learn what is best to use in this field to disable a password for this new group.

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.

2.6.2.3 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 switch tells 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 switch causes sendmail to wake up once each 30 minutes and process any deferred messages it finds in the second queue. [9]

[9] If you prefer to avoid running two daemons, you can run the second invocation from cron , something like the following:

To differentiate one sendmail from another in the logs created by the syslog (8) facility, you can use the -L command-line switch (-L). 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) log files. 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 with Solaris 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 .

2.6.2.4 The submit.cf file

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

[10] Creating and installing submit.cf has been added as a convenience for you, to simplify the transition to this new non- set-user-id root model.

 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 (Section 4.2). 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 hard-coded 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 (_PATH...), 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. [11] For example, your build m4 file might look, in part, like this:

[11] Although it contains as part of its name SENDMAILCF, this macro is used only to define the directory for the submit.cf file.

 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. [12]

[12] If you need to make post-installation adjustments, we recommend you maintain your own Makefile outside the sendmail source distribution. That way you can always replicate those adjustments even though the source tree is updated with later releases of sendmail .

Table 2-4 shows how the Build process parallels the creation of the submit.cf file in certain limited ways.

Table 2-4. Considerations for the submit.cf file

m4 macro

m4 default

mc macro

Description

confMSPQOWN

smmsp

confRUN_AS_USER

User ID

confGBINGRP

smmsp

confRUN_AS_USER

Group ID

confMSP_QUEUE_DIR

/var/spool/clientmqueue

MSP_QUEUE_DIR

MSP queue

_DIR_SENDMAILCF

/etc/mail

none

cf file dir

Note again that _DIR_SENDMAILCF does not affect where Build install places the submit.cf file.

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

2.6.3 The /etc/mail Directory

One surprise you will encounter when installing V8.10 sendmail and above is that all support files now have a default location of /etc/mail . If that directory does not exist, Build will create it for you. If it exists but is not a directory, you might see an error like this:

 install -c -o bin -g bin -m 444 helpfile /etc/mail/helpfile install: /etc/mail/helpfile: Not a directory *** Error code 1 

If the file /etc/mail is serving no current purpose, consider removing it and rerunning Build . If that file is still important, take the time now to discover why and change its name. All future versions of sendmail will be grounded in the /etc/mail directory, so taking time now to free that name will be well spent.

2.6.4 Old Alias Files

On sites that are already running sendmail , the /etc/mail directory will likely not exist. If this is the case, your aliases (and possibly other database files) will exist in another directory (probably /etc ). The Build install process does not move those old files into the new /etc/mail directory.

After installing the new sendmail , test it by running newaliases . If you see the following error (or something similar), you probably have old files you need to move into the new directory:

 %  newaliases  newaliases: cannot open /etc/mail/aliases: No such file or directory 

You should also check for directory assumptions in your prior mc configuration file. You might have carried old locations into the new V8.10 or above configuration file, and moving files can cause errors to appear after the move.

2.6.5 Other Moved Files

Be aware that other files have also moved into /etc/mail , while still others have both been moved and renamed . Table 2-5 shows the old and new locations and names for the affected files.

Table 2-5. Files moved into /etc/mail

Old

Do what

New

/etc/aliases

move to

/etc/mail/aliases

/etc/bitdomain

move to

/etc/mail/bitdomain

/etc/domaintable

move to

/etc/mail/domaintable

/etc/genericstable

move to

/etc/mail/genericstable

/etc/mail/sendmail.cw

move to

/etc/mail/local-host-names

/etc/mail/sendmail.hf

remove, and use the new

/etc/mail/helpfile

/etc/mail/sendmail.st

remove, and use the new

/etc/mail/statistics

/etc/mailer/sendmail.st

remove, and use the new

/etc/mail/statistics

/etc/sendmail.ct

move to

/etc/mail/trusted-users

/etc/sendmail.cw

move to

/etc/mail/local-host-names

/etc/sendmail.hf

remove, and use the new

/etc/mail/helpfile

/etc/sendmail.oE

move to

/etc/mail/error-header

/etc/sendmail.st

remove, and use the new

/etc/mail/statistics

/etc/sendmail/aliases

move to

/etc/mail/aliases

/etc/sendmail/sendmail.cw

move to

/etc/mail/local-host-names

/etc/sendmail/sendmail.st

remove, and use the new

/etc/mail/statistics

/etc/service.switch

move to

/etc/mail/service.switch

/etc/ucbmail/aliases

move to

/etc/mail/aliases

/etc/ucbmail/sendmail.hf

remove, and use the new

/etc/mail/helpfile

/etc/ userdb

move to

/etc/mail/userdb

/etc/uudomain

move to

/etc/mail/uudomain

/etc/virtusertable

move to

/etc/mail/virtusertable

/share/misc/sendmail.hf

remove, and use the new

/etc/mail/helpfile

/usr/adm/sendmail/aliases

move to

/etc/mail/aliases

/usr/lib/aliases

move to

/etc/mail/aliases

/usr/lib/mail/aliases

move to

/etc/mail/aliases

/usr/lib/sendmail.hf

remove, and use the new

/etc/mail/helpfile

/usr/lib/sendmail.st

remove, and use the new

/etc/mail/statistics

/usr/share/lib/sendmail.hf

remove, and use the new

/etc/mail/helpfile

/usr/share/misc/sendmail.hf

remove, and use the new

/etc/mail/helpfile

/usr/ucblib/aliases

move to

/etc/mail/aliases

/usr/ucblib/sendmail.hf

remove, and use the new

/etc/mail/helpfile

/usr/ucblib/sendmail.st

remove, and use the new

/etc/mail/statistics

If any of these old names exist on your system, you should move them to the new /etc/mail directory, or remove them from service, as marked .

2.6.5.1 The MAIL_SETTINGS_DIR mc macro

The name of the default directory, /etc/mail , is stored in the MAIL_SETTINGS_DIR mc configuration macro. You can redefine this macro to relocate that default to a new directory, but if you do, be certain that the declaration ends in a slash character:

 define(`MAIL_SETTINGS_DIR', `/opt/sendmail/etc/')   must end in a slash  

Note that the MAIL_SETTINGS_DIR mc configuration macro must specify a full pathname, one that starts with a slash. If it does not specify a full pathname, unexpected problems might arise when you run sendmail .

2.6.6 The Wrong Symbolic Link

When upgrading from the vendor's version of sendmail to the open source version of sendmail , vendor assumptions about program locations might not agree with the new sendmail locations. One way to check for a mismatch is to look at the version of sendmail under each of its names. Consider, for example, a check to see if sendmail and the newaliases program are the same:

 %  newaliases -d0.1 < /dev/null  head -1  Version 8.9.2 %  /usr/lib/sendmail -d0.1 < /dev/null  head -1  Version 8.12.7 

Here we find that newaliases is not a symbolic link to sendmail as we expected. Finding the cause of this mismatch can take some investigation. Under BSDI 3.x, for example, the /usr/sbin/newaliases program is a hard link, not a symbolic link, so replacing sendmail will not affect it.



Sendmail
sendmail, 4th Edition
ISBN: 0596510292
EAN: 2147483647
Year: 2002
Pages: 1174

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