Components of the Mail Service

Mail services include many programs and daemons that interact with each other. This section introduces the programs and the terms and concepts related to administration of electronic mail.

Mail Services Programs and Files

Table 8-1 lists the mail services programs and files.

Table 8-1

Command	Description
/usr/bin/mailx	Mail program described in mailx(1)
/usr/bin/mail	Mailer that delivers mail to mailboxes
$OPENWINHOME/bin/mailtool	Window-based interface to the sendmail program
/usr/lib/sendmail	Mail-routing program
/usr/lib/sendmail.mx	Mail-routing program linked with the domain name service resolver
/etc/mail/main.cf	Sample configuration file for main systems
/etc/mail/sendmail.subsidiary.cf	Sample configuration file for subsidiary systems
/etc/mail/sendmail.cf	Configuration file for mail routing
/etc/mail/aliases	Mail forwarding information
/etc/mail/sendmailvars	Table that stores macro and class definitions for lookup from sendmail.cf file
sendmailvars.org_dir	NIS+ version of sendmailvars table
/usr/bin/newaliases	Symbolic link to /usr/lib/sendmail
/usr/bin/mailq	Symbolic link to /usr/lib/sendmail
/usr/bin/mailstats	File used to store mail statistics generated by /etc/mail/sendmail.st (if present)

Table 8-1 (Continued)

Command	Description
/usr/bin/mconnect	Connects to the mailer for address verification and debugging
/usr/sbin/in.comsat	Mail notification daemon
/usr/sbin/syslogd	Error message logger, used by sendmail

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

Figure 8-1

Users send messages by using programs like /bin/mailx, or mailtool. See the reference manual pages for information about these programs.

The message is collected by the program that was used to generate it, and 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 /bin/mail 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 the /bin/mail, /bin/mailx, mailtool, or similar programs.

Mail Services Terminology

This section defines the following terms and describes how they are used as part of the mail services:

• Systems in a mail configuration

  · Relay host

  · Gateway

  · Mail host

  · Mail server

  · Mail client

• User Agent (UA)
• Mail Transfer Agent (MTA)
• Mailers
• Domain Names
• Mail address
• Mailbox
• Aliases
• sendmail program
• Configuration file (sendmail.cf)
• Configuration table (sendmailvars)
• .forward files

Systems in a Mail Configuration

A mail configuration requires three elements, which can be combined on the same system or provided by separate systems:

• At least one mail server
• A mail host
• Mail clients

When you want users to communicate with networks outside your subnet, you must also have a relay host or a gateway.

Figure 8-2 shows a typical electronic mail configuration, using all three elements and a relay host. Each element is identified and described in the following sections.

Figure 8-2

Relay Host A relay host is a system that runs at least one mail-related protocol, called a mailer. Each mailer specifies a policy and the mechanics to be used when delivering mail. The relay host handles mail with an address for which sendmail could not find a recipient in your domain. If a relay host exists, sendmail uses it for sending and receiving mail outside your domain.

The mailer on the sending relay host must be compatible with the mailer on the receiving system, as shown in Figure 8-3. You specify the mailer for your domain in the sendmail.cf file. The default sendmail.cf file defines several mailer specifications, like smartuucp, ddn, ether, and uucp. You can define others.

Figure 8-3

The relay host can be the same system as the mail host, or you can configure another system as the relay host. You can, in fact, configure more than one relay host for your domain if you have several connections outside of your site. If you have a uucp or Internet connection, configure the system with those connections as the relay host.

Gateway A gateway is a system that handles connections between networks running different communications protocols, or between different subnets running the same communications protocols, as shown in Figure 8-4. A relay host and the system to which it is connected must use matching mailers. But, a gateway can handle connections to systems with unmatched mailers. You must customize the sendmail.cf file on the gateway system, which can be a difficult and time-consuming process.

Figure 8-4

If you have to set up a gateway, you should find a gateway configuration file that is close to what you need, and modify it to fit your situation.

Mail Host A mail host is a system that you designate as the main mail machine on your network. The mail host is the system to which other systems at the site forward mail that they cannot deliver. You designate a system as a mail host by adding

the word mailhost to the Internet Protocol (IP) address line in the system's /etc/hosts file. You must also use the main.cf file as the mail configuration file on the mail host system.

