Chapter 26 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 24, Mail Services (Overview) provided an introduction to the components of mail services and a description of a typical mail service configuration. Chapter 25, Mail Services (Tasks) explained how to set up and administer an electronic mail system. This chapter provides information on the following topics.

• Solaris Version of sendmail

• Software and Hardware Components of Mail Services

• Mail Service Programs and Files

• Mail Addresses and Mail Routing

• Interactions of sendmail With Name Services

See Chapter 27, What's New With Mail Services (Reference) for a description of the new features that are included in version 8.12 of sendmail, the version that is in this Solaris 9 release. You can also read about changes to mail.local, mailstats, makemap, and about a new maintenance utility, editmap. For details that are not covered in these chapters, see the man pages for sendmail(1M), mail.local(1M), mailstats(1), makemap(1M), and editmap(1M).

Solaris Version of sendmail

This section, which includes the following topics, describes some of the differences in the Solaris version of sendmail as compared to the generic Berkeley version.

• Flags Used and Not Used to Compile sendmail

• Alternative sendmail Commands

• Versions of the Configuration File

Flags Used and Not Used to Compile sendmail

The following tables list the flags that are used when compiling the version of sendmail that is delivered with the Solaris 9 release. If your configuration requires other flags, you need to download the source and recompile the binary. You can find information about this process at http://www.sendmail.org.

The following table lists generic flags that are not used to compile the version of sendmail that is delivered with the Solaris 9 release.

To see a list of the flags that are used to compile sendmail, use the following command.

% /usr/lib/sendmail -bt -d0.10 < /dev/null

The preceding command does not list the flags that are specific to Sun.

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 by using sendmail.

Versions of the Configuration File

The Solaris 9 version of sendmail includes a configuration option that enables you to define the version of the sendmail.cf file. This option enables older configuration files to be used with the current version of sendmail. You can set the version level to values between 0 and 10. You can also define the vendor. Either Berkeley or Sun are valid vendor options. 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.

You are urged not to use V1/Sun. For more information, refer to http://www.sendmail.org/vendor/sun/differences.html#4.

For task information, refer to Building the sendmail.cf Configuration File (Task) in Chapter 25, Mail Services (Tasks).

Software and Hardware Components of Mail Services

This section describes the software and hardware components of a mail system.

• Software Components

• Hardware Components

Software Components

Each mail service includes at least one of each of the following software components.

• Mail User Agent

• Mail Transfer Agent

• Local Delivery Agent

This section also describes these software components.

• Mailers

• Mail Addresses

• Mailbox Files

• Mail Aliases

Mail User Agent

The mail user agent is the program that acts as the interface between the user and mail transfer agent. The sendmail program is a mail transfer agent. The Solaris operating environment supplies the following mail user agents.

• /usr/bin/mail

• /usr/bin/mailx

• $OPENWINHOME/bin/mailtool

• /usr/dt/bin/dtmail

Mail Transfer Agent

The mail transfer agent is responsible for the routing of mail messages and the resolution of mail addresses. This agent 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

Local Delivery Agent

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

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

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

Chapter 27, What's New With Mail Services (Reference) provides information on these related topics.

• New Delivery Agent Flags

• New Equates for Delivery Agents

• Changes to mail.local

Mailers

Mailer is a sendmail-specific term. A mailer is used by sendmail to identify a specific instance of a customized local delivery agent or a customized mail transfer agent. You need to specify at least one mailer in your sendmail.cf file. For task information, refer to Building the sendmail.cf Configuration File (Task) in Chapter 25, Mail Services (Tasks). This section provides a brief description of two types of mailers.

• Simple Mail Transfer Protocol (SMTP) Mailers

• UNIX-to-UNIX Copy Program (UUCP) Mailers

For additional information about mailers, see http://www.sendmail.org/m4/readme.html or /usr/lib/mail/README.

Simple Mail Transfer Protocol (SMTP) Mailers

SMTP is the standard mail protocol that is used on the Internet. This protocol defines these mailers.

• smtp provides regular (historic-style) SMTP transfers to other servers

• esmtp provides extended SMTP transfers to other servers

• smtp8 provides SMTP transfers to other servers without converting 8–bit data to MIME

• dsmtp provides on-demand delivery by using the F=% mailer flag. Refer to Changes to the MAILER() Declaration and New Delivery Agent Flags in Chapter 27, What's New With Mail Services (Reference).

