Chapter 35 Mail Services Reference

The sendmail program is a mail transport agent that uses a configuration file to provide aliasing and forwarding, automatic routing to network gateways, and flexible configuration. The Solaris operating environment supplies standard configuration files that most sites can use. Chapter 34, Setting Up and Administering Mail Services explains how to set up an electronic mail system using the standard files. This chapter describes some of the differences between the generic version of sendmail and the Solaris version.

• "Solaris sendmail Differences"

• "Mail Services Terminology"

• "Mail Service Programs and Files"

• "How Mail Addressing Works"

• "How sendmail Interacts With a Name Service"

Solaris sendmail Differences

This section describes some of the changes included in the Solaris version of sendmail as compared to the generic Berkeley version.

Flags Used When Compiling sendmail

The following table lists the flags used when compiling the version of sendmail delivered with the Solaris 8 release. If your configuration requires other flags, you need to download the source and recompile the binary yourself. Information about this process can be found at http://www.sendmail.org.

Alternative sendmail Commands

The Solaris release does not include all of the command synonyms that are provided in the generic release from Berkeley. This table includes a complete list of the command aliases, whether they are included in the Solaris release, and how to generate the same behavior using sendmail.

Define Configuration File Version

The new version of sendmail (version 8.9.3) includes a new configuration option that defines the version of the sendmail.cf file. This will allow older configuration files to be used with Version 8.9.3 sendmail. You can set the version level to values between 0 and 8. You can also define the vendor. Either Berkeley or Sun are valid vendor options. If the V option is not defined in the configuration file, the default setting is V1/Sun. If a version level is specified but no vendor is defined, Sun is used as the default vendor setting. The following table lists some of the valid options.

Mail Services Terminology

In addition to the mail files and programs, many other components are required to establish a mail service. The following sections define these components and some of the terminology used to describe them.

The first section defines the terminology used when discussing the software parts of the mail delivery system. The next section focuses on the functions of the hardware systems in a mail configuration.

Mail Services Software Terminology

This section describes the software components of a mail system. Each service includes at least one of each of the following:

• Mail user agent

• Mail transfer agent

• Mail delivery agent

Other software components include domain names, mail addresses, mailboxes, and mail aliases.

Mail User Agent

The mail user agent is the program that acts as the interface between the user and mail transfer agent, such as the sendmail program. The mail user agents supplied with the Solaris operating environment are /usr/bin/mail, /usr/bin/mailx, $OPENWINHOME/bin/mailtool, and /usr/dt/bin/dtmail.

Mail Transfer Agent

The mail transfer agent is responsible for the routing of mail messages and resolution of mail addresses. This is also known as a mail transport agent. The transfer agent for the Solaris operating environment is sendmail. The transfer agent performs these functions:

• Accepts messages from the mail user agent

• Resolves destination addresses

• Selects a proper delivery agent to deliver the mail

• Receives incoming mail from other mail transfer agents

Mail Delivery Agent

A mail delivery agent is a program that implements a mail delivery protocol. The following mail delivery agents are provided with the Solaris operating environment:

• The UUCP mail delivery agent, which uses uux to deliver mail

• The local mail delivery agent, which is mail.local in the standard Solaris release

Mailers

A mailer is a sendmail specific term. You can customize a mail delivery agent. A mailer is used by sendmail to identify a specific instance of a customized mail delivery agent or a mail transfer agent.

You need to specify at least one mailer in the sendmail.cf file of all systems in your network.

The smtp mailer uses SMTP to transfer a message. SMTP is the standard mail protocol used on the Internet. This is an example of an SMTP mail header:

To: paul@phoenix.stateu.edu
From: Iggy.Ignatz@eng.acme.com

If mail is sent between two users in the same domain, the header looks like this:

To: Irving.Who@eng.acme.com
From: Iggy.Ignatz@eng.acme.com

Use SMTP for sending mail outside your domain, especially for mailboxes that you must reach through the Internet.

The uucp-old 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, much like the SMTP headers. The uucp headers look like this:

To: paul@phoenix.stateu.com
From: ignatz@eng.acme.com

Use uucp-uudom 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-old mailer uses an exclamation point address in the headers. This is one of the original mailers. The headers look like this:

To: edu!stateu!phoenix!paul
From: acme!ignatz