A good candidate for mail host is a system that is attached to an Ethernet and to phone lines, or a system configured as a router to the Internet. If you have a standalone system that is not networked but is in a time-sharing configuration, you can set up electronic mail on it. Treat the standalone system as the mail host of a one-system network. Similarly, if you have several systems on an Ethernet and none have phones, designate one as the mail host.

Mail Server A mail server is any system that stores mailboxes in the /var/mail directory. The mail server routes all mail from a client. When a client sends mail, the mail server puts it in a queue for delivery. Once the mail is in the queue, the client can reboot or turn off the system without losing those mail messages. When the recipient gets mail from a client, the path in the "From" line of the message contains the name of the mail server. If the recipient responds, the response goes to the user's mailbox.

Mail is delivered to the system where the user's mailbox resides.

If the mail server is not the user's local system, users with NFS can mount the /var/mail directory by using the /etc/vfstab file, using the Automounter, or logging in to the server to read their mail.

---

Note - If you automount the /var/mail directory, you may have problems with mail on heterogeneous networks with SunOS 4.1 mail clients. Good candidates for mail servers are systems that provide a home directory for users, or that are backed up regularly.

---

Table 8-2 shows some sample statistics about the size of mail messages and mail traffic at a computer company with about 12,000 employees.

---

Note - The information in Table 8-2 is valid for ASCII messages only. With the advent of multimedia mail, which lets users transmit any type of data (not just ASCII text), the average size of an email message is likely to grow enormously. In the future, system administrators will need to allocate more spooling space for multimedia mailboxes.

---

Table 8-2

Statistic	Description
6,500 bytes	Average size of an email message
140 Kbytes	Amount of mail received by an average user in one day
15 Kbytes	Small mailbox size (user reads mail regularly and stores messages elsewhere)
40 Mbytes	Large mailbox size (user stores long-term mail in /var/mail mailbox)
18,000	Average number of messages per day sent outside the company
55,000	Average number of messages per day received from outside the company
2 Mbytes	Recommended spooling space to allocate for each user's mailbox, based on the figures in this table

Mail Client A mail client is any system that receives mail on a mail server and does not have a local /var/mail directory.

You must make sure the mail client has the appropriate entry in the /etc/vfstab file and a mount point to mount the mailbox from the mail server.

User Agent

The user agent is the program that acts as the interface between the user and the sendmail program. The user agents supplied with the SunOS 5.x software system are /usr/bin/mail, /usr/bin/mailx, and $OPENWINHOME/bin/mailtool.

Mail Transport Agent

The mail transport agent is responsible for actually receiving and delivering messages. The transport agent for the SunOS 5.x software is sendmail. The transport agent performs these functions:

• Accepts messages from the user agent
• Understands destination addresses
• Delivers mail originating on the local system to the proper mailboxes, if local, or to a delivery agent if not local
• Receives incoming mail from other delivery agents and delivers it to local users

Mailers

A mailer is a protocol that specifies the policy and mechanics used by sendmail when it delivers mail. You need to specify a mailer in the sendmail.cf file of a relay host or a gateway. The mailer for a relay host must match the mailer on the system outside of your domain. A gateway is a more complicated relay host (or you can think of a relay host as a simple gateway) and can communicate with more than one type of mailer.

The mailers provided with the SunOS 5.x system are:

• The smartuucp mailer (the default relay mailer) uses uux to deliver messages, but it formats headers with a domain-style address, and the To: and CC: lines are formatted by domain. For example, if ignatz in the eng.acme.com domain sends mail to guy at auspex using smartuucp, the headers look like this:

To: guy@auspex.com From: ignatz@Eng.acme.COM

Use smartuucp for uucp mail to systems that can handle and resolve domain-style names. The sender also must be able to handle domain-style names and be able to receive replies from the Internet.

• The uucp mailer uses uux to deliver mail, but it uses an exclamation point address in the headers. For example, if ignatz in domain acme.eng.acme.com sends mail to guy@auspix using the uucp mailer, the headers look like this:

To: auspex!guy From: acme!ignatz

Use uucp for uucp connections to systems that need a bang-style path.

• The ddn mailer uses the Simple Mail Transfer Protocol (SMTP) on port 25 to connect to the remote host. The ddn mailer inverts aliases and adds a domain name. For example, if ignatz in domain eng.acme.com sends mail to paul@phoenix.stateu.edu, the headers look like this:

To: paul@phoenix.stateu.edu From: Iggy.Ignatz@Eng.acme.COM

