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 1-3 shows the contents of the /usr/bin directory that are used for mail services.

Table 1-3 Contents of the /usr/bin Directory Used for Mail Services

Name	Type	Description
aliasadm	File	A program to manipulate the NIS+ aliases map
mail	File	A user agent
mailcompat	File	A filter to store mail in SunOS 4.1 mailbox format
mailq	Link	Link to /usr/lib/sendmail; used to list the mail queue
mailstats	File	A program used to read mail statistics stored in the /etc/mail/sendmail.st file (if present)
mailx	File	A user agent
mconnect	File	A program that connects to the mailer for address verification and debugging
newaliases	Link	Link to /usr/lib/sendmail; used to create the binary form of the aliases file
rmail	Link	Link to /usr/bin/mail; command often used to permit only the sending of mail
vacation	File	A command to set up an automatic reply to mail

Table 1-4 shows the contents of the /etc/mail directory.

Table 1-4 Contents of the /etc/mail Directory

Name	Type	Description
Mail.rc	File	Default settings for the mailtool user agent
aliases	File	Mail-forwarding information
aliases.dir	File	Binary form of mail-forwarding information (created by running newaliases)
aliases.pag	File	Binary form of mail-forwarding information (created by running newaliases)
mailx.rc	File	Default settings for the mailx user agent
main.cf	File	Sample configuration file for main systems
relay-domains	File	Contains a list of all domains for which relaying is allowed; by default, only the local domain is allowed
sendmail.cf	File	Configuration file for mail routing
sendmail.cw	File	Optional file that you can create if the number of aliases for the mail host is too long
sendmail.hf	File	Help file used by the SMTP HELP command
sendmail.pid	File	File that lists the PID of the listening daemon
sendmail.st	File	The sendmail statistics file; if this file is present, sendmail logs the amount of traffic through each mailer
sendmailvars	File	Stores macro and class definitions for name space lookup from sendmail.cf
subsidiary.cf	File	Sample configuration file for subsidiary systems

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

Table 1-5 Contents of the /usr/lib Directory Used for Mail Services

Name	Type	Description
mail.local	File	Mailer that delivers mail to mailboxes
sendmail	File	The routing program, also known as the mail transfer agent

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 1-6.

Table 1-6 Contents of the /usr/lib/mail Directory Used for Mail Services

Name	Type	Description
README	File	Document describing the configuration files
cf	Directory	Site-dependent and site-independent descriptions of hosts
cf/main-v7sun.mc	File	Main configuration file
cf/makefile	File	Contains rules for building new configuration files
cf/subsidiary-v7sun.mc	File	Configuration file for hosts that NFS-mount /var/mail from another host
domain	Directory	Site-dependent subdomain descriptions
domain/generic.m4	File	Generic domain file from Berkeley
domain/solaris-antispam.m4	File	Domain file with changes that make sendmail function like previous Solaris versions, except that relaying is disabled completely, sender addresses with no hostname are rejected, and unresolvable domains are rejected
domain/solaris-generic.m4	File	Domain file with changes that make sendmail function like previous Solaris versions (default)
feature	Directory	Definitions of specific features for particular hosts (see README for a full description of the features)
m4	Directory	Site-independent include files
mailer	Directory	Definitions of mailers, which include local, smtp and uucp
ostype	Directory	Definitions describing various operating system environments
ostype/solaris2.m4	File	Defines local mailer as mail
ostype/solaris2.ml.m4	File	Defines local mailer as mail.local (default)
sh	Directory	Shell scripts used by the m4 build process and migration aids
sh/check-permissions	File	Checks permissions of :include: aliases and .forward files and their parent directory path for correct permissions
sh/check-hostname	File	Verifies that sendmail is able to determine the fully qualified host name

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

Table 1-7 Other Files Used for Mail Services

Name	Type	Description
sendmailvars.org_dir	Table	NIS+ version of sendmailvars file
/etc/shells	File	Lists the valid login shells
/usr/sbin/in.comsat	File	Mail-notification daemon
/usr/sbin/makemap	File	Builds binary forms of keyed maps
/usr/sbin/syslogd	File	Error message logger, used by sendmail
/usr/dt/bin/dtmail	File	CDE mail user agent
/var/mail/mailbox1, /var/mail/mailbox2	File	Mailboxes for delivered mail
/var/spool/mqueue	Directory	Storage for undelivered mail
$OPENWINHOME/bin/mailtool	File	Window-based mail user agent

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

Figure 1-3 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 TCP/IP and Data Communications Administration Guide 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.

---

Note -

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 "Setting Up DNS to Work 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 namespace-wide basis, depending on the type of file that is used. Using a namespace alias file allows for mail rerouting changes to be administered at a single source, but there can be lag-times created when the change is propagated. Also, namespace administration is usually restricted to a select group of system administrators, so this is not a change that a normal user is able to 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 lag-time 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 is able to administer.

The next mechanisms, forwarding and inclusion, allow users the ability to administer mail rerouting. Forwarding allows local users to reroute their incoming mail to either another mail box, 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, then the user can reroute mail as needed. More information on inclusion can be found in "/etc/mail/aliases".

Figure 1-4 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 1-4 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 is 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 1-5 shows how sendmail interacts with the other programs in the mail system.

Figure 1-5 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.