UNIX-to-UNIX Copy Program (UUCP) Mailers

If possible, avoid using UUCP. For an explanation, refer to http://www.sendmail.org/m4/uucp.html or do a search in /usr/lib/mail/README on this string: USING UUCP MAILERS.

UUCP defines these mailers.

uucp-old

Names in the $=U class are sent to uucp-old. uucp is the obsolete name for this mailer. The uucp-old mailer uses an exclamation-point address in the headers.

uucp-new

Names in the $=Y class are sent to uucp-new. Use this mailer when you know that the receiving UUCP mailer can manage multiple recipients in one transfer. suucp is the obsolete name for this mailer. The uucp-new mailer also uses an exclamation-point address in the headers.

If MAILER(smtp) is also specified in your configuration, two more mailers are defined.

uucp-dom

This mailer uses domain-style addresses and, basically, applies the SMTP rewriting rules.

uucp-uudom

Names in the $=Z class are sent to uucp-uudom. uucp-uudom and uucp-dom use the same header address format, domain-style addresses.

Because the smtp mailer modifies the UUCP mailer, always put MAILER(smtp) before MAILER(uucp) in your .mc file.

Mail Addresses

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. The login names uniquely identify the users. Complexity is introduced if you are administering a mail system that has more than one system with mailboxes or has one or more domains. Additional complexity can be generated if you have a UUCP (or other) mail connection to the outside world. The information in the following sections can help you understand the parts and complexities of a mail address.

• Domains and Subdomains

• Name Service Domain Name and Mail Domain Name

• Typical Format for Mail Addresses

• Route–Independent Mail Addresses

Domains and Subdomains

Email addressing uses domains. A domain is a directory structure for network address naming. A domain can have one or more subdomains. The domain and subdomains of an address can be compared to the hierarchy of a file system. Just as a subdirectory is considered to be inside the directory above it, each subdomain in a mail address is considered to be inside the location to its right.

The following table shows some top-level domains.

Domains are case insensitive. You can use uppercase, lowercase, or mixed-case letters in the domain part of an address without making any difference.

For more information about domains, refer to “Introduction to DNS (Overview)” in System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP).

Name Service Domain Name and Mail Domain Name

When you are working with name service domain names and mail domain names, remember the following.

• By default, the sendmail program strips the first component from the NIS or NIS+ domain name to form the mail domain name. For example, if an NIS+ domain name were bldg5.example.com, its mail domain name would be example.com.

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

• The DNS domain name and the mail domain name must be identical.

For more information, refer to Interactions of sendmail With Name Services.

Typical Format for Mail Addresses

Typically, a mail address has the following format. For further details, refer to Route–Independent Mail Addresses.

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 the following.

• 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. For information about mailers, refer to Mailers.

The part of the address to the right of the @ sign shows the domain levels, which is where the local address resides. A dot separates each subdomain. The domain part of the address can be an organization, a physical area, or a geographic region. Furthermore, the order of domain information is hierarchical—the more local the subdomain, the closer it is to the @ sign.

Route–Independent Mail Addresses

Mail addresses can be route independent. Route-independent addressing requires the sender of an email message to specify the name of the recipient and the final destination. A high-speed network, such as the Internet, uses route-independent addresses. Route-independent addresses can have this format.

user@host.domain

Route-independent addresses for UUCP connections can have this address format.

host.domain!user

The increased popularity of the domain-hierarchical naming scheme for computers is making route-independent addresses more common. Actually, 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 and then reading the domain hierarchy from the right (the highest level) to the left (the most specific part of the address to the right of the @ sign).

Mailbox Files

A mailbox is a file that is the final destination for email messages. The name of the mailbox can be the user name or the identity of a specific function, such as 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 instance, 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 instance, 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.

The /etc/mail/aliases file and name services such as 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 sendmail version 8, the envelope sender for mail that is sent to a group alias has been changed to the address that is expanded from the owner alias, if an owner alias exists. This change enables any mail errors to be sent to the alias owner, rather than being returned to the sender. With this change, users notice that mail that was sent to an alias looks as if it came from the alias owner, when delivered. The following alias format helps with some of the problems that are 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. 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 email, you can use aliases to assign a mailbox location or to define mailing lists. For a task map, refer to Administering Mail Alias Files (Task Map) in Chapter 25, Mail Services (Tasks). Also, you can refer to Mail Alias Files in this chapter.

