Mail Service Programs and Files

Mail services include many programs and daemons that interact with each other. This section introduces the programs and the terms and concepts related to administering electronic mail. Table 35-5 shows the contents of the /usr/bin directory that are used for mail services.

Table 35-6 shows the contents of the /etc/mail directory.

Table 35-7 shows the contents of the /usr/lib directory that are used for mail services.

Within the /usr/lib directory is a subdirectory that contains all of the files needed to build a sendmail.cf file. The contents of this directory are shown in Table 35-8.

Several other files and directories are used by the mail services, as shown in Table 35-9.

Mail services are provided by a combination of these programs, which interact as shown by the simplified diagram in Figure 35-2.

Figure 35-2 How Mail Programs Interact

Users send messages by using programs like mailx or mailtool. See the mailx(1) or mailtool(1) man pages for information about these programs.

The message is collected by the program that was used to generate it and is passed to the sendmail daemon. The sendmail daemon parses the addresses (divides them into identifiable segments) in the message, using information from the configuration file, /etc/mail/sendmail.cf, to determine network name syntax, aliases, forwarding information, and network topology. Using this information, sendmail determines the route a message must take to get to a recipient.

The sendmail daemon passes the message to the appropriate system. The /usr/lib/mail.local program on the local system delivers the mail to the mailbox in the /var/mail/username directory of the recipient of the message.

The recipient is notified that mail has arrived, and retrieves it using mail, mailx, mailtool, or a similar program.

sendmail Program

The sendmail program can use different types of communications protocols, like TCP/IP and UUCP. It also implements an SMTP server, message queueing, and mailing lists. Name interpretation is controlled by a pattern-matching system that can handle both domain-based naming and improvised conventions.

The sendmail program can accept domain-based naming as well as arbitrary (older) name syntaxes--resolving ambiguities by using heuristics you specify. sendmail can also convert messages between disparate naming schemes. The domain technique separates the issue of physical versus logical naming. See the "Domain Names" for a complete description of Internet domain-naming conventions.

You can handle certain special cases by improvised techniques, like providing network names that appear local to hosts on other networks.

The Solaris operating environment uses the sendmail program as a mail router. sendmail is responsible for receiving and delivering electronic mail messages. It is an interface between mail-reading programs like mail, mailx, and mailtool, and mail-transport programs like uucp. The sendmail program controls email messages that users send, evaluates the recipients' addresses, chooses an appropriate delivery program, rewrites the addresses in a format that the delivery agent can handle, reformats the mail headers as required, and finally passes the transformed message to the mail program for delivery.

Solaris releases prior to Solaris 2.4 included a binary called sendmail.mx. This program is now included in the sendmail program and the functionality is turned on by adding the dns flag to the hosts entry in /etc/nsswitch.conf. For more information, see "How to Use DNS With sendmail".

The sendmail program supports three mechanisms for mail rerouting. Which mechanism you choose depends on whether this is a server or domain-wide change, or just a change for one user. In addition, by selecting a different rerouting mechanism, you can change the level of administration required.

One rerouting mechanism is aliasing, which maps names to addresses on a server-wide or a name space-wide basis, depending on the type of file that is used. Using a name space alias file allows mail rerouting changes to be administered at a single source, but there can be lagtimes created when the change is propagated. Also, name space administration is usually restricted to a select group of system administrators, so this is not a change that a normal user can make. Rerouting handled through a server alias file is managed by anyone who can become root on that server. Normally, there should be little or no lagtime associated with propagating the change, but the change only affects the local server. This limitation might be acceptable if most of the mail is sent to one server anyway, but trying to propagate this change to many mail servers is easier using a name service. Again, this is not a change that a user can administer.

The next mechanisms, forwarding and inclusion, allow users to administer mail rerouting. Forwarding allows local users to reroute their incoming mail to either another mailbox, a different mailer, or to another mail host. This form of mail rerouting is supported through the use of .forward files. Further information on these files can be found in ".forward Files".

The last rerouting mechanism is inclusion, which allows for alias lists to be maintained by a user instead of requiring root access. To provide this, the root user must create an appropriate entry in the alias file on the server. After this entry is created, the user can reroute mail as needed. You can find more information on inclusion in "/etc/mail/aliases".

Figure 35-3 shows how sendmail uses aliases. Programs that read mail, like /usr/bin/mailx, can have aliases of their own, which are expanded before the message reaches sendmail. The aliases for sendmail can come from a number of name space sources (local files, NIS or NIS+). The order of the lookup is determined by the nsswitch.conf file. See the nsswitch.conf(4) man page.

Figure 35-3 How sendmail Uses Aliases

sendmail Features

The sendmail program provides the following features:

• It is reliable. It is designed to correctly deliver every message. No message should ever be completely lost.

• It uses existing software for delivery whenever possible.

• It can be configured to handle complex environments, including multiple connections to a single network type (like with UUCP or Ethernet). sendmail checks the contents of an address as well as its syntax to determine which mailer to use.

