Managing sendmail Services in Oracle® Solaris 11.2

Exit Print View

Updated: July 2014
 
 

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 queuing, 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 from logical naming. For more information about 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 Oracle Solaris operating system 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 to a local delivery agent, such as mail.local or procmail.

  • sendmail is a mail transfer agent that accepts messages from user agents, such as mailx and Mozilla Mail, and routes the messages through the Internet to their destination.

  • sendmail controls email messages that users send in the following ways:

    • 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

The sendmail program supports three mechanisms for mail rerouting. The mechanism that 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 that 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 of name service aliasing.

    • The use of a name service 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 of 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 2, Administering Mail Services.

  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 2, Administering Mail Services.

  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 about inclusion, refer to /etc/mail/aliases File in this chapter. For a task map, refer to Administering Mail Alias Files (Task Map) in Chapter 2, Administering Mail Services.


    Note - 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, such as local files or NIS. The order of the lookup is determined by the svc:/system/name-service/switch service. Refer to the nsswitch.conf(4) man page.

sendmail Features

The sendmail program provides the following features.

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

  • sendmail uses existing software for delivery whenever possible. For example, the user interacts with a mail-generating and a mail-sending program. When 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. See Interactions of Mail Programs for a more detailed description of the process.

  • sendmail can be configured to handle complex environments, including multiple networks. 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. Additionally, 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.

  • Each user can specify a custom mailer to process incoming mail. The custom mailer 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.

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.

The Oracle Solaris operating system provides two default configuration files in the /etc/mail directory.

  1. sendmail.cf, a configuration file that is used to run sendmail in daemon mode.

  2. submit.cf, a configuration file that is used to run sendmail in mail-submission program mode, instead of daemon mode. For more information, refer to submit.cf Configuration File From Version 8.12 of sendmail.

    When setting up mail clients, mail servers, mail hosts, or mail gateways, consider the following:

  • 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, you need 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 Changing the sendmail Configuration in Chapter 2, Administering Mail Services. Note that with sendmail version 8.13, you no longer need the main.cf file.

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

  • Time values, which specify the following information.

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

  • Load limits, which increase efficiency during busy periods. These parameters prevent sendmail from 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.