For large sites, the mail alias typically defines the location of a mailbox. Providing a mail alias is like providing a room number as part of the address for an individual at a large corporation that occupies multiple rooms. If you do not provide the room number, the mail is delivered to a central address. Without a room number, extra effort is required to determine where within the building the mail is to be delivered, and the possibility of an error increases. For example, if two people who are named Kevin Smith are in the same building, only one of them might get mail. To correct the problem, each Kevin Smith should have a room number added to his address.

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 who is named ignatz on system mars, in domain example.com, create the alias ignatz@example instead of ignatz@mars. If user ignatz changes the name of his system but remains within the example domain, you do not need to update alias files to reflect the change in system name.

When you create 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 is in the domain planets, could have this entry in the NIS+ aliases table.

fred: fred@planets

When you create 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 example.com, create the alias as smallberries@example.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.

The following list describes methods for creating and administering mail alias files.

• You can 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 that use 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 anyone can use. Users cannot normally create or administer NIS or NIS+ alias files.

Hardware Components

You can provide the three required elements of mail configuration in the same system or have separate systems provide these elements.

• Mail Host

• Mail Server

• Mail Client

When users are to communicate with networks outside your domain, you must also add a fourth element, a mail gateway. For more information, refer to 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. A mail host 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. For detailed task information, refer to How to Set Up a Mail Host in Chapter 25, Mail Services (Tasks).

A good candidate for a 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 that is configured as a router from your network to the Internet global network. For more information, refer to Chapter 29, Solaris PPP 4.0 (Overview), Chapter 38, Overview of UUCP, and “Configuring Routers” in System Administration Guide: IP Services. 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 that are attached to its serial ports. You can set up electronic mail for this configuration by designating the standalone system as the mail host of a one-system network. Overview of the Hardware Components in Chapter 24, Mail Services (Overview) provides a figure that shows a typical email configuration.

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, which can be on a local machine or a remote server. A mail server is any system that maintains user mailboxes in its /var/mail directory. For task information, refer to How to Set Up a Mail Server in Chapter 25, Mail Services (Tasks).

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 systems that are backed up regularly.

If the mail server is not the user's local system, users in configurations that use 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, users can log in to the server to read their mail.

If users on your network send other types of mail, such as 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 simplifies backups. Backups can be difficult to do when mail is spread over many systems. The disadvantage of storing many mailboxes on one server is that the server can be a single point of failure for many users. However, 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 type of configuration 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, ensure that the alias for the client is directed to the mail server's host name, not to the client's name. For task information, refer to How to Set Up a Mail Client in Chapter 25, Mail Services (Tasks).

Mail Gateway

The mail gateway is a machine that handles connections between networks that run different communications protocols or communications between different networks that use the same protocol. For example, a mail gateway might connect a TCP/IP network to a network that runs 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 that use unmatched mailers, as shown in the next figure. To support this configuration, you must customize the sendmail.cf file on the mail gateway system, which can be a difficult and time-consuming process.

Figure 26–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 conform to your situation.

If you have a machine that provides 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 up that gateway as the mail gateway. For task information, refer to How to Set Up a Mail Gateway in Chapter 25, Mail Services (Tasks).

Mail Service Programs and Files

Mail services include many programs and daemons that interact with each other. This section introduces the files, programs, terms, and concepts that are related to administering electronic mail.

• Contents of the /usr/bin Directory

• Contents of the /etc/mail Directory

• Contents of the /usr/lib Directory

• Other Files Used for Mail Services

• Interactions of Mail Programs

• sendmail Program

• Mail Alias Files

• .forward Files

• /etc/default/sendmail File

Contents of the /usr/bin Directory

The following table shows the contents of the /usr/bin directory, which is used for mail services.

Contents of the /etc/mail Directory

The following table shows the contents of the /etc/mail directory.

Contents of the /usr/lib Directory

Table 26–9 shows the contents of the /usr/lib directory, which is used for mail services.

Contents of the /usr/lib/mail Directory

Within the /usr/lib directory is a subdirectory, mail, that contains all of the necessary files to build a sendmail.cf file. The contents of mail are shown in Table 26–10.

Other Files Used for Mail Services

Several other files and directories are used for mail services, as shown in Table 26–11.