• It uses configuration files to control mail configuration instead of requiring that configuration information be compiled into the code.

• Users can maintain their own mailing lists. In addition, individuals can specify their own forwarding without modifying the domain-wide alias file (typically located in the domain-wide aliases maintained by NIS or NIS+).

• Each user can specify a custom mailer to process incoming mail, which can provide functions like returning an "I am on vacation" message. See the vacation(1) man page for more information.

• It batches addresses to a single host to reduce network traffic.

Figure 35-4 shows how sendmail interacts with the other programs in the mail system.

Figure 35-4 Interaction of sendmail With Other Mail Programs

The user interacts with a mail-generating and -sending program. When the mail is submitted, the mail-generating program calls sendmail, which routes the message to the correct mailers. Because some of the senders might be network servers and some of the mailers might be network clients, sendmail can be used as an Internet mail gateway.

sendmail Configuration File

A configuration file controls the way that sendmail performs its functions. The configuration file determines the choice of delivery agents, address rewriting rules, and the format of the mail header.

The sendmail program uses the information from the /etc/mail/sendmail.cf file to perform its functions. Each system has a default sendmail.cf file installed in the /etc/mail directory. You do not need to edit or change the default configuration file for mail servers or mail clients. The only systems that require a customized configuration file are mail hosts and mail gateways.

The Solaris operating environment provides two default configuration files in the /etc/mail directory:

1. A configuration file named main.cf for the system (or systems) you designate as the mail host or a mail gateway

2. A configuration file named subsidiary.cf (a duplicate copy of the default sendmail.cf file)

The configuration file you use on a system depends on the role the system plays in your mail service.

• For mail clients or mail servers, you do not need to do anything to set up or edit the default configuration file.

• To set up a mail host or gateway, copy the main.cf file and rename it sendmail.cf (in the /etc/mail directory). Then reconfigure the sendmail configuration file to set the relay mailer and relay host parameters needed for your mail configuration.

The following list describes some configuration parameters you might want to change, depending on the requirements of your site:

• Time values specifies:

  • Read timeouts.

  • Length of time a message remains undelivered in the queue before it is returned to the sender.

• Delivery modes specify how quickly mail will be delivered.

• Load limiting prevents wasted time during loaded periods by not attempting to deliver large messages, messages to many recipients, and messages to sites that have been down for a long time.

• Log level specifies what kinds of problems are logged.

Mail Alias Files

You can use any of the following files to maintain aliases. Which type of file to use depends on who will be using the alias and who needs to be able to change the alias. Each type of alias file has unique format requirements. Each of these is defined in the following sections.

.mailrc Aliases

Aliases listed in a .mailrc file are accessible only by the user who owns the file. This allows users to establish an alias file they control and that is usable only by its owner. Aliases in a .mailrc file adhere to the following format:

alias aliasname value value value ...

where aliasname is the name the user will use when sending mail, and value is a valid email address.

If a user establishes a personal alias for scott that does not match the email address for scott in the name space, mail will be routed to the wrong person when other people try to reply to mail generated by that user. The only workaround is to use any of the other aliasing mechanisms.

/etc/mail/aliases

Any alias established in the /etc/mail/aliases file can be used by any user who knows the name of the alias and the host name of the system that contains the file. Distribution list formats in a local /etc/mail/aliases file adhere to the following format:

aliasname: value,value,value...

where aliasname is the name the user will use when sending mail to this alias and value is a valid email address.

If your network is not running a name service, the /etc/mail/aliases file of each system should contain entries for all mail clients. You can either edit the file on each system or edit the file on one system and copy it to each of the other systems.

The aliases in the /etc/mail/aliases file are stored in text form. When you edit the /etc/mail/aliases file, run the newaliases program to recompile the database and make the aliases available in binary form to the sendmail program. Or you can use Administration Tool's Database Manager to administer the mail aliases stored in local /etc files.

You can create aliases for only local names--a current host name or no host name. For example, an alias entry for user ignatz who has a mailbox on the system saturn would have this entry in the /etc/mail/aliases file:

ignatz: ignatz@saturn

It is a good idea to create an administrative account for each mail server. You do this by assigning root a mailbox on the mail server and adding an entry to the /etc/mail/aliases file for root. For example, if the system saturn is a mailbox server, add the entry root: sysadmin@saturn to the /etc/mail/aliases file.

Normally, the root user only can edit this file. When using the Administration Tool, then all users in group 14, which is the sysadmin group, can change the local file. Another option is to create an entry like:

aliasname: :include:/path/aliasfile

where aliasname is the name the user will use when sending mail and /path/aliasfile is the full path to the file that includes the alias list. The alias file should include email entries, one entry on each line, and no other notations:

user1@host1
user2@host2

You can define additional mail files in /etc/mail/aliases to keep a log or a backup copy. The following entry stores all mail sent to aliasname in filename.

aliasname: /home/backup/filename