If ignatz sends mail to irving@sluggo (both users in the eng.acme.com domain), the header looks like this:

To: Irving.Who@Eng.acme.Com From: Iggy.Ignatz@Eng.acme.COM

Use ddn for sending mail outside of your domain, especially for mailers that you must reach through a relay.

• The ether mailer uses the SMTP on port 25 to connect to the remote host. The ether mailer does not invert aliases or append a domain name.

  Use ether for systems in your dns domain that users can reach directly.

You can define other mailers by providing a mailer specification in the sendmail.cf file.

Domain Names

A domain is a directory structure for electronic mail addressing and network address naming. The domain address has this format:

mailbox@subdomain. ... .subdomain2.subdomain1.top-level-domain

The part of the address to the left of the @ sign is the local address, as shown in Figure 8-5.

Figure 8-5

The local address may contain information about the following:

• Routing using another mail transport (for example,

bob::vmsvax@gateway or
smallberries%mill.uucp@physics.uchicago.edu)

• An alias (for example, iggy.ignatz)
• A token that resolves to the name of a mailbox (for example, ignatz--> /var/mail/ignatz)

The receiving mailer is responsible for determining what the local part of the address means.

The part of the address to the right of the @ sign shows the domain address where the local address is located. A dot separates each part of the domain address. The domain can be an organization, a physical area, or a geographic region. In older forms the domain can show one or several computer systems.

Domain addresses are case-insensitive. It makes no difference whether you use uppercase, lowercase, or mixed case letters in the domain part of an address.

The order of domain information is hierarchical--the more local the address, the closer it is to the @ sign.

---

Note - British and New Zealand domains reverse this order. Most gateways automatically translate the reverse order of British and New Zealand domain names into the hierarchical order.

---

The larger the number of subdomains, the more detailed the information that is provided about the destination. Just as a subdirectory in a file-system hierarchy is considered to be inside the directory above, each subdomain in the mail address is considered to be inside the location to its right.

Table 8-3 shows the top-level domains in the United States.

Table 8-3

Domain	Description
Com	Commercial sites
Edu	Educational sites
Gov	Government installations
Mil	Military installations
Net	Networking organizations
Org	Nonprofit organizations

Table 8-4 shows the top-level domains for the United States and European countries. !%@:: A Directory of Electronic Mail Addressing and Networks, written by Donnalyn Frey and Rick Adams, contains a complete list of domain addresses, and is updated periodically.

Table 8-4

Domain	Description
AT	Austria
BE	Belgium
CH	Switzerland
DE	Germany
DK	Denmark
ES	Spain
FI	Finland

Table 8-4 (Continued)

Domain	Description
FR	France
GR	Greece
IE	Ireland
IS	Iceland
IT	Italy
LU	Luxembourg
NL	The Netherlands
NO	Norway
PT	Portugal
SE	Sweden
TR	Turkey
UK	United Kingdom
US	United States
YU	Yugoslavia

For mail delivery, the network domain name and the mail domain name normally do not match. By default, the sendmail program strips off the first component from the network domain name to form the mail domain name. Mail is then delivered to the mailer for that mail domain. For example, if a NIS+ domain name were bldg5.EBB.Eng.acme.COM, its mail domain name would be EBB.Eng.acme.COM.

This default rule for determining the mail domain name restricts the number of components you can have in the network domain name. Fortunately, you can define the mail domain name in the sendmail.cf file. You can set the m variable (for mail domain name) using either a D macro definition or an L macro definition. The former is a simple assignment, while the latter uses a lookup table (sendmailvars) maintained by the naming service. The advantage of the lookup table is that you can change the mail domain name easily without having to edit the sendmail.cf file on each client.

Mail Address

The mail address contains the name of the recipient and the system to which the mail message is delivered.

When you administer a small mail system that does not use a naming service, addressing mail is easy: login names identify users uniquely.

When, however, you are administering a mail system that has more than one system with mailboxes, one or more domains, or when you have a uucp (or other) mail connection to the outside world, mail addressing becomes more complex. Mail addresses can be route-based, route-independent, or a mixture of the two.

Route-Based Addressing Route-based addressing requires the sender of an email message to specify the local address (typically a user name) and its final destination, as well as the route that the message must take to reach its final destination. Route-based addresses are fairly common on uucp networks, and have this format:

host!path!user

Whenever you see an exclamation point as part of an email address, all (or some) of the route was specified by the sender. Route-based addresses are always read from left to right.