Interactions of Mail Programs

Mail services are provided by a combination of the following programs, which interact as shown in the simplified illustration in Figure 26–2.

Figure 26–2 Interactions of Mail Programs

For a more detailed illustration, refer to the figure in sendmail Features.

The following is a description of the interactions of mail programs.

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

2. The message is collected by the program that generated it and is passed to the sendmail daemon.

3. The sendmail daemon parses the addresses (divides them into identifiable segments) in the message. The daemon uses information from the configuration file, /etc/mail/sendmail.cf, to determine network name syntax, aliases, forwarding information, and network topology. By using this information, sendmail determines the route a message must follow to get to a recipient.

4. The sendmail daemon passes the message to the appropriate system.

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

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

sendmail Program

The following list describes some of the capabilities of the sendmail program.

• sendmail can use different types of communications protocols, such as TCP/IP and UUCP.

• sendmail implements an SMTP server, message queueing, and mailing lists.

• sendmail controls name interpretation by using a pattern-matching system that can work with the following naming conventions.

  • Domain-based naming convention. The domain technique separates the issue of physical versus logical naming. For more information on domains, refer to Mail Addresses.

  • Improvised techniques, such as providing network names that appear local to hosts on other networks.

  • Arbitrary (older) naming syntaxes.

  • Disparate naming schemes.

The Solaris operating environment uses the sendmail program as a mail router. The following list describes some of its functions.

• sendmail is responsible for receiving and delivering email messages.

• sendmail is an interface between mail–reading programs such as mail, mailx, and mailtool, and mail–transport programs such as uucp.

• sendmail controls email messages that users send.

  • By evaluating the recipients' addresses

  • By choosing an appropriate delivery program

  • By rewriting the addresses in a format that the delivery agent can handle

  • By reformatting the mail headers as required

  • By finally passing the transformed message to the mail program for delivery

For more information about the sendmail program, refer to the following topics.

• sendmail and Its Rerouting Mechanisms

• sendmail Features

• sendmail Configuration File

sendmail and Its Rerouting Mechanisms

The sendmail program supports three mechanisms for mail rerouting. The mechanism you choose depends on the type of change that is involved.

• A server change

• A domain-wide change

• A change for one user

Additionally, the rerouting mechanism you choose can affect the level of administration that is required. Consider the following options.

1. One rerouting mechanism is aliasing.

   Aliasing can map names to addresses on a server-wide basis or a name service-wide basis, depending on the type of file that you use.

   Consider the following advantages and disadvantages for name service aliasing.

   • The use of a name service (such as NIS or NIS+) alias file permits mail rerouting changes to be administered from a single source. However, name service aliasing can create lag time when the rerouting change is propagated.

   • Name service administration is usually restricted to a select group of system administrators. A normal user would not administer this file.

   Consider the following advantages and disadvantages for using a server alias file.

   • By using a server alias file, rerouting can be managed by anyone who can become root on the designated server.

   • Server aliasing should create little or no lag time when the rerouting change is propagated.

   • The change only affects the local server, which might be acceptable if most of the mail is sent to one server. However, if you need to propagate this change to many mail servers, use a name service.

   • A normal user would not administer this change.

   For more information, refer to Mail Alias Files in this chapter. For a task map, refer to Administering Mail Alias Files (Task Map) in Chapter 25, Mail Services (Tasks).

2. The next mechanism is forwarding.

   This mechanism permits users to administer mail rerouting. Local users can reroute their incoming mail to the following.

   • Another mailbox

   • A different mailer

   • Another mail host

   This mechanism is supported through the use of .forward files. For more information about these files, refer to .forward Files in this chapter. For a task map, refer to Administering .forward Files (Task Map) in Chapter 25, Mail Services (Tasks).

3. The last rerouting mechanism is inclusion.

   This mechanism allows users to maintain alias lists, instead of requiring root access. To provide this feature, 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 necessary. For more information on inclusion, refer to /etc/mail/aliases File in this chapter. For a task map, refer to Administering Mail Alias Files (Task Map) in Chapter 25, Mail Services (Tasks).

Figure 26–3 shows how sendmail uses aliases. Programs that read mail, such as /usr/bin/mailx, can have aliases of their own, which are expanded before the message reaches sendmail. The aliases for sendmail can originate from a number of name service sources (local files, NIS or NIS+). The order of the lookup is determined by the nsswitch.conf file. Refer to the nsswitch.conf(4) man page.

