11 Mail System

The Digital UNIX mail system enables users to send mail to other users, whether on the same system, same network, or the other side of the world. This chapter describes the Digital UNIX mail system and its components, guidelines for configuring and administering mail on a standalone system or across an enterprise, mail configuration planning, mail configuration, and day-to-day management tasks.

For additional introductory information on mail, see also mail_intro(7) and the sendmail book by O'Reilly & Associates.

11.1 The Mail Environment

In the Digital UNIX mail environment, systems can have the following roles:

Standalone -- A mail standalone system is one that processes, sends, and delivers mail locally. This is useful for configurations of from 1 to 6 systems. In small LAN configurations of two or more systems, one system serves the mailbox to the other systems using NFS. In this case, NFS must be configured on all systems.
Client -- A mail client system is a system that sends all mail to a mail server for processing and delivery. If the addressee is on the client system, the mail is delivered there. If not, the mail is forwarded to the destination system.
Server -- A mail server system is a system that receives mail from clients in a local domain for processing and delivery to other domains, the Internet, or other networks. In addition, the server also receives mail from other domains for delivery.

Figure 11-1 shows a sample standalone configuration on a LAN in which all hosts are configured as mail standalone systems. Host B is also an NFS server, exporting the /var/spool/mail directory to hosts A, C, D, and E. Hosts A, C, D, and E are also NFS clients, importing the /var/spool/mail directory from host B.

The hosts must also have identical information in their passwd and aliases files. This information can be distributed either by using NIS or by manually editing the files on each system.

Figure 11-1: Sample Mail Standalone Configuration

Figure 11-2 shows a sample client/server configuration in which host B is configured as a mail server and hosts A, C, D, and E are configured as mail clients. This is useful in larger enterprise networks that consist of multiple domains and connections to the Internet or other networks.

This configuration also provides for the creation of a natural hierarachy of mail servers in large enterprise networks with multiple domains. Mail clients in each domain would direct all traffic to one or more mail servers, depending on the number of clients in the domain. Each domain's servers would then forward mail to the enterprise's top domain servers for forwarding to the Internet. Since almost all of your local domain's mail traffic goes through the servers, this simplifies administration and problem resolution in that you only have to manage the servers.

The connection to the Internet in Figure 11-2 could be direct or through a local access provider. Business configurations would typically use firewalls and dedicated mail servers. If using a firewall, ensure the firewall and the mail server are configured to work with each other. See the documentation for your firewall product or consult with Digital Firewall Services for more information.

Figure 11-2: Sample Mail Client/Server Configuration

If users need to send mail between systems that use different mail protocols, such as DECnet, SMTP, and UUCP, you should designate specific server systems in your network to perform that function. These server systems are also known as mail relays.

Additional mail configurations are possible, but they require more effort to plan for and to configure. See the sendmail book by O'Reilly and Associates for more information.

In implementing a client/server mail environment, you need to decide the following:

How to direct outgoing mail to the servers
How to handle incoming mail to the domain
How to deliver mail to clients
How to handle DECnet mail

This section describes each of these topics.

11.1.1 Directing Outgoing Mail to Servers

To direct outgoing mail to a server, you include the BIND mail exchanger (MX) entry in the /etc/namedb/hosts.db file. This entry specifies a system in the local domain that can deliver mail to systems not directly connected to the local network. Using MX to route mail has the following benefits:

You can define an MX record to point to all of the mail servers in your local domain. If a mail server is inaccessible, mail can be delivered to another host listed in the MX record.
You can use MX records to define a system to be a mail exchanger for an inaccessible remote system. Then, if you send mail to the remote, inaccessible host, instead of being queued on your local system and periodically resent, the mail is sent to the mail exchanger and queued there until the host is restored.

For information on adding entries to the /etc/namedb/hosts.db file, see Section 6.5 and bind_manual_setup(7).

11.1.2 Handling Incoming Mail to the Domain

To simplify the handling of incoming mail to a domain and to ensure reliability, you should use domain-based addresses in your environment. Typically, mail sent over the Internet is usually addressed in the following format:

username@hostname.domain

For example: joe@host1.nyc.big.com

Using domain-based addresses, this address appears as follows:

joe@.nyc.big.com

Mail is sent to the local domain nyc.big.com instead of to the specific host within that domain host1.nyc.big.com; the return address is also @nyc.big.com. Then, the mail servers within the local domain decide how to deliver the mail to the user's account.

Domain-based addresses make it easier to manage your mail environment. You can change your mail system (that is, move user accounts and replace or move systems) without disrupting your mail delivery. These changes are transparent to users sending mail to your systems.

11.1.3 Delivering Mail to Clients

Once mail is delivered to the domain, you can deliver it to clients using either of the following mechanisms:

Deliver the mail to the /var/spool/mail directory on each client.
Deliver the mail to the server and use NFS to serve the mail directory to each client.

In order to deliver mail to each of the clients, each server in the domain must have an aliases file that contains entries for each user on the client. For example:

username1: username1@client1
username2: username2@client1

See Section 11.1.4 for information on distributing the aliases file.

11.1.4 Distributing the aliases File

For standalone and server systems, Digital recommends that you use the Network Information System (NIS) to distribute the mail aliases file from one machine. In LAN environment with standalone systems, distribute the mail aliases file from the system that is also the NFS server. In a client/server environment, distribute the aliases file to the servers in the domain. In either case, sharing the aliases file among systems simplifies administration in that you only need to update one aliases file, instead of several.

For client systems, do not distribute the aliases file and, if using NIS, do not put a yp entry for the aliases database in the svc.conf file.

11.1.5 Distributing the passwd File

If you are using multiple server systems in a domain, make sure that the passwd information is identical on each system. For security reasons and to ensure correct mail delivery, you should do this by manually editing the passwd file on each server system.

11.1.6 Handling DECnet Mail

When you set up your Digital UNIX mail server system, you must consider that the mail address formats for DECnet Phase IV and DECnet/OSI are different from those for TCP/IP. Therefore, you need to establish a mapping scheme to translate mail addresses when sending mail between a DECnet node and a TCP/IP node.

The mapping scheme used by the Digital UNIX version of the sendmail program for DECnet Phase IV is to encapsulate DECnet addresses inside a pseudodomain. For example, a typical DECnet Phase IV address has the following format:

nodename::username

Mail addressed in this format is mapped to an address in the following format:

username@nodename.pseudodomain.top.domain

The variables represent the following:

username: The user name.

nodename: The DECnet node name.

pseudodomain: An arbitrary string that specifies the DECnet pseudodomain. The pseudodomain can be an arbitrary string, but it must be used consistently throughout your organization. All of your mail systems must be configured to use the same string for the pseudodomain.

top.domain: Usually, your company's domain name; for example, abc.com.

The mapping for DECnet/OSI uses a similar scheme. A typical DECnet/OSI address has the following format:

username@namespace:.site.nodename

Mail addressed in this format is mapped as follows:

username@nodename.site.namespace.pseudodomain.top.domain

As with DECnet Phase IV, the pseudodomain can be an arbitrary string. However, if you use both DECnet Phase IV and DECnet/OSI within your organization the pseudodomain names should be different.

Some environments that support both DECnet Phase IV and DECnet/OSI use the DECnet Phase IV syntax for handling DECnet-based mail. This simplifies the mail administration task. In order to implement this, all DECnet-OSI nodes must have a unique Phase IV Synonym and must be configured to use the Phase IV Synonym. You can reconfigure a DECnet/OSI host by typing the following command line:

# ncl set session control application mail11 Node Synonym=true

See the DECnet/OSI documentation for more information.

11.2 Mail System Planning

This section describes those tasks you need to do before configuring mail.

11.2.1 Verifying that Required Protocols are Installed

Depending on the protocols supported by your mail server, verify that the following required subsets are installed and configured:

DECnet
DECnet/OSI
X.25 (PSInet)
UUCP

See the documentation for each product for installation and configuration instructions. For UUCP, verify that the UUCP subset is installed by entering the following command:

# setld -i | grep OSFUUCP

If it is not installed, install it by using the setld command. For more information on installing subsets, see setld(8), the Installation Guide, or the System Administration manual.

11.2.2 Verifying that Required Services are Configured

The following table lists specific mail configuration and the network service required:

If you want to: Configure this service:

Distribute the aliases file NIS

Use domain-based addressing BIND

11.2.3 Preparing for the Configuration

After you install and configure the required protocols and services, you configure mail using Mail Configuration application. Appendix A contains a worksheet that you can use to record the information that you need to complete the tasks in this book. If you are viewing this manual online, you can use the print feature to print a copy of this part of the worksheet.

Mail configuration consists of the following parts:

Defining the standalone, client, or server system
Defining the protocol information (server systems only)

11.2.3.1 General System Information

Figure 11-3 shows Part 10A of the Configuration Worksheet. The following sections explain the information you need to record in Part 10A of the worksheet.

Figure 11-3: Configuration Worksheet, Part 10A

server (clients only): The fully qualified name of your mail server; for example, foo.dec.com is a fully qualified name.

Top domain (servers only): The name of the highest level domain in your organization that uniquely identifies your organization. For example, if the server domain name is nyc.big.com, the top domain is big.com. If the server domain name is cs.big.univ.ac.uk, the top domain is big.univ.ac.uk.

Mailbox directory

The location of the mailbox directory.

For standalone and client syatems, if it is on the local system, check LOCAL. If it is on a remote system and to be mounted on the local system using NFS, check CLIENT. If the local system is to export mail boxes to NFS clients, check SERVER.

For server systems, Digital recommends that you check SERVER to make the mailbox directories available to other systems. If you do not want to share the mailbox directories, check LOCAL. In this case, use the aliases command to send each user's mail to the appropriate system. See Section 11.7 and aliases(4) for more information.

Locking

The type of file locking to use on the mailbox.

For standalone and client systems, if the host with the mailbox directory is a Digital UNIX system, check LOCKF; this provides the best performance. If you are not sure what operating system the host with the mailbox directory is running, check LOCK FILE. If you want to use both, check BOTH.

Note
The locking mechanism you select must match the mechanism used by the NFS server. If you are not sure how the locking mechanisms are set on the NFS server, ask the administrator of the NFS server.

For server systems, if you checked LOCAL as the mailbox location, check LOCKF. If you checked CLIENT as the mailbox location, check LOCK FILE. If you checked SERVER as the mailbox location, check BOTH.

Mailbox server: The name of the system that exports the mailbox to your local system.

11.2.3.2 Protocol Information

Figure 11-4 shows Part 10B of the Configuration Worksheet. The following sections explain the information you need to record in Part 10A of the worksheet.

Figure 11-4: Configuration Worksheet, Part 10B

Protocol

For systems functioning as mail gateways, the type of mail protocol to support. Available protocols include the following:

DECnet
DECnet/OSI
Internet Mail Protocol (SMTP) (required)
Message Transport System (MTS)
UUCP
X.25 (PSInet)

Forward: For SMTP only, the type mail that has to be forwarded to a relay. If the local host has direct access to the Internet and does not forward any mail, check NONE. If the local host must forward all mail addressed outside of the top domain, check INTERNET. If the local host must forward all messages addressed outside of the local Internet domain, check NONLOCAL. If the local host must forward all mail, including local domain mail, check LOCAL.

Routing: For DECnet, DECnet/OSI, UUCP, MTS, and X.25 only. If mail for the particular protocol is to be forwarded over the Internet to an unspecified gateway, check INTERNET. The Internet depends on BIND/DNS to select an appropriate relay; therefore, do not specify a relay hostname for the Internet.
If the particular protocol is installed on this server, check DIRECT. If mail requiring the particular protocol is to be forwarded to another system for processing, check RELAY. Complete the Relay's Hostname and Relay's Protocol fields.

Relay's host name: The name of the host that will process mail for the protocol.