For example, an email address that looks like this:

venus!acme!sierra!hplabs!ucbvax!ignatz

reached user ignatz from the system named venus by going first to the address acme, then to sierra, then to hplabs, and finally to ucbvax. (Note that this is an example and not an actual route.) If any of the four mail handlers is out of commission, the message will be delayed or returned as undeliverable.

Route-Independent Addressing Route-independent addressing requires the sender of an email message to specify the name of the recipient and the final destination address. Route-independent addresses usually indicate the use of a high-speed network like the Internet. In addition, newer uucp connections frequently use domain-style names. Route-independent addresses may have this format:

user@host.domain

Increased popularity of the domain hierarchical naming scheme for computers across the country is making route-independent addresses more common. In fact, the most common route-independent address omits the host name, and relies on the domain naming service to properly identify the final destination of the email message:

user@domain

Route-independent addresses are read by searching for the @ sign, then reading the domain hierarchy from the right (the highest level) to the left (the most specific address to the right of the @ sign).

Mailbox

A mailbox is a directory on a mail server that is the final destination for email messages. The name of the mailbox may be the user name, a group of users, or a place to put mail for someone with a specific function, like the postmaster. Mailboxes are in the /var/mail/username directory on either the user's local system or on a mail server. However, in either case, the mailbox is on the system to which the mail is delivered.

Mail should always be delivered to a local file system so that the user agent can pull mail from the mail spool and store it readily in the local mailbox. Do not use NFS-mounted file systems as the destination for a user's mailbox. NFS-mounted file systems cause problems with mail delivery and handling. Clients that NFS-mount /var/mail go into "Remote Mode" and arrange to have the server send and receive mail for them.

The /etc/mail/aliases file and naming services like NIS and NIS+ provide mechanisms for creating aliases for electronic mail addresses, so that users do not need to know the precise local name of a user's mailbox.

Some common naming conventions for special-purpose mailboxes are shown in Table 8-5.

Table 8-5

Format	Description
username	User names are frequently the same as mailbox names.
Firstname.Lastname Firstname_Lastname Firstinitial.Lastname Firstinitial_Lastname	User names may be identified as full names with a dot (or an underscore) separating the first and last names, or by a first initial with a dot (or an underscore) separating the initial and the last name.
postmaster	Users can address questions and report problems with the mail system to the postmaster mailbox. Each site and domain should have a postmaster mailbox.
MAILER-DAEMON	sendmail automatically routes any mail addressed to the MAILER-DAEMON to the postmaster.
x-interest	Names with dashes are likely to be a distribution list or a mailing list. This format is commonly used for net mail groups.
x-interest-request	Names ending in -request are administrative addresses for distribution lists.
owner-x-interest	Names beginning with owner- are administrative addresses for distribution lists.
local%domain	The percent sign (%) marks a local address that is expanded when the message arrives at its destination. Most mail systems interpret mailbox names with % characters as full mail addresses. The % is replaced with an @, and the mail is redirected accordingly. Although many people use the % convention, it is not a formal standard. In the email community, it is referred to as the "% hack."

Aliases

An alias is an alternate name. For electronic mail, you can use aliases to assign additional names to a user, route mail to a particular system, or define mailing lists.

You need to create a mail alias for each user at your site. The alias points to where the mail is stored. Providing a mail alias is like providing a mail stop as part of the address for an individual at a large corporation. If you do not provide the mail stop, the mail is delivered to a central address. Extra effort is required to determine where, within the building, the mail is to be delivered, and the possibility of error increases. For example, if there are two people named Kevin Smith in the same building, the probability is high that each Kevin will receive mail intended for the other one.

Use domains and location-independent addresses as much as possible when you create alias files. To enhance portability and flexibility of alias files, make your alias entries as generic and system-independent as possible. For example, if you have a user named ignatz on system mars, in domain Adm.acme.com, create the alias as ignatz instead of ignatz@Eng or ignatz@mars. If user ignatz changes the name of his system, but remains within the engineering domain, you do not need to update any alias files to reflect the change in system name.

When creating aliases that include users outside of your domain, create the alias with the user name and the domain name. For example, if you have a user named smallberries on system privet, in domain Mgmt.acme.com, create the alias as smallberries@Corp.acme.com.

You can set an option in the sendmail.cf file to translate the email address to a fully qualified domain name when mail goes outside of the user's domain.