Figure 26–3 How sendmail Uses Aliases

sendmail Features

The sendmail program provides the following features.

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

• sendmail uses existing software for delivery whenever possible.

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

• sendmail 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 mechanism without modifying the domain-wide alias file, typically located in the domain-wide aliases that are maintained by NIS or NIS+.

• Each user can specify a custom mailer to process incoming mail, which can provide functions such as returning a message that reads: “I am on vacation.” See the vacation(1) man page for more information.

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

Figure 26–4 shows how sendmail interacts with the other programs in the mail system.

Figure 26–4 Interaction of sendmail With Other Mail Programs

As shown in Figure 26–4, the user interacts with a mail-generating and mail-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, you can use sendmail as an Internet mail gateway. See Interactions of Mail Programs for a more detailed description of the process.

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 that is 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 three default configuration files in the /etc/mail directory.

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

2. A configuration file that is named subsidiary.cf, which is a duplicate copy of the default sendmail.cf file

3. A configuration file that is named submit.cf, which is used to run sendmail in mail submission program mode, instead of daemon mode. For more information, refer to New Configuration File, submit.cf.

The configuration file you use on a system depends on the role of the system 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 mail gateway, copy the main.cf file and rename it to sendmail.cf in the /etc/mail directory. Then reconfigure the sendmail configuration file to set the relay mailer and relay host parameters that are needed for your mail configuration. For task information, refer to Setting Up Mail Services (Task Map) or Building the sendmail.cf Configuration File (Task) in Chapter 25, Mail Services (Tasks).

The following list describes some configuration parameters you can change, depending on the requirements of your site.

• Time values, which specify the following information.

  • Read timeouts. Refer to Changes to the Timeout Option.

  • Length of time a message remains undelivered in the queue before it is returned to the sender. Refer to New Queue Features. For a task map, refer to Administering the Queue Directories (Task Map).

• Delivery modes, which specify how quickly mail is delivered.

• Load limits, which increase efficiency during busy 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, which specifies the kinds of problems that are logged.

Mail Alias Files

You can use any of the following files, maps, or tables to maintain aliases.

• .mailrc Aliases

• /etc/mail/aliases File

• NIS aliases Map

• NIS+ mail_aliases Table

Your method of maintaining aliases depends on who uses the alias and who needs to be able to change the alias. Each type of alias has unique format requirements.

If you are looking for task information, refer to Administering Mail Alias Files (Task Map) in Chapter 25, Mail Services (Tasks).

.mailrc Aliases

Aliases that are listed in a .mailrc file are accessible only by the user who owns the file. This restriction enables 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 ...

aliasname is the name that the user uses 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 service, mail is routed to the wrong person when people try to reply to mail that is generated by this user. The only workaround is to use any of the other aliasing mechanisms.

/etc/mail/aliases File

Any alias that is 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 ...

aliasname is the name that the user uses 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, you need to run the newaliases program to recompile the database and make the aliases available in binary form to the sendmail program. For task information, refer to How to Set Up a Local Mail Alias File in Chapter 25, Mail Services (Tasks). Otherwise, you can use the AdminTool's Database Manager to administer the mail aliases that are stored in the 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 the following entry in the /etc/mail/aliases file.

ignatz: ignatz@saturn

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

Normally, only the root user can edit this file. However, when you use the Administration Tool, all users in group 14, which is the sysadmin group, can change the local file. Another option is to create the following entry.

aliasname: :include:/path/aliasfile

aliasname is the name that the user uses when sending mail, and /path/aliasfile is the full path to the file that contains 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 that is sent to aliasname in filename.

aliasname: /home/backup/filename

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

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

For a task map, refer to Administering Mail Alias Files (Task Map) in Chapter 25, Mail Services (Tasks).

NIS aliases Map

All users in a local domain can use the entries that are in the NIS aliases map, because the sendmail program can use the NIS aliases map instead of the local /etc/mail/aliases files to determine mailing addresses. For more information, refer to the nsswitch.conf(4) man page.

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

aliasname: value,value,value ...

aliasname is the name that the user uses 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 such aliases can be useful if the aliases point to another alias file, as in the following syntax example.

aliasname: aliasname@host

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