Relay's protocol: The name of the protocol the relay host uses to forward messages to the gateway.

Node address: The DECnet address for this machine (DECnet only).

DNS name space: The complete DNS name space name for this node (DECnet/OSI only). The syntax of the DNS name space is as follows:
namespace:.site.nodename

Pseudo domain: An arbitrary string that specifies the pseudo domain (DECnet, DECnet/OSI, and MTS only). The pseudo domain name must be unique for each protocol and must be used consistently throughout your enterprise.

Pseudo domain aliases: Any synonyms for your pseudo domain (DECnet, DECnet/OSI, UUCP, and MTS only).

Host aliases: The alternative names that other systems might use to direct mail to your host.

11.3 Configuring Mail

Digital recommends that you use the Mail Configuration application of the Common Desktop Environment (CDE) Application Manager for configuring mail on systems with graphics capabilities. You can configure the following systems:

Standalone systems
Client systems
Server systems

To start up the Mail Configuration application, do the following:

Log in as root.
Click on the Application Manager icon on the CDE desktop.
Double-click on the System_Admin application group icon.
Double-click on the Digital System_Management_Utilities application group icon.
Double-click on the Configuration application group icon.
Double-click on the Mail Configuration application icon in the Configuration group. The Mail Configuration main window appears, showing available Mail service types and configured Mail service types.

To exit the Mail Configuration application, choose File then Exit. See mailconfig8X for more information.

Note
For systems without graphics capabilities, you can use the mailsetup utility. See mailsetup(8) for more information.

The Mail Configuration application also has an extensive online help system. You can use it instead of the instructions in this section to configure mail on your system.

11.3.1 Configuring a Standalone Mail System

To configure mail for a standalone system, do the following:

From the Mail Configuration window, select Standalone in the Available Mail Service Types list box.
Click on Configure. The Standalone Setup dialog box appears.
If your system will not use NFS to import or export the mailbox file (/var/spool/mail), go to step 8; the default settings are applicable for your mail configuration.
Otherwise, click on Mailbox Setup. The Mailbox Setup dialog box appears.
If your system imports its mailbox using NFS, click on Client for Mailbox Directory. If your system distributes its mailbox to NFS clients, click on Server.
If you clicked on Client for Mailbox Directory, do the following:
1. Click on the Mailbox Server field and enter the server name.
2. Click on one of the following Locking mechanisms: lockf, Lock Files, or Both.
If you clicked on Server for Mailbox Directory, do the following:
1. Click on Both as the Locking Mechanism setting.
Click on Ok to complete the mailbox setup and close the Mailbox Setup dialog box.
Click on Commit to save the changes.
Click on Restart in the confirmation dialog box to restart the sendmail daemon and enable the changes.
Click on Close to close the Standalone Setup dialog box.

11.3.2 Configuring a Mail Client

To configure a mail client, do the following:

From the Mail Configuration window, select Client in the Available Mail Service Types list box.
Click on Configure. The Client Setup dialog box appears.
Click in the Mail Server input text box and enter the name of the mail server.
Click on Mailbox Setup. The Mailbox Setup dialog box appears.
Click on NFS Client for the Mailbox Directory.
If your site does not use NFS to share system mailbox directories, click on Local instead of NFS Client, and then go to step 7.
Click in the Mailbox Server input text and enter the name of the mailbox server.
Click on one of the following Locking mechanisms: lockf, Lock Files, or Both.
Click on Ok to complete the mailbox setup and close the Mailbox Setup dialog box.
Click on Commit to save the changes.
Click on Restart in the confirmation dialog box to restart the sendmail daemon and enable the changes.
Click on Close to close the Client Setup dialog box.

11.3.3 Configuring a Mail Server

Mail servers are part of a network and process mail for clients. To configure a mail server, do the following:

From the Mail Configuration window, select Server in the Available Mail Service Types list box.
Click on Configure. The Server Setup dialog box appears.
Select the mail protocol you want to configure for use on this system from the Available Protocols list box. You must configure the Internet Mail Protocol (SMTP) protocol; it is the only required protocol configuration. Configure additional protocols as necessary.
Click on Configure. The protocol setup dialog box for the protocol you selected appears.
For the SMTP protocol, do the following:
1. Click on the type of forwarding for this server. If you click on None, go to step 10; otherwise, go to step 7.
For the DECnet, DECnet/OSI, MTS, UUCP, and X.25 protocols, do the following:
1. Click on a Routing type. If you click on Internet or Direct, go to step 9.
  If you click on Relay, go to step 7.
If you are forwarding mail to another system for processing, click in the Relay's Hostname input text field and enter the system name of the host that will process mail requiring this protocol; otherwise, continue with step 9.
If you are forwarding mail to another system for processing, click on the Relay's Protocol option menu and select the protocol used to communicate with the Relay.
For the DECnet, DECnet/OSI, and MTS protocols, in the Pseudo Domain text input field, enter the domain name used to identify mail that requires the selected protocol.
For the DECnet, DECnet/OSI, MTS, UUCP, and X.25 protocols, to add aliases for the pseudo domain, click on Pseudo Domain Aliases and do the following:
1. Enter the alias name in the Pseudo Domain Alias text input field, and click on Add.
2. Repeat the previous step as many times as necessary.
3. Click on Commit to close the Pseudo Domain Aliases dialog box.
To add aliases for this mail server, click on Host Aliases and do the following:
1. Enter the alias name in the Host Alias text input field, and click on Add.
2. Repeat the previous step as many times as necessary.
3. Click on Commit to close the Host Aliases dialog box.
For the DECnet protocol, click in the Node Address field and enter the DECnet node address (area.node) for this server, for example, 32.958.
For the DECnet/OSI protocol, click in the DNS Name Space field and enter the name space of the node, which is usually the token before the colon (:) in a DECnet Phase V address.
Click on Ok to close the Setup dialog box for the protocol you selected. The Server Setup dialog box is active.
Configure another protocol if necessary. Repeat steps 3 through 15 for each additional protocol.
Click on Mailbox Setup. The Mailbox Setup dialog box appears.
Click on a Mailbox Directory.
If your site does not use NFS to distribute the system mailbox directories, click on Local instead of NFS Server, and then go to step 19.
If you selected NFS Client as a Mailbox Directory, enter the name of the mail server in the Mail Server input text box. Be sure to include the domain. For example, for a server named mailhub, the server name with domain might be mailhub.nyc.dec.com.
Click on one of the following Locking mechanisms: lockf, Lock Files, or Both.
Click on Ok to complete the mailbox setup and close the Mailbox Setup dialog box.
Click on Commit to save the changes.
Click on Restart in the confirmation dialog box to restart the sendmail daemon and enable the changes.
Click on Close to close the Server Setup dialog box.

11.4 Mail Utilities

Digital UNIX operating system includes the following mail utilities:

The mail, binmail utility (the default) -- Used by the sendmail utility to deliver mail locally. Because the mail utility has root setuid permission, it handles delivery of all mail to a user's local mailbox located in the /var/spool/mail directory. See the Command and Shell User's Guide and mail(1).
The mailx, Mail utility -- A combination of the Berkeley Software Distribution's (BSD) and UNIX System Laboratories, Inc.'s System V Release 4 (SVIDI) mail utilities. The mailx utility depends on the binmail utility for delivery to a user's mailbox. It has more user features than the binmail utility. See the Command and Shell User's Guide and mail(1).
The Dtmail utility -- The default mail program in the Common Desktop Environment. This utility uses sendmail as the transport and stores information in much the same way as mailx. In addition, it offers MIME support. See the Common Desktop Environment: User's Guide and dtmail(1).
The message handler utility mh -- It and its associated commands are included in the optional RAND Corporation Mail Handler subset. The message handler is composed of several shell commands where each command handles a specific function. For example, the inc command reads new mail and the comp command creates a message. Like the mailx utility, the mh utility depends on the mail utility for delivery to a user's mailbox. This utility provides a graphical interface with graphical interface with the dxmail and xmh commands, and the Post Office Protocol (POP). See the DECwindows User's Guide and dxmail(1) for more information on dxmail. See xmh1X for more information on xmh. See mail_manual_setup(7) for more information on POP.