You can also route the mail to another process. The following stores a copy of the mail message in filename and prints a copy.

aliasname: "|tee -a /home/backup/filename |lp"

NIS Aliases Map

All users in the local domain can use entries included in the NIS aliases map. The sendmail program can use the NIS aliases map instead of the local /etc/mail/aliases files to determine mailing addresses. See the nsswitch.conf(4) man page for more information.

Aliases in the NIS aliases map adhere to the following format:

aliasname: value,value,value...

where aliasname is the name the user will use when sending mail and value is a valid email address.

The NIS aliases map should contain entries for all mail clients. In general, only the root user on the NIS master can change these entries. This type of alias might not be a good choice for aliases that are constantly changing, but can be useful if the alias points to another alias file; as in this syntax example:

aliasname: aliasname@host

where aliasname is the name the user will use when sending mail and host is the host name for the server that contains an /etc/mail/alias file.

NIS+ mail_aliases Table

The NIS+ mail_aliases table contains the names by which a system or person is known in the local domain. The sendmail program can use the NIS+ mail_aliases table instead of the local /etc/mail/aliases files to determine mailing addresses. See the aliasadm(1M) and nsswitch.conf(4) man pages for more information.

Aliases in the NIS+ mail_aliases table adhere to the following format:

alias:			expansion					[options		# "comments"]

Table 35-10 describes the four columns.

The NIS+ mail_aliases table should contain entries for all mail clients. You can list, create, modify, and delete entries in the NIS+ aliases table with the aliasadm command. Or you can use Administration Tool's Database Manager to administer NIS+ mail aliases.

If you are creating a new NIS+ aliases table, you must initialize the table before you create the entries. If the table exists, no initialization is needed.

To use the aliasadm command, you must be a member of the NIS+ group that owns the aliases table or the person who created the table.

.forward Files

Users can create a .forward file in their home directories that sendmail uses to redirect mail or send mail to a custom set of programs without consulting a system administrator. When troubleshooting mail problems, particularly problems with mail not being delivered to the expected address, always check the user's home directory for a .forward file.

A common mistake users make is to put a .forward file in the home directory of host1 that forwards mail to user@host2. When the mail gets to host2, sendmail looks up user in the NIS or NIS+ aliases and sends the message back to user@host1, resulting in a loop, and more bounced mail.

The root and bin accounts should never have .forward files. Creating these files will create a large security hole. If necessary, forward mail using the aliases file instead.

In order for a .forward file to be consulted during the delivery of mail, the file must be writable only by the owner of the file. This prevents other users from breaking security. In addition, the paths leading up to the home directory must be owned and writable by root only. In particular, if a .forward file is in /export/home/terry, then /export and /export/home must be owned and writable only by root. The actual home directory should be writable only by the user. Other restrictions on a .forward file are that the file cannot be a symbolic link and cannot have more than one hard link.

In addition to the standard .forward file, a .forward.hostname file can be created to redirect mail sent to a specific host. For example, if a user's alias has changed from a sandy@phoenix.eng.acme.com to sandy@eng.acme.com, place a .forward.phoenix file in the home directory for sandy.

% cat .forward.phoenix
sandy@eng.acme.com
"|/usr/bin/vacation sandy"
% cat .vacation.msg
From: sandy@eng.acme.com (via the vacation program)
Subject: my alias has changed

My alias has changed to sandy@eng.acme.com.
Please use this alias in the future.
The mail that I just received from you
has been forwarded to my new address.

Sandy

This allows for the mail to be forwarded to the correct place while also notifying the sender of the alias change. Because the vacation program allows only one message file, you can forward only one message at a time. However, if the message is not host specific, one vacation message file can be used by .forward files for many hosts.

Another extension to the forwarding mechanism is the .forward+detail file. The detail string can be any sequence of characters as long as no operator characters are used. The operator characters are .:%&!^[]+. Using a file like this can make it possible to determine if someone else is giving your email address away. For instance, if a user told someone to use the email address sandy+test1@eng.acme.com, the user would be able to identify any future mail that was delivered to this alias. By default, any mail sent to sandy+test1@eng.acme.com alias is checked against the alias and .forward+detail files. If there are no matches, the mail falls back to delivery to sandy@eng.acme.com, but the user is able to see a change in the To: header in their mail.

/etc/default/sendmail

This file is used to store start-up options for sendmail so that they are not removed when a host is upgraded. The following variables can be used:

MODE=-bd

Selects the mode to start sendmail with. Use the -bd option or leave it undefined.

QUEUEINTERVAL=#

Sets interval for the mail queues to be run. # can be a positive integer followed by either s for seconds, m for minutes, h for hours, d for days, or w for weeks. The syntax is checked before sendmail is started. If the interval is negative or if the entry does not end with an appropriate letter, the interval is ignored and sendmail starts with a queue interval of 15 minutes.

OPTIONS=string

Selects additional options to be used with the sendmail command. No syntax checking is done, so be careful when making changes to this variable.