Considerations for sendmail daemons

Mail must be configured so that it can be exchanged only among equivalent security labels. Essentially, multiple independent mail networks must be set up. Mail support does not need to be configured for every security label supported on a multilevel secure system. On z/OS® systems, users must not be configured for sendmail when they log on with the SYSMULTI security label.

The most straightforward way to accomplish multiple independent mail networks is to define a different domain for each security label supported. Single-level security systems have their host name and IP address defined in the domain intended for their security label. Multilevel secure systems can have the same host name defined in each domain name intended for one of the security labels they support. An appropriate IP address on a restricted stack, or a VIPA on an unrestricted stack, is used in each domain for the multilevel secure system. When users log on to a multilevel secure system, their mail address becomes their user ID at that host name within the security label-specific domain. They use only the sendmail daemon on their system that supports that domain. When a user directs mail to a user ID at another multilevel secure host name, by default it is sent to the sendmail daemon on that host that is supporting the same security label-specific domain.

On a multilevel secure system in a single domain environment, each security label with mail support has a different host name. When users log on, their mail address becomes their user ID at the security label-specific host name in the common domain. They use only the sendmail daemon on their system that supports that host name. Users must know which host names are located in network security zones with equivalent security labels.

Of course, a user can address mail to another user at any host and domain name. However, their sendmail daemon will be able to connect only to other mail servers at IP addresses in network security zones with an equivalent security label. Mail sent to hosts that are in security zones with security labels that are not equivalent will time out. Mail received by the z/OS sendmail daemon, addressed to a local user ID that is defined but is not permitted to the security label of the sendmail daemon, is returned with the unknown user error message.

The sendmail daemon receives mail files from TCP clients or other mail servers. It forwards these mail files to other mail servers, queues mail for later transmission to other mail servers, or passes mail to tsmail (or another local delivery agent) to complete local delivery. In a multilevel secure environment, you must run a separate instance of the sendmail daemon for each security label. The sendmail daemon must not be run under the SYSMULTI security label. In some cases, the sendmail daemon queues mail for delivery. There are several different configuration options that allow the sendmail daemon to process the queue. Each mail queue must have a security label that matches the security label of the sendmail daemon.

Run each sendmail daemon under a different job name assigned to a user ID with the appropriate security label. In a multilevel secure environment, there are special configuration considerations and changes needed to support multiple sendmail daemons running under different security labels. These considerations and changes are as follows:

• You can run multiple sendmail daemons on the same unrestricted stack (using multiple network security zones), or you can run one sendmail daemon on each restricted stack.
• If CINET is active and multiple restricted stacks are used, each sendmail daemon can establish stack affinity through the _BPX_SETIBMOPT_TRANSPORT environment variable and bind to the IPv4 INADDR_ANY address, or to the IPv6 unspecified address (in6addr_any). Otherwise, you must define a VIPA in a network security zone with the appropriate security label for each sendmail daemon.

  CINET or INET	Restricted stack	Unrestricted stack
  CINET with single stack	VIPA is optional.	VIPA with same SECLABEL is required.
  CINET with multiple stacks	Use VIPA or stack affinity.	VIPA with same SECLABEL is required.
  INET	VIPA is optional.	VIPA with same SECLABEL is required.

• Sendmail clients are permitted to connect only to sendmail daemons with an equivalent security label. NETACCESS configuration permits sendmail daemons (mail transmission agents, or MTAs) to connect outbound only to other MTAs with an equivalent security label and accept inbound connections only from clients and other MTAs with an equivalent security label. Sendmail configuration should direct sendmail clients to attempt connections that will succeed.
• If the mail submission agent (MSA) or MTA is bound to a specific IP address, a shared sendmail.cf can be used if you are using the same host name in security label-specific domains. If you are using different host names, you must provide a separate sendmail.cf for each security label.
• Whenever a sendmail daemon (MTA) is bound to a specific IP address, the use of job-specific source IP addressing specifying the same IP address is suggested. This ensures that name resolution by peer MTAs results in the intended host name and domain name.