For more information on sendmail, see sendmail(8), sendmail.cf(4), and sendmail.m4(8).

11.5 Monitoring the Mail Queue

Monitoring the mail queue enables you to determine the status of several types of networking operations, including jobs that have been queued on a local system for transfer to a remote system. General users and system administrators can monitor the mail queue.

To display the contents of the mail queue, use the mailq command. This command lists the number of requests and the queue ID, the message size, the date the message entered the queue, and the sender and recipient for each request. Alternatively, you can also use the sendmail -bp command.

See mailq(1) for more information.

If a major host is off line for a period of time, the number of entries in the queue might be quite large, causing the performance of the mail environment to suffer. To remedy this, you will have to archive the queue. See Section 11.6 for information.

The following example shows two requests in the mail queue:

# mailq

                Mail Queue (2 requests)
--QID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------
AA04956     1442 Tue Aug 24 10:12 <blaise>
                 (Deferred)
                                 <corcoran@host1.corp.com>
AA08618* (no control file)

11.6 Archiving the Mail Queue

When a major host is off line for a number of days, the mail queue might grow to be quite large. As a result, sendmail spends a lot of time sorting the large queue, severely affecting the mail environment performance. Archiving the mail queue enables your mail environment to function normally while the major host is off line. To archive the mail queue, do the following:

Log in as root.
Change to the /var/spool directory by using the cd command.
Move the mqueue directory to the old.mqueue directory by using the mv command.
Make a new mqueue directory by using the mkdir command.
Change the directory's permission code to 775 by using the chmod command.
Restart sendmail by using the following command:
# /sbin/init.d/sendmail restart

After the major host returns on line, process the old mail queue by using the following command:

# /usr/sbin/sendmail -oQ/var/spool/old.mqueue -q

When the queue is empty, remove it by using the following command:

# rm -r /var/spool/old.mqueue

11.7 Administering and Distributing Alias Information

Depending on how you choose to administer and distribute alias information on standalone or server systems, there are two ways to provide alias information for use in the mail environment:

/var/adm/sendmail/aliases file
NIS aliases database

By default, the /var/adm/sendmail/aliases file permissions code is 644. This means that global users cannot change and write the changes to the file. While this creates a reasonably secure system, it leaves the maintenance of the list of global users up to the system administrator.

You can distribute responsibility for maintenance by doing the following:

Create a local alias file for a global maintainer in a directory. Both the file and the directory must be accessible by another maintainer.
Create an entry in the /var/adm/sendmail/aliases file that includes the additional alias file. The entry has the following form:
alias_name: :include:filename
The filename is the full path name and file name of the alias file.
Build a new version of the alias file by using the newaliases command.

See aliases(4) for more information.

You can also use NIS aliases database to administer and distribute alias information for use in the mail environment. To use the NIS aliases database, do the following:

Install and configure NIS, if this is not already done, by using the nissetup script.
Edit the svc.conf file by using the svcsetup script, and modify the aliases entry to include yp (NIS).
Edit the NIS aliases map to include the alias information you want.

See Chapter 7 for information on configuring NIS and Section 7.4.4 for information on updating an NIS map.

11.8 Display Mail Statistics

You can display statistics about mail traffic on your system by using the mailstats command as follows:

# /usr/sbin/mailstats

At any time, you can initialize the statistics file by issuing the following commands:

# cp /dev/null /var/adm/sendmail/sendmail.st # chmod 666 /dev/null /var/adm/sendmail/sendmail.st

11.9 Adding a New Mail Host

To add a new host to the mail environment, do the following:

Configure the network and network services. See Chapter 2 for more information.
If you are using BIND MX records in your environment, you must update the BIND data files. See Section 6.5 for more information.

If you want to:	Configure this service:
Distribute the aliases file	NIS
Use domain-based addressing	BIND