For task information, refer to How to Set Up an NIS mail.aliases Map in Chapter 25, Mail Services (Tasks).

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. Refer to 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 26–12 describes the four columns that are in an NIS+ mail_aliases table.

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. To use the aliasadm command, you must be a member of the NIS+ group that owns the aliases table. For task information, refer to How to Manage Alias Entries in an NIS+ mail_aliases Table in Chapter 25, Mail Services (Tasks). Alternately, you can use the AdminTool's Database Manager to administer the 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.

.forward Files

Users can create a .forward file in their home directories that sendmail, along with other programs, can use to redirect mail or send mail. Refer to the following topics.

• Situations to Avoid

• Controls for .forward files

• .forward.hostname File

• .forward+detail File

For a task map, refer to Administering .forward Files (Task Map) in Chapter 25, Mail Services (Tasks).

Situations to Avoid

The following list describes some situations that you can avoid or easily fix.

• If mail is not being delivered to the expected address, check the user's .forward file. The user might have put the .forward file in the home directory of host1, which forwards mail to user@host2. When the mail arrives at host2, sendmail checks for user in the NIS or NIS+ aliases and sends the message back to user@host1, which results in a loop and more bounced mail.

• To avoid security problems, never put .forward files in the root and bin accounts. If necessary, forward the mail by using the aliases file instead.

Controls for .forward files

For the .forward files to be an effective part of mail delivery, ensure that the following controls (mostly permissions settings) are correctly applied.

• The .forward file must be writable only by the owner of the file. This restriction prevents other users from breaking security.

• The paths that lead to the home directory must be owned and writable by root only. For example, if a .forward file is in /export/home/terry, /export and /export/home must be owned and writable by root only.

• The actual home directory should be writable only by the user.

• The .forward file cannot be a symbolic link, and it cannot have more than one hard link.

.forward.hostname File

You can create a .forward.hostname file to redirect mail that is sent to a specific host. For example, if a user's alias has changed from sandy@phoenix.example.com to sandy@example.com, place a .forward.phoenix file in the home directory for sandy.

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

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

Sandy

In this example, mail can be forwarded to the correct place while the sender is notified of the alias change. Because the vacation program permits 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.

.forward+detail File

Another extension to the forwarding mechanism is the .forward+detail file. The detail string can be any sequence of characters except operator characters. The operator characters are .:%&!^[]+. By using this type of file, you can determine if someone else is using your email address without your knowledge. For instance, if a user tells someone to use the email address sandy+test1@example.com, the user would be able to identify any future mail that was delivered to this alias. By default, any mail that is sent to the sandy+test1@example.com alias is checked against the alias and the .forward+detail files. If no matches are made, the mail falls back to delivery to sandy@example.com, but the user is able to see a change in the To: mail header.

/etc/default/sendmail File

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

CLIENTOPTIONS=“string”

Selects additional options to be used with the client daemon, which looks in the client-only queue (/var/spool/clientmqueue) and acts as a client queue runner. No syntax checking is done, so be careful when making changes to this variable.

CLIENTQUEUEINTERVAL=#

Similar to the QUEUEINTERVAL option, CLIENTQUEUEINTERVAL sets the time interval for mail queue runs. However, the CLIENTQUEUEINTERVAL option controls the functions of the client daemon, instead of the master daemon. Typically, the master daemon is able to deliver all messages to the SMTP port. However, if the message load is too high or the master daemon is not running, then messages go into the client-only queue, /var/spool/clientmqueue. The client daemon, which checks in the client-only queue, then acts as a client queue processor.

ETRN_HOSTS=“string”

Enables an SMTP client and server to interact immediately without waiting for the periodic queue run intervals. The server can immediately deliver the portion of its queue that goes to the specified hosts. For more information, refer to the etrn(1M) man page.

MODE=-bd

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

OPTIONS=string

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

QUEUEINTERVAL=#

Sets the interval for mail queue runs on the master daemon. # can be a positive integer that is 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.

QUEUEOPTIONS=p

Enables one persistent queue runner that sleeps between queue run intervals, instead of a new queue runner for each queue run interval. You can set this option to p, which is the only setting available. Otherwise, this option is not set.

Mail Addresses and Mail Routing

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 another alias resolution, but the routing process is basically the same on most hosts.

You can set up a client system to receive mail locally. Receiving mail locally is known as running sendmail in local mode. Local mode is the default for all mail servers and some clients. On a mail server or a mail client in local mode, a mail message is routed the following way.

