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.