Uses for Aliases Files You create mail aliases for global use in the NIS+ mail_aliases table, the NIS aliases map, or in local /etc/mail/aliases files if your site does not use a naming service. You can also create and administer mailing lists using the same alias files.

Depending on the configuration of your mail services, you may administer aliases by using the NIS or NIS+ naming service to maintain a global aliases database, or by updating all of the local /etc/mail/aliases files to keep them in sync.

Users can also create and use aliases. They can create aliases either in their local .mailrc file, which only they can use, or in their local /etc/mail/aliases file, which can be used by anyone. Users cannot create or administer NIS or NIS+ alias files.

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

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

alias: expansion [options # "comments"]

Four columns are described in Table 8-6.

Table 8-6

Column	Description
alias	The name of the alias
expansion	The value of the alias as it would appear in a sendmail /etc/aliases file
options	Reserved for future use
comments	Comments about an individual alias

The NIS+ 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. See "How to List the Contents of an NIS+ Aliases Table" on page 257 for information about how to create NIS+ alias tables.

When creating alias entries, enter one alias per line. You should only have one entry that contains the user's system name. For example, you could create the following entries for one user named ignatz:

ignatz: iggy.ignatz iignatz: iggy.ignatz iggyi: iggy.ignatz iggy.ignatz: ignatz@mars

You can create an alias for local names or domains. For example, an alias entry for user fred who has a mailbox on the system mars and who is in the domain Planets could have this entry in the NIS+ aliases table:

fred: fred@Planets

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

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

name: name1, name2, ...

Syntax of .mailrc Aliases Aliases in a .mailrc file adhere to the following format:

alias aliasname value value value ...

Syntax of /etc/mail/aliases Aliases Distribution list formats in a local /etc/mail/aliases file adhere to the following format:

aliasname: value,value,value...

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.

sendmail Program

The SunOS 5.x operating system 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, understands the recipients' addresses, chooses an appropriate delivery program, rewrites the addresses in a format that the delivery agent understands, reformats the mail headers as required, and finally passes the transformed message to the mail program for delivery.

Figure 8-6 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. Note that this behavior can be changed using nsswitch.conf. See the reference manual page for nsswitch.conf(4).

---

1. See sendmail, by Bryan Costales with Eric Allman and Neil Rickert, published by O'Reilly & Associates, Inc., 1993, for a complete explanation of the sendmail program.

Figure 8-6 sendmail

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, relay hosts, and gateways.

The SunOS 5.x system provides two default configuration files in the /etc/mail directory:

• A configuration file, named main.cf, for the system (or systems) you designate as the mail host, a relay host, or a gateway
• A configuration file, named sendmail.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, relay host, or gateway, copy the main.cf file and rename it sendmail.cf (in the /etc/mail directory). Then edit the sendmail.cf file to set the relay mailer and relay host parameters needed for your mail configuration.

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

• Time values specify:

  · How often sendmail runs the queue. The interval is typically set to between 15 minutes and 1 hour

  · Read timeouts

  · How long 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.
• File modes set:

  · User ID (setuid) for sendmail

  · Temporary file modes

  · /etc/mail/aliases permissions

sendmail Configuration Table

In response to two entries in the sendmail.cf file, the sendmail program can define macros and classes by looking up values in the sendmailvars configuration table. There are two such commands:

• Lines that begin with the L key letter are macro definitions, where the values assigned to the specified variable are obtained from the configuration table.
• Lines that begin with the G key letter are class definitions, where the values assigned to the specified variable are obtained from the configuration table.

The L command has the following syntax:

LXsearch_key

For example: Lmmaildomain

In this case, the search key maildomain is used to look up a value in the configuration table to assign to the variable m. Most often the single-letter variable name is uppercase, but for internal variables (like m for the mail domain name) it is lowercase.

The G command has the following syntax:

GCsearch_key

For example: GVuucp-list

In this case, the search key uucp-list is used to look up a value in the configuration table to assign to the variable V.

In both cases, matching of the search key is case sensitive.

Both commands have counterparts for defining macros or classes within the sendmail.cf file, rather than the lookup table. D is the counterpart of L; C is the counterpart of G.

If NIS+ is used to administer the network, a global version of the table, sendmailvars.org_dir, can be maintained. In addition to the NIS+ table or as an alternative, the table can be maintained in /etc/mail/sendmailvars files. The order in which these sources are searched by sendmail is controlled by the sendmailvars entry in the /etc/nsswitch.conf file. By default, the search order is files nisplus, which means sendmail attempts to look up information in the local table, before going to the NIS+ table.

Entries in an /etc/mail/sendmailvars file have the following format: search_key [value1 value2 value3...]

The search key may be followed by a Tab or several spaces; values are separated by a single space.

The NIS+ sendmailvars table has two columns: a Key column and a Value column. The Value column can have one or more values, each separated by a space. For example:

Key Column	Value Column
maildomain	Eng.acme.COM
uucp-list	acmemoon hugo comic

Most mail variables should be defined in the NIS+ table. However, in special cases, systems can override the global setting for a variable by including it in a their local /etc/mail/sendmailvars file. The following are such cases:

• A system that has a local uucp connection
• A gateway machine between two Internet domains

.forward Files

Users can create a .forward file in their home directories that sendmail uses to temporarily redirect mail or send mail to a custom set of programs without bothering 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.

Planning Your Mail System

This section describes four basic types of mail configurations, and briefly outlines the tasks required to set up each configuration. You may find this section useful if you need to set up a new mail system or if you are expanding an existing one. The configurations start with the most basic case (mail completely local, no connection to the outside world) and increase in complexity to a two-domain configuration with a gateway.

To set up a mail system, regardless of its configuration, you need these elements:

• A sendmail.cf configuration file on each system
• Alias files with an alias for each user to point to the place where mail is stored
• A mailbox to store (or spool) mail files for each user
• A postmaster alias for the person who administers mail services

How you set up the configuration file and the alias file and where you put the mailboxes depend on the configuration you choose.

As system administrator, you should decide on a policy for updating aliases and for forwarding mail messages. You might set up an aliases mailbox as a place for users to send requests for mail forwarding and for changes to their default mail alias. If your system uses NIS or NIS+, you can administer forwarding rather than forcing users to manage it themselves.

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

Local Mail Only

The simplest mail configuration, shown in Figure 8-7, is one mail server with two or more workstations connected to it. Mail is completely local. One system is both the mail server (provides mail spooling for client mailboxes) and the mail host. Mail addresses are parsed using the /etc/mail/aliases files. No naming service is used.

Figure 8-7

To set up this kind of a local mail configuration, assuming that the mail clients mount their mail files from /var/mail on the mail host, you need:

• The default sendmail.cf file in the /etc/mail directory on each system
• A server designated as the mail host (add mailhost to the /etc/hosts file on the mail host; then if you are not running NIS or NIS+, add the mail host IP address line to the /etc/hosts file of all mail clients)
• Matching /etc/mail/aliases files on any system that has a local mailbox
• Entries in each mail client's /etc/vfstab file to mount the /var/mail directory when mailboxes are located on the mail host

Local Mail and a uucp Connection

The most common mail configuration in a small network is shown in Figure 8-8. One system is the mail server, the mail host, and the relay host to the outside world. Mail is distributed using the /etc/mail/aliases files. No naming service is required.

Figure 8-8 uucp

To set up this kind of a mail configuration, assuming that the mail clients mount their mail files from /var/mail on the mail host, you need:

• The main.cf file on the mail host (you must edit the file to select a major relay mailer)
• The default sendmail.subsidiary.cf file on each mail client system (no editing required)
• A server designated as the mail host (add mailhost to the /etc/hosts file on the mail host; if you are not running NIS or NIS+, add the mail host IP address line to the /etc/hosts file of all mail clients)
• Matching /etc/mail/aliases files on any system that has a local mailbox
• Entries in each mail client's /etc/vfstab file to mount the /var/mail directory when mailboxes are located on the mail host

One Domain, Two Networks, and a Router

The mail configuration shown in Figure 8-9 has one domain, two networks, and a router. In this configuration, the mail server, the mail host, and the relay host (or hosts) are likely to be different systems. To make the process of administering and distributing mail easier, a naming service is used.

Figure 8-9 uucp

To set up this kind of a mail configuration, assuming that the mail clients may have local or remote /var/mail files, you need everything specified in Table 8-7.

Table 8-7

Category	Requirements
Relay host	The main.cf file on the relay hosts--the systems with uucp connections. You must edit the file to select a major relay connector. You may want to define a mail relay host that knows about all connections. Special rules added to the sendmail.cf file can help but are not mandatory.
Mail host	One system designated as the mail host (add mail host to the /etc/hosts file on the mail host system).

Table 8-7 (Continued)

Category	Requirements
Mail server	Adequate spooling space for client mailboxes.
Mail client	The sendmail.subsidiary.cf file on each mail client system (no editing required). Entries in each mail client's /etc/vfstab file to mount the /var/mail directory.
NIS+ tables	mail_aliases.org_dir tables for NIS+ with a mail alias entry for all users to point to where their mail is stored.

Two Domains and a Gateway

The mail configuration shown in Figure 8-10 has two domains and a gateway. In this configuration, the mail server, the mail host, and the relay host (or hosts) for each domain are likely to be different systems. To make the process of administering and distributing mail easier, a naming service is used.

Figure 8-10

Table 8-8 lists the requirements for this mail configuration.

Table 8-8

Category	Requirements
Gateway	Complex gateway systems usually need a customized sendmail.cf file with special rules added.
Relay host	The main.cf file on the relay hosts--the systems with uucp connections. (You must edit the file to select a major relay mailer.) It might be useful to define a mail relay host with information about all connections. (Special rules added to the sendmail.cf file can help but are not mandatory.) NOTE: The sendmail.subsidiary.cf file has an entry (the CV class) that you can use to define "local" uucp connections (like the system at the left of Domain 1 in Figure 8-10). If you define such a local uucp connection, users must address mail using the format, uucphost!remote-system!address.
Mail host	One system designated as the mail host (add mailhost to the /etc/hosts file on the mail host system).
Mail server	Adequate spooling space for client mailboxes.
Mail client	The sendmail.cf file on each mail client system (no editing required). Entries in each mail client's /etc/vfstab file to mount the /var/mail directory.
NIS+ tables	mail_aliases.org_dir tables for NIS+ with a mail alias entry for each user to point to where the mail is stored.

An Overview of the Mail Service

This section describes the directory structure and files of the mail service and explains how the sendmail program and mail addressing work.

Structure of the Mail Service

Files for the mail service are located in three directories: /bin, /etc/mail, and /usr/lib. User's mailboxes are located in the /var/mail directory.

Table 8-9 shows the contents of the /bin directory that are used for mail services.

Table 8-9 /bin

Name	Type	Description
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
mailstats	File	A file used to store mail statistics generated by the /etc/mail/sendmail.st file (if present)
mailx	File	A user agent
newaliases	Link	Link to /usr/lib/sendmail

Table 8-10 shows the contents of the /etc/mail directory.

Table 8-10 /etc/mail

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
newaliases	File	Command that creates the binary form of the aliases file
main.cf	File	Sample configuration file for main systems
sendmail.cf	File	Configuration file for mail routing
sendmail.fc	File	Frozen configuration file
sendmail.hf	File	Help file used by the SMTP HELP command

Table 8-10 /etc/mail(Continued)

Name	Type	Description
sendmail.st	File	The sendmail statistics file; if this file is present, sendmail logs the amount of traffic through each mailer
sendmailvars	File	Table that stores macro and class definitions for lookup from sendmail.cf
sendmailvars.org_dir	Table	NIS+ version of sendmailvars table
sendmail.subsidiary.cf	File	Sample configuration file for subsidiary systems

Table 8-11 shows the contents of the /usr/lib directory.

Table 8-11 /usr/lib

Name	Type	Description
sendmail	File	The routing program, also known as the mail transport agent
sendmail.mx	File	Mail-routing program linked with the domain name service

Spooling directories for delivered mail reside in the /var/mail directory, as shown in Table 8-12.

Table 8-12 /var/mail

Name	Type	Description
mqueue	Directory	Where undelivered mail is stored
mailbox1, mailbox2	File	Mailboxes for delivered mail

How the Mail Service Works

Figure 8-11 shows how sendmail interacts with the other programs in the mail system.

Figure 8-11

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.

How sendmail Works

The sendmail program collects a message from a program like mailx or mailtool, edits the message header as required by the destination mailer, and calls appropriate mailers to do delivery or queueing for network transmission.

---

Note - The sendmail program never edits or changes the body of a message. Any changes that it makes to interpret email addresses are made only in the header of the message.

---

Argument Processing and Address Parsing

When sendmail receives input, it collects recipient names (either from the command line or from the SMTP protocol) and generates two files. One is an envelope that contains a list of recipients. The other file contains the header and the body of the message. The sendmail program expands aliases, including mailing lists, and validates as much as possible of the remote recipient. Then sendmail checks syntax and verifies local recipients. Detailed checking of host names is deferred until delivery. As local recipients are verified, messages are forwarded to them.

After parsing the recipient lists, sendmail appends each name to both the envelope and the header of the message. When a name is "aliased" or forwarded, it retains the old name in the list and sets a flag to tell the delivery phase to ignore this recipient. The lists are kept free from duplicates, preventing alias loops and duplicate messages delivered to the same recipient, which can occur if a recipient is in two different alias groups.

---

Note - Users may receive duplicate copies of the same message when alias lists contain email addresses for the same person using different syntax. The sendmail program cannot always match the email addresses as duplicates of one another.

---

Message Collection

The sendmail program then collects the message. The message should have a header at the beginning. The header and the body of the message must be separated by a blank line. No formatting requirements are imposed on the message body except that they must be lines of text. sendmail stores the header in memory, and stores the body of the message in a temporary file. To simplify the program interface, the message is collected, even if no names are valid. The message is returned to the sender with an error.

---

Note - With multimedia Mail Tool, users can transmit binary data. However, it must be encoded by Mail Tool. The sendmail program does not automatically encode binary data. Refer to the Mail Tool documentation for information about how to encode and decode binary data messages.

---

Message Delivery

For each unique mailer and host in the recipient list, sendmail calls the appropriate mailer. The mailer sends the message to all recipients on the host.

The sendmail program sends the message to the mailer using one of the same interfaces used to submit a message to sendmail (using the conventional UNIX argument vector/return status, communicating over a pair of UNIX pipes, or using SMTP over a TCP connection). Each copy of the message has a customized header.

Error Handling

When mail can't be delivered, the mailer catches and checks the status code, and a suitable error message is given as appropriate. The exit code must conform to a system standard. If a nonstandard exit code is used, sendmail transmits the message, Services unavailable.

Queueing for Retransmission

When the mailer returns a status that shows it might be able to handle the mail later (for example, the next host is down, or the phone is busy for uucp), sendmail queues it and tries again later.

Return to Sender

If errors occur during processing, sendmail returns the message to the sender for retransmission. The letter may be mailed back or written to the dead.letter file in the sender's home directory.

How Mail Addressing Works

Assuming that you are using the default rule set in the sendmail.cf file, the following examples show the route an email message takes, depending on the way it is addressed.

Mail within a domain addressed with only the user's login name goes to the aliases file on the mail host (or to the aliases database), and is sent to the address found in the database. In the example shown in Figure 8-12, mail addressed to user ignatz goes to the mail host, and is forwarded to the host named mars.

Figure 8-12

Mail within a domain addressed with the user's login name and host name goes directly to the host system without any additional processing. In the example shown in Figure 8-13, mail addressed to user ignatz at the host named mars goes directly to the host named mars.

Figure 8-13

User and Host Names

Mail within a domain addressed with the user's login name and domain name goes to the aliases file on the mail host (or to the aliases database). If the mail host has an alias, it redirects the message to the host system. In the example shown in Figure 8-14, mail addressed to user ignatz@Lab goes to the mail host and is then forwarded to the host named mars.

Figure 8-14

User and Domain Names

Mail addressed with the user's name and a fully qualified domain name goes to the mail host, which sends it to the relay host. The relay host sends the message to the host system.

When the mail comes from within the recipient's domain, however, the mail host recognizes the domain name and does not send the message to the relay host. In the example shown in Figure 8-15, mail addressed to user ignatz@Lab.Acme.com from outside the engineering domain goes to the sender's mail host, the sender's relay host, and is then forwarded to the recipient's relay host, the recipient's mail host, and then to the host named mars.

Figure 8-15

Fully Qualified Domain Name

When a recipient responds to a message that was sent within a domain running neither NIS or NIS+, and with no /etc/aliases files on each system, using only the login name as an address, the sender's host name is appended to the address. If a recipient responds to such a message, the message is routed to the named system, then to the mail host. If the named host system is not available, the message is delayed until the host responds, or the message bounces after three days of trying. In the example shown in Figure 8-16, if ignatz@mars sent a copy to fred, and the recipient uses the information in the message header to reply, a message to fred@mars goes first to mars, then to the mail host, and finally to fred@venus, Fred's real mail destination.

Figure 8-16

Sender's Host Name