The following example assumes that you are using the default rule set in the sendmail.cf file.

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

   The mail address is expanded by checking for the mail alias in the name service 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 is 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 that is addressed to the domain name as well as to the host name.

Interactions of sendmail With Name Services

This section describes domain names as they apply to sendmail and name services, as well as the rules for effective use of name services, and the specific interactions of sendmail with name services. For details, refer to the following topics.

• sendmail.cf and Mail Domains

• sendmail and Name Services

• Interactions of NIS and sendmail

• Interactions of sendmail With NIS and DNS

• Interactions of NIS+ and sendmail

• Interactions of sendmail With NIS+ and DNS

If you are looking for related task information, refer to How to Use DNS With sendmail or Administering Mail Alias Files (Task Map) in Chapter 25, Mail Services (Tasks).

sendmail.cf and Mail Domains

The standard sendmail.cf file uses mail domains to determine whether mail is delivered directly or through a mail host. Intradomain mail is delivered through a direct SMTP connection, while interdomain mail is forwarded to a mail host.

In a secure network, only a few selected hosts are authorized to generate packets that are targeted to external destinations. Even if a host has the IP address of the remote host that is external to the mail domain, the establishment of an SMTP connection is not guaranteed. 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. Actually, the mail host can itself be an authorized host.

With these assumptions, the mail host is responsible for delivering or forwarding interdomain mail.

sendmail and Name Services

sendmail imposes various requirements on name services. To improve your understanding of these requirements, this section first describes the relationship of mail domains to name service domains. Then the section describes the various requirements. Refer to the following.

• Mail Domains and Name Service Domains

• Host Name Service Data

• Man pages for in.named(1M), nis+(1), nisaddent(1M), and nsswitch.conf(4)

Mail Domains and Name Service Domains

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, 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 Service Data

This section describes the requirements that sendmail imposes on name services.

A host table or map in a 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 in order 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 support gethostbyname() with a short host name as an argument, so this requirement is automatically satisfied.

Two additional rules about the host-name service need to be followed to establish efficient sendmail services within a name service.

• gethostbyname() with full host-name argument and short host-name argument 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.

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

For more information about the gethostbyname() function, refer to the gethostbyname(3NSL) man page.

Interactions of NIS and sendmail

The following list describes the interactions of sendmail and NIS and provides some guidance.

• 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 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 change turns off sendmail's interdomain mail detection. If the target host can be resolved to an IP address, a direct SMTP delivery is attempted. Ensure 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.

For task information, refer to Administering Mail Alias Files (Task Map) in Chapter 25, Mail Services (Tasks).

Interactions of sendmail With NIS and DNS

The following list describes the interactions of sendmail with NIS and DNS and provides some guidance.

• 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 name – When the DNS forwarding feature is turned on, queries that NIS cannot resolve are forwarded to DNS, so you do not need a mailhost entry in the NIS host map.

• Full host names – Although NIS does not “understand” full host names, DNS does understand. 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 domain. Otherwise, one address might work in one NIS domain, but fail in the other NIS domain.

For task information, refer to How to Use DNS With sendmail and Administering Mail Alias Files (Task Map) in Chapter 25, Mail Services (Tasks).

Interactions of NIS+ and sendmail

The following list describes the interactions of sendmail with NIS+ and provides some guidance.

• Mail domain name – If you are setting up NIS+ as your primary name service, sendmail can check 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. Notice in the following example that the mail domain is a suffix of the NIS+ domain.

  nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<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. In effect, you are merging (logical or physical) multiple host tables into one host table. Therefore, the same host name cannot be reused in the multiple name service domain that shares a common mail domain.

For task information, refer to Administering Mail Alias Files (Task Map) in Chapter 25, Mail Services (Tasks).

Interactions of sendmail With NIS+ and DNS

The following list describes the interactions of sendmail with NIS+ and DNS and provides some guidance.

• Mail domain name — If you are setting up NIS+ as your primary name service, sendmail can check 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 maildomain entry to the sendmailvars table. Notice in the following example that the mail domain is a suffix of the NIS+ domain.

  nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<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. Ensure that your users include 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.

For task information, refer to Administering Mail Alias Files (Task Map) and How to Use DNS With sendmail in Chapter 25, Mail Services (Tasks).