Steps for setting up and running sendmail in a multiple security label environment

You must configure mail so that it can be exchanged only among equivalent security labels, essentially setting up multiple independent mail networks.

Before you begin

Read and understand Steps for configuring z/OS UNIX sendmail. The objective of this topic is to guide you through the steps required to set up sendmail in a multilevel secure environment. The contents of this topic are based on the assumption that you understand your sendmail configuration and your network configuration.

Procedure

Perform the following steps to set up and run sendmail in a multiple security label environment:

Create host and domain names as follows:
1. Decide whether you are using security label-specific domain names or separate host names.
2. Define a VIPA in a network security zone with the appropriate security label for each sendmail server to which you will bind.
  Tip: This step is optional if stack affinity is used with restricted stacks.
3. Define the domains and host names in your DNS, or /etc/hosts and /etc/ipnodes files. For example, if your system supported the security labels SYSHIGH, SYSLOW, ORANGES and APPLES, the following definitions are some sample /etc/hosts definitions:
```
;  DIFFERENT HOST NAMES IN THE SAME DOMAIN
10.10.10.1		Z10HIGH.MYCORP.COM         
10.10.10.2		Z10LOW.MYCORP.COM
10.10.10.3		Z10ORNGE.MYCORP.COM
10.10.10.4		Z10APPLE.MYCORP.COM
;  SAME HOST NAMES IN DIFFERENT DOMAINS 
192.168.10.41	ZOS10.SYSHIGH.MYCORP.COM 
192.168.10.42	ZOS10.SYSLOW.MYCORP.COM   
192.169.10.43	Z0S10.ORANGE.MYCORP.COM
192.168.10.44	ZOS10.APPLES.MYCORP.COM
```
4. Set up stack affinity and resolver configuration, as described in Planning for interactive UNIX System Services users in a multilevel secure environment.
5. If the sendmail servers are started by using started procedures, take one of the following actions:
  - Add a STDENV DD line to the JCL, specifying a file that sets the environment variable RESOLVER_CONFIG to the appropriate file based on the security label for this sendmail server. For example:
```
//STDENV DD PATH='/etc/seclbl/sendmail.env',  
//       PATHOPTS=(ORDONLY)
```
  - Set the RESOLVER_CONFIG environment variable to the appropriate file (based on the security label of the sendmail server) using ENVAR on the PARM keyword of the EXEC statement. For example:
```
//SENDMAIL EXEC PGM=BPXBATCH,REGION=4096K,TIME=NOLIMIT,    
// PARM=('PGM /usr/sbin/sendmail -bd -q1h -L sndmail1', 
//      'ENVAR("RESOLVER_CONFIG=/etc/resolv.conf")'
```
Create security label-specific mail queue directories as follows:
1. If necessary, create the parent SYSMULTI directories. To create these directories, you must log on as a superuser with the SYSMULTI security label and issue the following UNIX System Services commands:
```
mkdir /var 
mkdir /var/spool
```
2. Create new mail queue directories for each security label to be supported for sendmail. For each security label to be supported for servers, repeat the following steps:
  1. Log on to a TSO user ID with that security label.
  2. Issue the following UNIX System Services commands, replacing seclbl with the security label name and sndmuser with the appropriate sendmail user ID:
```
mkdir /var/spool/seclbl 
mkdir /var/spool/seclbl/mqueue 
chown sndmuser:sndmgrp /var/spool/seclbl/mqueue 
mkdir /var/spool/seclbl/clientmqueue 
chown smmsp:smmspgrp /var/spool/seclbl/clientmqueue
```
    Tip: Do not create /var/spool/seclbl or its subdirectories for SYSMULTI or any other security label that is not to be supported for sendmail. There will not be a server to use them.
  3. Create a symbolic link for these mail directories. The following UNIX System Services command issued by a superuser creates the symbolic link and directs the mail to the appropriate queue:
```
ln -s '$SYSSECR/'  /var/spool/secsymr
```
Change statements in the sendmail.mc configuration file as follows:
1. Change the location of the daemon pid file so that there is a separate one for each security label:
```
define(`confPID_FILE', `/var/spool/secsymr/sendmail.pid')dnl
```
2. Change the location of the local host names file so that there is a separate one for each security label:
```
define(`confCW_FILE', `/etc/secsymr/local-host-names')dnl
```
3. Change the location of the queue directories:
```
define(`MSP_QUEUE_DIR', `/var/spool/secsymr/clientmqueue')dnl  
define(`QUEUE_DIR', `/var/spool/secsymr/mqueue')dnl
```
4. Define configuration file variables for the local host name and domain name:
```
define(`MLS_hostname', esyscmd(`hostname -s'))dnl 
define(`MLS_domain', esyscmd(`domainname'))dnl
```
5. Change the DAEMON_OPTIONS statements. Code the ADDR parameter, specifying the unqualified local host name. For each sendmail daemon you start, this name will be resolved within the domain specific to the security label that daemon is running under. For example:
```
FEATURE(`no_default_msa')dnl   
DAEMON_OPTIONS(`Name=MTA, Addr='MLS_hostname`, Family=inet ')dnl   
DAEMON_OPTIONS(`Name=MSA, Port=587,  Addr='MLS_hostname`, Family=inet ')dnl
```
Change statements in the submit.mc configuration file as follows:
1. Change the location of the client queue directory:
```
define(`MSP_QUEUE_DIR', `/var/spool/secsymr/clientmqueue')dnl
```
2. Define configuration file variables for the local host name and domain name:
```
define(`MLS_hostname', esyscmd(`hostname -s'))dnl 
define(`MLS_domain', esyscmd(`domainname'))dnl
```
3. Change the FEATURE(`msp') statement. Code the unqualified local host name for this system. For each user that invokes /bin/sendmail, this name will be resolved within the domain specific to the security label that user is running under. For example:
```
FEATURE(`msp', MLS_hostname)
```
  Tip: If MX records in DNS should not be searched, brackets [] must be placed around the name or address.

Use the m4 compiler to create sendmail.cf and submit.cf files as follows:

Create symbolic links for the submit.cf and sendmail.cf files:

ln  -s  /etc/seclbl/mail/submit.cf  /etc/mail/submit.cf  
ln  -s  /etc/seclbl/mail/sendmail.cf  /etc/mail/sendmail.cf

Log on with each security label to be supported for mail and create the .cf files:

/etc/m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf 
/etc/m4 /etc/mail/submit.mc > /etc/mail/submit.cf

Create new system mailbox directories for each supported security label. When sendmail is configured to use /usr/lib/tsmail, you must configure /usr/mail to be a symbolic link to a security label-specific directory. The following approach creates a set of security label-specific mount points for mail file systems:
1. Log on as a superuser with the SYSMULTI security label and issue the following UNIX System Services commands:
```
mkdir  /mailmnt  
ln  -s  '$SYSSECR/mail'  /usr/mail
```
  Tip: If another program other than /usr/lib/tsmail is used, these commands might need to be adjusted accordingly.
2. Perform the following steps for each security label supported for mail on the system:
  1. Log on to a superuser ID using the security label.
  2. Set an environment variable to your current security label as follows:
```
export SL=$(id -M)
```
  3. Issue the following UNIX System Services command:
```
mkdir /mailmnt/$SL
```
Start a separate instance of the sendmail daemon for each security label you need to support. For instructions on setting up the appropriate user IDs and groups for sendmail, see Steps for configuring z/OS UNIX sendmail. You can start sendmail daemons either from UNIX System Services or as started procedures. See the EZARACFM sample for examples of defining user IDs and STARTED class profiles for sendmail. Repeat either of the following steps to start a sendmail daemon for each supported security label:
- From UNIX System Services:
  1. Log on to UNIX System Services with the security label that you want to support.
  2. Start the sendmail daemon from the command line.
- From the MVS™ console:
  1. Add a user ID and permit the user ID to the appropriate security label.
  2. Use the STARTED class to assign the user ID with the appropriate security label to the procedure.
  3. Start the procedure from the MVS console or using the AUTOLOG statement in PROFILE.TCPIP.