You can define other mail delivery agents by providing a mailer specification in the sendmail.cf file. Additional information about mailers can be found in /usr/lib/mail/README.

Domain Names

A domain is a directory structure for network address naming. Electronic-mail addressing also uses domains. An email address has this format:

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

The part of the address to the left of the @ sign is the local address. The local address can contain information about:

• Routing with another mail transport (for example, bob::vmsvax@gateway or smallberries%mill.uucp@gateway)

• An alias (for example, iggy.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.

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.

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.

The following table shows the top-level domains.

!%@:: A Directory of Electronic Mail Addressing and Networks by Donnalyn Frey and Rick Adams (O'Reilly & Associates, Inc., 1993) contains a complete list of international top-level domain addresses; it is updated periodically.

For mail delivery, the name space domain name and the mail domain name occasionally do not match. However, the DNS domain name and the mail domain name must be identical. By default, the sendmail program strips the first component from the domain name to form the mail domain name. For example, if a NIS+ domain name were bldg5.eng.acme.com, its mail domain name would be eng.acme.com.

Although mail domain addresses are case insensitive, the name space domain name is not. For best results use lowercase characters when setting up the mail and name space domain names.

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 name service, addressing mail is easy: login names uniquely identify users.

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 independent, route based, or a mixture of the two. Route-based addressing is based on old specifications and is not required or desired in most situations.

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 can have this format:

user@host.domain

UUCP connections can use the following address format:

host.domain!user

The increased popularity of the domain hierarchical naming scheme for computers is making route-independent addresses more common. In fact, the most common route-independent address omits the host name and relies on the domain name 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).

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 were fairly common on UUCP networks, and have this format:

path!host!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!ignatz

means that mail sent to the user named ignatz is first sent to the system named venus, next to acme, and then to sierra. (This is an example and not an actual route.) If any of the mail handlers is down, the message will be delayed or returned as undeliverable.

Mail sent through the uucp mailer is not restricted to using route-based addressing. Some uucp mailers also handle route-independent addressing.

Mailbox

A mailbox is a file on a mail server that is the final destination for email messages. The name of the mailbox can be the user name or a place to put mail for someone with a specific function, like the postmaster. Mailboxes are in the /var/mail/username file, which can exist either on the user's local system or on a remote mail server. 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. Specifically, do not direct mail to a mail client that is mounting the /var/mail file system from a remote server. Mail for the user, in this case, should be addressed to the mail server and not to the client host name. NFS mounted file systems can cause problems with mail delivery and handling. Clients that NFS mount /var/mail go into "remote mode" and should arrange to have the server send and receive mail for them.

The /etc/mail/aliases file and name 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.

The following table shows some common naming conventions for special-purpose mailboxes.

Starting with version 8, the envelope sender for mail sent to a group alias is changed to the address expanded from the owner alias, if an owner alias exists. This change allows for any mail errors to be sent to the alias owner rather than being returned to the sender. What users will notice is that mail they send to an alias, when delivered, will look like it came from the alias owner. The following alias format will help with some of the problems associated with this change:

mygroup: :include:/pathname/mygroup.list
owner-mygroup: mygroup-request
mygroup-request: sandys, ignatz

In this example, the mygroup alias is the actual mail alias for the group; the owner-mygroup alias receives error messages; and the mygroup-request alias should be used for administrative requests. This structure means that in mail sent to the mygroup alias, the envelope sender changes to mygroup-request.

Mail Aliases

An alias is an alternate name. For electronic mail, you can use aliases to assign a mailbox location or to define mailing lists.

For large sites, the mail alias typically defines the location of a mailbox. 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 two people named Kevin Smith are in the same building, only one of them will get mail.

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

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

ignatz: 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

When creating mail lists that include users outside 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@mgmt.acme.com.

The email address of the sender is now automatically translated to a fully qualified domain name when mail goes outside 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. You can also create and administer mailing lists using the same alias files.

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

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 normally create or administer NIS or NIS+ alias files.

Hardware Components of a Mail Configuration

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

• A mail host

• At least one mail server

• Mail clients

When you want users to communicate with networks outside your domain, you must also add a fourth element, a mail gateway. The following sections describe each hardware component.

Mail Host

A mail host is the machine that you designate as the main mail machine on your network. It is the machine to which other systems at the site forward mail that they cannot deliver. You designate a system as a mail host in the hosts database by adding the word mailhost to the right of the IP address in the local /etc/hosts file or in the hosts file in the name service. 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 on the local area network that also has a modem for setting up PPP or UUCP links over telephone lines. Another good candidate is a system configured as a router from your network to the Internet global network. (See Chapter 21, Overview of PPP, Chapter 25, Overview of UUCP, and "Configuring Routers" for more information.) If none of the systems on your local network has a modem, designate one as the mail host.

Some sites use standalone machines that are not networked in a time-sharing configuration; that is, the standalone machine serves terminals attached to its serial ports. You can set up electronic mail for this configuration by treating the standalone system as the mail host of a one-system network.

Mail Server

A mailbox is a single file that contains email for a particular user. Mail is delivered to the system where the user's mailbox resides: the local machine or a remote server. A mail server is any system that maintains user mailboxes in its /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. After the mail is in the queue, a user can reboot or turn off the client 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. Good candidates for mail servers are systems that provide a home directory for users or that are backed up regularly.

If the mail server is not the user's local system, users in configurations using NFS software can mount the /var/mail directory by using the /etc/vfstab file (if they have root access) or by using the automounter. If NFS support is not available, the users can log in to the server to read their mail.

If users on your network send other types of mail, such as PostScript^TM files, audio files, or files from desktop publishing systems, you need to allocate more space on the mail server for mailboxes.

One advantage to establishing a mail server for all mailboxes is that it makes backups easy. Having mail spread over many systems makes it hard to do backups. The disadvantage of storing many mailboxes on one server is that the server can be a single point of failure for many users, but the advantages of providing good backups usually make the risk worthwhile.

Mail Client

A mail client is any system that receives mail on a mail server and does not have a local /var/mail directory. This is known as remote mode. Remote mode is enabled by default in /etc/mail/subsidiary.cf.

You must check that the mail client has the appropriate entry in the /etc/vfstab file and a mount point to mount the mailbox from the mail server. Also make sure that the alias for the client is directed to the mail server's host name, not to the client's.

Mail Gateway

The mail gateway is a machine that handles connections between networks running different communications protocols or communications between different networks using the same protocol. For example, a mail gateway might connect a TCP/IP network to a network running the Systems Network Architecture (SNA) protocol suite.

The simplest mail gateway to set up is one that connects two networks that use the same protocol or mailer. This system handles mail with an address for which sendmail cannot find a recipient in your domain. If a mail gateway exists, sendmail uses it for sending and receiving mail outside your domain.

You can set up a mail gateway between two networks using unmatched mailers, as shown in the next figure. To support this, you must customize the sendmail.cf file on the mail gateway system, which can be a difficult and time-consuming process.

Figure 35-1 Gateway Between Different Communications Protocols

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

If you have a machine providing connections to the Internet, you can configure that machine as the mail gateway. Carefully consider your site's security needs before you configure a mail gateway. You might need to create a firewall gateway between your corporate network and the outside world, and set that up as the mail gateway.

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.

How Mail Addressing Works

The path a mail message follows during delivery depends on the setup of the client system and the topology of the mail domain. Each additional level of mail hosts or mail domains can add one more round of alias resolution, but the routing process is basically the same on most hosts.

You can set up a client system to receive mail locally or select a remote to receive the mail for the client system. Receiving mail locally is known as running sendmail in local mode. Local is the default mode for all mail servers and some clients. If the client is mounting /var/mail from a server, the client is running sendmail in remote mode.

Assuming that you are using the default rule set in the sendmail.cf file, the following examples show the route an email message takes.

On a mail client in remote mode, a mail message will go through the following routing process:

1. Expand the mail alias, if possible, and restart the local routing process.

   The mail address is expanded by looking up the mail alias in the name space, according to the entry in /etc/nsswitch.conf, and substituting the new value, if one is found. This new alias is then checked again.

2. If the address cannot be expanded, forward it to the mail server.

   If the mail address cannot be expanded, there could be a problem with the address or the address is not local. In both cases, the mail server needs to resolve the problem.

3. If the expanded alias loops back to the original address, forward the mail to the mail server.

   The process keeps a history of all of the lookups and if the original alias is generated again, the mail is forwarded to the mail server to resolve.

On the mail server or a mail client in local mode, a mail message goes through the following routing process:

1. Expand the mail alias, if possible, and restart the local routing process.

   The mail address is expanded by looking up the mail alias in the name space and substituting the new value, if one is found. This new alias is then checked again.

2. If the mail is local, deliver it to /usr/lib/mail.local.

   The mail will be delivered to a local mailbox.

3. If the mail address includes a host in this mail domain, deliver the mail to that host.

4. If the address does not include a host in this domain, forward the mail to the mail host.

   The mail host uses the same routing process as the mail server, but the mail host can receive mail addressed to the domain name as well as to the host name.

How sendmail Interacts With a Name Service

Mail domain is a concept used by the standard sendmail.cf file to determine whether mail should be delivered directly or through the mail host. Intra-domain mail is delivered through direct SMTP connection, while inter-domain mail is forwarded to a mail host.

In a secure network, only a few selected hosts are authorized to generate packets targeted to external destinations. Even if a host has the IP address of the remote host external to the mail domain, this does not guarantee that an SMTP connection can be established. The standard sendmail.cf assumes the following:

• The current host is not authorized to send packets directly to a host outside the mail domain.

• The mail host is capable of forwarding the mail to an authorized host that can transmit packets directly to an external host. (In fact, the mail host can itself be an authorized host.)

Given these assumptions, the mail host is responsible for delivering or forwarding inter-domain mail.

Setting Up sendmail Requirements for Name Services

sendmail imposes various requirements on name services. This section explains these requirements and how to satisfy them. For more information, refer to the in.named(1M), nis+(1), nisaddent(1M), and nsswitch.conf(4) man pages.

Establishing the Mail Domain Name With a Name Service

The mail domain name must be a suffix of the name service domain. For example, if the domain name of the name service is A.B.C.D, the mail domain name could be one of the following:

• A.B.C.D

• B.C.D

• C.D

• D

When first established, the mail domain name is often identical to the name service domain. As the network grows larger, the name service domain can be divided into smaller pieces to make the name service more manageable. However, the mail domain often remains undivided to provide consistent aliasing.

Host Name Space Data

The host table or map in the name service must be set up to support three types of gethostbyname() queries:

• mailhost - Some name service configurations satisfy this requirement automatically.

• Full host name (for example, smith.admin.acme.com) - Many name service configurations satisfy this requirement.

• Short host name (for example, smith) - sendmail must connect to the mail host to forward external mail. To determine if a mail address is within the current mail domain, gethostbyname() is invoked with the full host name. If the entry is found, the address is considered internal.

  NIS, NIS+, and DNS all support gethostbyname() with a short host name as an argument, so this requirement is automatically satisfied.

Two additional rules about the host name space need to be followed to establish the sendmail services within a name space properly.

1. gethostbyname() with full and short host name should yield consistent results. For example, gethostbyname(smith.admin.acme.com) should return the same result as gethostbyname(smith), as long as both functions are called from the mail domain admin.acme.com.

2. For all name service domains under a common mail domain, gethostbyname() with a short host name should yield the same result. For example, given the mail domain smith.admin.acme.com, gethostbyname(smith) should return the same result calling from either domain ebb.admin.acme.com or esg.admin.acme.com. The mail domain name is usually shorter than the name service domain, giving this requirement special implications for various name services.

Configuration Issues With NIS and sendmail

This list includes all the configuration issues that you must resolve before using sendmail, when using NIS as your only name service.

Mail domain name - If you are setting up NIS as the primary name service, sendmail automatically strips the first component of the NIS domain name and uses the result as the mail domain name. For example, ebs.admin.acme.com becomes admin.acme.com.




Mail host host name - You must have a mailhost entry in the NIS host map.




Full host names - The normal NIS setup does not "understand" the full host name. Rather than trying to make NIS understand the full host name, turn off this requirement from the sendmail side by editing the sendmail.cf file and replacing all occurrences of %l with %y. This turns off sendmail's inter-domain mail detection. As long as the target host can be resolved to an IP address, a direct SMTP delivery is attempted. Make sure that your NIS host map does not contain any host entry that is external to the current mail domain. Otherwise, you need to further customize the sendmail.cf file.




Matching full and short host names - Follow the previous instructions on how to turn off gethostbyname() for a full host name.




Multiple NIS domains in one mail domain - All NIS host maps under a common mail domain should have the same set of host entries. For example, the host map in the ebs.admin.acme.com domain should be the same as the host map in the esg.admin.acme.com. Otherwise, one address might work in one NIS domain but fail in the other NIS domain.

Configuration Issues With NIS and DNS While Using sendmail

This list includes all the configuration issues that you must resolve before using sendmail, when using NIS with DNS as your name service.

Mail domain name - If you are setting up NIS as the primary name service, sendmail automatically strips the first component of the NIS domain name and uses the result as the mail domain name, for example, ebs.admin.acme.com becomes admin.acme.com.




Mailhost host name - When the DNS forwarding feature is turned on, queries that NIS cannot resolve are forwarded to DNS, so there is no need for a mailhost entry in the NIS host map.




Full host names - Although NIS does not "understand" full host names, DNS does. This requirement is satisfied when you follow the regular procedure for setting up NIS and DNS.




Matching full and short host names - For every host entry in the NIS host table, you must have a corresponding host entry in DNS.




Multiple NIS domains in one mail domain - All NIS host maps under a common mail domain should have the same set of host entries. For example, the host map in the ebs.admin.acme.com domain should be the same as the host map in the esg.admin.acme.com. Otherwise, one address might work in one NIS domain but fail in the other NIS domain.

Configuration Issues With NIS+ and sendmail

This list includes all the configuration issues that you must resolve before using sendmail when using NIS+ as your only name service.

Mail domain name - If you are setting up NIS+ as your primary name service, sendmail can look up the mail domain from the NIS+ sendmailvars table, a two-column NIS+ table with one key column and one value column. To set up your mail domain, you must add one entry to this table. This entry should have the key column set to the literal string maildomain and the value column set to your mail domain name (for example, admin.acme.com). Although NIS+ allows any string in the sendmailvars table, the suffix rule still applies for the mail system to work correctly. You can use nistbladm to add the maildomain entry to the sendmailvars table. For example:

nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain>

Notice that this mail domain is a suffix of the NIS+ domain.



Mailhost host name - You must have a mailhost entry in the NIS+ hosts table.




Full host names - NIS+ "understands" the full host name. Following the regular NIS+ setup procedure satisfies this requirement.




Matching full and short host names - To satisfy this requirement, you can duplicate the entries in the host table, or you can enter all host entries in the user name service domains into a master host table at mail domain level.




Multiple NIS domains in one mail domain - To satisfy this requirement, you can duplicate the entries in all the host tables, or you can type all host entries in the user name service domains into a master host table at mail domain level. Because you are merging (logical or physical) multiple host tables into one host table, the same host name cannot be reused in the multiple name service domain sharing a common mail domain.

Configuration Issues with NIS+ and DNS while Using sendmail

This list includes all the configuration issues that you must resolve before using sendmail when using NIS+ with DNS as your name service.

mail domain name -- If you are setting up NIS+ as your primary name service, sendmail can look up the mail domain from the NIS+ sendmailvars table, a two-column NIS+ table with one key column and one value column. To set up your mail domain, you must add one entry to this table. This entry should have the key column set to the literal string maildomain and the value column set to the your mail domain name (for example, admin.acme.com). Although NIS+ allows any string in the sendmailvars table, the suffix rule still applies for the mail system to work correctly. You can use nistbladm to add the maildomail entry to the sendmailvars table. For example:

nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain>

Notice that this mail domain is a suffix of the NIS+ domain.




mailhost host name -- If your network uses both NIS+ and DNS as the source for the host database, you can put the mailhost entry in either the NIS+ or DNS host table. Make sure that your users list NIS+ and DNS as the source for the host database in the /etc/nsswitch.conf file.




full host names -- Both NIS+ and DNS "understand" full host names. Following the regular NIS+ and DNS setup procedures satisfies this requirement.




matching full and short host names -- For every host entry in the NIS+ host table, you must have a corresponding host entry in DNS.




multiple NIS domains in one mail domain -- To satisfy this requirement, you can duplicate the entries in all the host tables, or you can type all host entries in the user name service domains into a master host table at the mail domain level.