System Administration Guide: Network Services

Chapter 14 Mail Services (Reference)

The sendmail program is a mail transport agent. The program uses a configuration file to provide aliasing and forwarding, automatic routing to network gateways, and flexible configuration. The Solaris OS supplies standard configuration files that most sites can use. Chapter 12, Mail Services (Overview) provides an introduction to the components of mail services and a description of a typical mail service configuration. Chapter 13, Mail Services (Tasks) explains how to set up and administer an electronic mail system. This chapter provides information about the following topics.

For details that are not covered in these chapters, see the following man pages:

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

Starting in the Solaris 10 release, the following flags are used to compile sendmail. 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.

Table 14–1 General sendmail Flags

Flag 

Description 

SOLARIS=21000

Support for the Solaris 10 release. 

MILTER

Support for the Mail Filter API. In version 8.13 of sendmail, this flag is enabled by default. See MILTER, Mail Filter API for sendmail.

NETINET6

Support for IPv6. This flag has been moved from conf.h to Makefile.

Table 14–2 Maps and Database Types

Flag 

Description 

NDBM

Support for ndbm databases

NEWDB

Support for Berkeley DB databases 

USERDB

Support for the user database 

NIS

Support for nis databases

NISPLUS

Support for nisplus databases

LDAPMAP

Support for LDAP maps

MAP_REGEX

Support for regular expression maps 

Table 14–3 Solaris Flags

Flag 

Description 

SUN_EXTENSIONS

Support for Sun extensions that are included in sun_compat.o.

SUN_INIT_DOMAIN

For backward compatibility, support for the use of NIS domain names to fully qualify the local host name. For more information, look for vendor-specific information in http://www.sendmail.org.

SUN_SIMPLIFIED_LDAP

Support for a simplified LDAP API, which is specific to Sun. For more information, look for vendor-specific information in http://www.sendmail.org.

VENDOR_DEFAULT=VENDOR_SUN

Selects Sun as the default vendor. 

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

Table 14–4 Generic Flags Not Used in the Solaris Version of sendmail

Flag 

Description 

SASL

Simple Authentication and Security Layer (RFC 2554) 

STARTTLS

Transaction Level Security (RFC 2487) 

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

Note –

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


MILTER, Mail Filter API for sendmail

MILTER, sendmail's Mail Filter API, enables third-party programs to access mail messages as they are being processed to filter meta-information and content. You do not need to build the filter and configure sendmail to use it. This API is enabled by default in version 8.13 of sendmail.

For more details, see the following:

Alternative sendmail Commands

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

Table 14–5 Alternate sendmail Commands

Alternate Name 

In the Solaris Release? 

Options With sendmail

hoststat

No 

sendmail -bh

mailq

Yes 

sendmail -bp

newaliases

Yes 

sendmail -bi

purgestat

No 

sendmail -bH

smtpd

No 

sendmail -bd

Versions of the Configuration File

Starting in the Solaris 10 release, 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 is a valid vendor option. 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.

Table 14–6 Version Values for the Configuration File

Field 

Description 

V7/Sun

Setting that was used for version 8.8 of sendmail.

V8/Sun

Setting that was used for version 8.9 of sendmail. This setting was included in the Solaris 8 release.

V9/Sun

Setting that was used for versions 8.10 and 8.11 of sendmail.

V10/Sun

Setting that is used for version 8.12 and version 8.13 of sendmail. Version 8.12 is the default for the Solaris 9 release. Starting in the Solaris 10 release, version 8.13 is the default.


Note –

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 Changing the sendmail Configuration in Chapter 13, Mail Services (Tasks).

Software and Hardware Components of Mail Services

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

Software Components

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

This section also describes these software components.

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 system supplies the following mail user agents.

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 system is sendmail. The transfer agent performs these functions.

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

Changes From Version 8.12 of sendmail provides information on these related topics.

Mailers and sendmail

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 Changing the sendmail Configuration in Chapter 13, Mail Services (Tasks). This section provides a brief description of two types of mailers.

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

Simple Mail Transfer Protocol (SMTP) Mailers

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

UNIX-to-UNIX Copy Program (UUCP) Mailers

If possible, avoid using UUCP. For an explanation, refer to http://www.sendmail.org/m4/uucp_mailers.html or do a search in /etc/mail/cf/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.


Note –

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 that has one or more domains. Additional complexity can be generated if you have a UUCP (or other) mail connection to servers outside your network. The information in the following sections can help you understand the parts and complexities of a mail address.

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.

Table 14–7 Top-Level Domains

Domain 

Description 

com

Commercial sites 

edu

Educational sites 

gov

United States government installations 

mil

United States military installations 

net

Networking organizations 

org

Other nonprofit organizations 

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

Name Service Domain Name and Mail Domain Name

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

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.


Note –

The receiving mailer is responsible for determining what the local part of the address means. For information about mailers, refer to Mailers and sendmail.


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, so the more local the subdomain, the closer the subdomain 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 first read by searching for the @ sign. The domain hierarchy is then read 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, 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.

Table 14–8 Conventions for the Format of Mailbox Names

Format 

Description 

username

User names are frequently the same as mailbox names. 

Firstname.Lastname Firstname_Lastname Firstinitial.Lastname Firstinitial_Lastname

User names can be identified as full names with a dot (or an underscore) that separates the first and last names. Alternately, user names can be identified by a first initial with a dot (or an underscore) that separates the initial and the last name. 

postmaster

Users can address questions and report problems with the mail system to the postmaster mailbox. Each site and domain should have a postmaster mailbox.

MAILER-DAEMON

sendmail automatically routes any mail that is addressed to the MAILER-DAEMON to the postmaster.

aliasname-request

Names that end in -request are administrative addresses for distribution lists. This address should redirect mail to the person who maintains the distribution list.

owner-aliasname

Names that begin with owner- are administrative addresses for distribution lists. This address should redirect mail to the person who handles mail errors.

owner-owner

This alias is used when no owner-aliasname alias exists for errors to be returned to. This address should redirect mail to the person who handles mail errors. This address also should be defined on any system that maintains a large number of aliases.

local%domain

The percent sign (%) marks a local address that is expanded when the message arrives at its destination. Most mail systems interpret mailbox names with % characters as full mail addresses. The % is replaced with an @, and the mail is redirected accordingly. Although many people use the % convention, this convention is not a formal standard. This convention is referred to as the “percent hack.” This feature is often used to help debug mail problems.

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 the mail 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 13, 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. So, 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 who is 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.

Hardware Components

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

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 cannot be delivered. 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. Alternately, you can add the word mailhost similarly to the hosts file in the name service. For detailed task information, refer to How to Set Up a Mail Host in Chapter 13, Mail Services (Tasks).

A good candidate for a mail host is a system that is configured as a router from your network to the Internet global network. For more information, refer to Chapter 15, Solaris PPP 4.0 (Overview), Chapter 24, UUCP (Overview), and Configuring an IPv4 Router in System Administration Guide: IP Services. If no systems on your local network have a modem, designate a system as the mail host.

Some sites use standalone machines that are not networked in a time-sharing configuration. Specifically, 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 single-system network. Overview of the Hardware Components in Chapter 12, 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 13, Mail Services (Tasks).

The mail server routes all mail from a client. When a client sends mail, the mail server puts the mail 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. Otherwise, users can use 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.

By establishing a mail server for all mailboxes, you can simplify your process of doing 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 a user of mail services with a mailbox on a mail server. Additionally, the mail client has a mail alias in the /etc/mail/aliases file that points to the location of the mailbox. For task information, refer to How to Set Up a Mail Client in Chapter 13, 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 the mail gateway 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 the gateway to send and receive 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 14–1 Gateway Between Different Communications Protocols

Diagram shows two mail gateways that use unmatched mailers.

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 other networks, and set up that gateway as the mail gateway. For task information, refer to How to Set Up a Mail Gateway in Chapter 13, 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.

Enhancement for vacation Utility

Starting in the Solaris 10 release, the vacation utility has been enhanced to enable a user to specify which incoming messages receive autogenerated replies. With this enhancement the user can avoid sharing confidential or contact information with unknown people. Messages from spammers or unknown people would not receive a reply.

This enhancement works by matching an incoming sender's email address to a list of domains or email addresses in a .vacation.filter file. This file is created by the user and is in the user's home directory. If a domain or email address match is found, a reply is sent. If no match is found, no reply is sent.

The .vacation.filter might contain entries such as these:


company.com
mydomain.com
onefriend@hisisp.com
anotherfriend@herisp.com

Note that each line contains one domain or one email address. Each entry must be on a separate line. For a sender's email address to match with an email address entry, the match must be exact, except for case. Whether the letters in the sender's address are lowercase or uppercase is ignored. For a sender's email address to match with a domain entry, the sender's address must contain the listed domain. For example, both somebody@dept.company.com and someone@company.com would be a match for a domain entry of company.com.

For more information, see the vacation(1) man page.

Contents of the /usr/bin Directory

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

Name 

Type 

Description 

aliasadm

File 

A program to manipulate the NIS+ aliases map. 

mail

File 

A user agent. 

mailcompat

File 

A filter to store mail in SunOS 4.1 mailbox format. 

mailq

File 

A program that lists the content of the mail queue. 

mailstats

File 

A program that is used to read mail statistics that are stored in the /etc/mail/statistics file (if present).

mailx

File 

A user agent. 

mconnect

File 

A program that connects to the mailer for address verification and debugging. 

praliases

File 

A command to “uncompile” the alias database. Refer to the uncompile information that is provided in the man page for praliases(1).

rmail

Symbolic Link 

A symbolic link to /usr/bin/mail. Command that is often used to permit only the sending of mail.

vacation

File 

A command to set up an automatic reply to mail. 

Contents of the /etc/mail Directory

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

Name 

Type 

Description 

Mail.rc

File 

Default settings for the mailx user agent.

aliases

File 

Mail-forwarding information. 

aliases.db

File 

Default binary form of mail-forwarding information that is created by running newaliases.

aliases.dir

File 

Binary form of mail-forwarding information that is created by running newaliases. Can still be used, but is no longer used by default starting with the Solaris 9 release.

aliases.pag

File 

Binary form of mail-forwarding information that is created by running newaliases. Can still be used, but is no longer used by default starting with the Solaris 9 release.

mailx.rc

File 

Default settings for the mailx user agent.

main.cf

Symbolic link 

A symbolic link from this sample configuration file for main systems to sendmail.cf is provided for backwards compatibility. This file is not needed in version 8.13 of sendmail.

relay-domains

File 

List of all domains for which relaying is allowed. By default, only the local domain is allowed. 

sendmail.cf

File 

Configuration file for mail routing. 

submit.cf

File 

New configuration file for the mail submission program (MSP). For more information, refer to submit.cf Configuration File From Version 8.12 of sendmail.

local-host-names

File 

Optional file that you can create if the number of aliases for the mail host is too long. 

helpfile

File 

Help file that is used by the SMTP HELP command.

sendmail.pid

File 

File that lists the PID of the listening daemon and is now in /var/run.

statistics

File 

sendmail statistics file. If this file is present, sendmail logs the amount of traffic through each mailer. Previously, this file was called sendmail.st.

subsidiary.cf

Symbolic link 

A symbolic link from this sample configuration file for subsidiary systems to sendmail.cf is provided for backwards compatibility. This file is not needed in version 8.13 of sendmail.

trusted-users

File 

File that lists the users (one user per line) who can be trusted to perform certain mail operations. By default, only root is in this file. Certain mail operations, when performed by untrusted users, result in the following warning, X-Authentication-Warning: header being added to a message.

Contents of the /etc/mail/cf Directory

Within the /etc/mail directory is a subdirectory, cf, that contains all of the necessary files to build a sendmail.cf file. The content of cf is shown in Table 14–9.

Starting in the Solaris 10 release, to support a read-only /usr file system, the content of the /usr/lib/mail directory has been moved to the /etc/mail/cf directory. Note, however, these exceptions. The shell scripts /usr/lib/mail/sh/check-hostname and /usr/lib/mail/sh/check-permissions are now in the /usr/sbin directory. See Other Files Used for Mail Services. For backward compatibility, symbolic links point to each file's new location.

Table 14–9 Contents of the /etc/mail/cf Directory Used for Mail Services

Name 

Type 

Description 

README

File 

Describes the configuration files. 

cf/main.cf

Symbolic Link 

As of the Solaris 10 release, this file name is linked to cf/sendmail.cf. This file used to be the main configuration file.

cf/main.mc

Symbolic Link 

As of the Solaris 10 release, this file name is linked to cf/sendmail.mc. This file was the file used to create the main configuration file.

cf/Makefile

File 

Provides rules for building new configuration files. 

cf/submit.cf

File 

Is the configuration file for the mail submission program (MSP), which is used to submit messages. 

cf/submit.mc

File 

Is the file used to build the submit.cf file. The file defines m4 macros for the mail submission program (MSP).

cf/sendmail.cf

File 

Is the main configuration file for sendmail. 

cf/sendmail.mc

File 

Contains the m4 macros that are used to generate the sendmail.cf file.

cf/subsidiary.cf

Symbolic Link 

As of the Solaris 10 release, this file name is linked to cf/sendmail.cf. This file used to be the configuration file for hosts that NFS-mount /var/mail from another host.

cf/subsidiary.mc

Symbolic Link 

As of the Solaris 10 release, this file name is linked to cf/sendmail.mc. This file used to contain the m4 macros that were used to generate the subsidiary.cf file.

domain

Directory 

Provides site-dependent subdomain descriptions. 

domain/generic.m4

File 

Is the generic domain file from Berkeley Software Distribution. 

domain/solaris-antispam.m4

File 

Is the domain file with changes that make sendmail function like the previous Solaris versions of sendmail. However, relaying is disabled completely, sender addresses with no host name are rejected, and unresolvable domains are rejected.

domain/solaris-generic.m4

File 

Is the default domain file with changes that make sendmail function like the previous Solaris versions of sendmail.

feature

Directory 

Contains definitions of specific features for particular hosts. See README for a full description of the features.

m4

Directory 

Contains site-independent include files. 

mailer

Directory 

Contains definitions of mailers, which include local, smtp, and uucp.

main-v7sun.mc

File 

Obsolete: as of the Solaris 10 release, this file name is renamed to cf/sendmail.mc.

ostype

Directory 

Describes various operating system environments. 

ostype/solaris2.m4

File 

Defines default local mailer as mail.local.

ostype/solaris2.ml.m4

File 

Defines default local mailer as mail.local.

ostype/solaris2.pre5.m4

File 

Defines local mailer as mail.

ostype/solaris8.m4

File 

Defines local mailer as mail.local (in LMTP mode), enables IPv6, specifies /var/run as the directory for the sendmail.pid file.

subsidiary-v7sun.mc

File 

Obsolete: as of the Solaris 10 release, this file name is renamed to cf/sendmail.mc.

Contents of the /usr/lib Directory

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

Table 14–10 Contents of the /usr/lib Directory

Name 

Type 

Description 

mail.local

File 

Mailer that delivers mail to mailboxes. 

sendmail

File 

Routing program, also known as the mail transfer agent. 

smrsh

File 

Shell program (sendmail restricted shell) that uses the “|program” syntax of sendmail to restrict programs that sendmail can run to those programs listed in the /var/adm/sm.bin directory. Refer to the smrsh(1M) man page for recommendations about what to include in /var/adm/sm.bin. To enable, include this m4 command, FEATURE(`smrsh'), in your mc file.

mail

symbolic link 

A symbolic link points to the/etc/mail/cf directory. For more information, refer to Contents of the /etc/mail/cf Directory.

Other Files Used for Mail Services

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

Table 14–11 Other Files Used for Mail Services

Name 

Type 

Description 

/etc/default/sendmail

File 

Lists the environment variables for the startup script for sendmail.

/etc/shells

File 

Lists the valid login shells. 

/etc/mail/cf/sh

Directory 

Contains shell scripts that are used by the m4 build process and migration aids.

/usr/sbin/check-permissions

File 

Checks permissions of :include: aliases and .forward files and their parent directory path for correct permissions.

/usr/sbin/check-hostname

File 

Verifies that sendmail is able to determine the fully qualified host name.

/usr/sbin/editmap

File 

Queries and edits single records in database maps for sendmail.

/usr/sbin/in.comsat

File 

Mail notification daemon. 

/usr/sbin/makemap

File 

Builds binary forms of keyed maps. 

/usr/sbin/newaliases

Symbolic Link 

A symbolic link to /usr/lib/sendmail. Used to create the binary form of the alias database. Previously in /usr/bin.

/usr/sbin/syslogd

File 

Error message logger, used by sendmail.

/usr/sbin/etrn

File 

Perl script for starting the client-side remote mail queue. 

/usr/dt/bin/dtmail

File 

CDE mail user agent. 

/var/mail/mailbox1, /var/mail/mailbox2

File 

Mailboxes for delivered mail. 

/var/spool/clientmqueue

Directory 

Storage for mail that is delivered by the client daemon. 

/var/spool/mqueue

Directory 

Storage for mail that is delivered by the master daemon. 

/var/run/sendmail.pid

File 

File that lists the PID of the listening daemon. 

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 14–2.

Figure 14–2 Interactions of Mail Programs

The context describes the graphic.

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

  1. Users send messages by using programs such as mailx. See the man page for mailx(1) for more information.

  2. The message is collected by the program that generated the message, and the message 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 which 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 the mail by using mail, mailx, or a similar program.

sendmail Program

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

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

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.

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 13, 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 13, 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 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 13, Mail Services (Tasks).


    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, NIS, or NIS+. The order of the lookup is determined by the nsswitch.conf file. Refer to the nsswitch.conf(4) man page.


sendmail Features

The sendmail program provides the following features.

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

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

Mail Alias Files

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

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 13, 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 that 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, an error occurs. 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 the file 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. This program recompiles the database and makes 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 13, Mail Services (Tasks). Otherwise, you can use the Mailing List feature in the Solaris Management Console to administer the mail aliases that are stored in the local /etc files.

You can create aliases for only local names, such as 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 Solaris Management Console, 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 13, Mail Services (Tasks).

NIS aliases Map

All users in a local domain can use the entries that are in the NIS aliases map. The reason is that 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. However, 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 13, 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 14–12 describes the four columns that are in an NIS+ mail_aliases table.

Table 14–12 Columns in the NIS+ mail_aliases Table

Column 

Description 

alias

The name of the alias 

expansion

The value of the alias or a list of aliases as it would appear in a sendmail /etc/mail/aliases file

options

The column that is reserved for future use 

comments

The column for comments about an individual alias 

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 Administering Mail Alias Files (Task Map) in Chapter 13, Mail Services (Tasks). Alternately, you can use the Solaris Management Console to administer the NIS+ mail aliases.


Note –

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.

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

Situations to Avoid

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

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.

.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 the options 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, rather than the functions 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 queue run intervals, which are periodic. 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 that 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.


Note –

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 a new value is found. This new alias is then checked again.

  2. If the mail is local, deliver the mail 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. However, 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. Furthermore, this section describes the rules for effective use of name services, and the specific interactions of sendmail with name services. For details, refer to the following topics.

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 13, 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.

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

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.

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.

Requirements for Name Services

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.

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

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.

For task information, refer to Administering Mail Alias Files (Task Map) in Chapter 13, 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.

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

Interactions of NIS+ and sendmail

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

For task information, refer to Administering Mail Alias Files (Task Map) in Chapter 13, 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.

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

Changes in Version 8.13 of sendmail

Although this new version of sendmail provides many new features, the FallBackSmartHost option is the most significant addition. Because of this option you no longer need to use main.cf and subsidiary.cf. The main.cf file was used in environments that supported MX records. The subsidiary.cf file was used in environments without a fully operative DNS. In such environments a smart host was used instead of MX records. The FallBackSmartHost option provides unified configuration. It operates like an MX record of last possible preference for all environments. To ensure that mail gets delivered to clients, this option, if enabled, provides a well-connected (or smart) host that serves as a backup (or failover) for MX records that fail.

For more information about version 8.13, see the following sections:

Additionally, starting in the Solaris 10 1/06 release, SMTP can run with Transport Layer Security (TLS). See the following description.

Support for Running SMTP With TLS in Version 8.13 of sendmail

Communications between SMTP servers and clients are not usually controlled or trusted on either end. This lack of security might allow a third party to monitor and even alter a communication between a server and a client. Starting in the Solaris 10 1/06 release, SMTP can use Transport Layer Security (TLS) in version 8.13 of sendmail to resolve this problem. This extended service to SMTP servers and clients provides the following:


Note –

The implementation of TLS is based on the Secure Sockets Layer (SSL) protocol.


STARTTLS is the SMTP keyword that initiates a secure SMTP connection by using TLS. This secure connection might be between two servers or between a server and a client. A secure connection is defined as follows:

When the client issues the STARTTLS command, the server responds with one of the following:

The 220 response requires the client to start the TLS negotiation. The 501 response notes that the client incorrectly issued the STARTTLS command. STARTTLS is issued with no parameters. The 454 response necessitates that the client apply rule set values to determine whether to accept or maintain the connection.

Note that to maintain the Internet's SMTP infrastructure, publicly used servers must not require a TLS negotiation. However, a server that is used privately might require the client to perform a TLS negotiation. In such instances, the server returns this response:


530 Must issue a STARTTLS command first

The 530 response instructs the client to issue the STARTTLS command to establish a connection.

The server or client can refuse a connection if the level of authentication and privacy is not satisfactory. Alternately, because most SMTP connections are not secure, the server and client might maintain an unsecure connection. Whether to maintain or refuse a connection is determined by the configuration of the server and the client.

Support for running SMTP with TLS is not enabled by default. TLS is enabled when the SMTP client issues the STARTTLS command. Before the SMTP client can issue this command, you must set up the certificates that enable sendmail to use TLS. See How to Set SMTP to Use TLS. Note that this procedure includes defining new configuration file options and rebuilding your sendmail.cf file.

Configuration File Options for Running SMTP With TLS

The following table describes the configuration file options that are used to run SMTP with TLS. If you declare any of these options, use one of the following syntaxes:

Table 14–13 Configuration File Options for Running SMTP With TLS

Option 

Description 

CACertFile

m4 name: confCACERT

Argument: filename

Default value: undefined 

Identifies the file that contains one CA certificate. 

CACertPath

m4 name: confCACERT_PATH

Argument: path

Default value: undefined 

Identifies the path to the directory that contains certificates of CAs. 

ClientCertFile

m4 name: confCLIENT_CERT

Argument: filename

Default value: undefined 

Identifies the file that contains the certificate of the client. Note that this certificate is used when sendmail acts as a client.

ClientKeyFile

m4 name: confCLIENT_KEY

Argument: filename

Default value: undefined 

Identifies the file that contains the private key that belongs to the client certificate. 

CRLFile

m4 name: confCRL

Argument: filename

Default value: undefined 

Identifies the file that contains the certificate revocation status, which is used for X.509v3 authentication. 

DHParameters

m4 name: confDH_PARAMETERS

Argument: filename

Default value: undefined 

Identifies the file that contains the Diffie-Hellman (DH) parameters. 

RandFile

m4 name: confRAND_FILE

Argument: file:filename or egd:UNIX socket

Default value: undefined 

Uses the file: prefix to identify the file that contains random data or uses the egd: prefix to identify the UNIX socket. Note that because the Solaris OS supports the random number generator device, this option does not need to be specified. See the random(7D) man page.

ServerCertFile

m4 name: confSERVER_CERT

Argument: filename

Default value: undefined 

Identifies the file that contains the server's certificate. This certificate is used when sendmail acts as a server.

Timeout.starttls

m4 name: confTO_STARTTLS

Argument: amount of time

Default value: 1h

Sets the amount of time the SMTP client waits for a response to the STARTTLS command.

TLSSrvOptions

m4 name: confTLS_SRV_OPTIONS

Argument: V

Default value: undefined 

Determines whether the server asks for a certificate from the client. If this option is set to V, no client verification is performed.

For sendmail to support SMTP's use of TLS, the following options must be defined:

Other options are not required.

Macros for Running SMTP With TLS

The following table describes the macros that are used by the STARTTLS command.

Table 14–14 Macros for Running SMTP With TLS

Macro 

Description 

${cert_issuer}

Holds the distinguished name (DN) of the certification authority (CA), which is the certificate issuer. 

${cert_subject}

Holds the DN of the certificate that is called the cert subject.

${cn_issuer}

Holds the common name (CN) of the CA, which is the cert issuer.

${cn_subject}

Holds the CN of the certificate that is called the cert subject.

${tls_version}

Holds the version of TLS that is used for the connection. 

${cipher}

Holds a set of cryptographic algorithms (known as a cipher suite) that is used for the connection.

${cipher_bits}

Holds in bits the key length of the symmetric encryption algorithm that is used for the connection. 

${verify}

Holds the result of the verification of the certificate that was presented. Possible values are as follows: 

  • OK – The verification succeeded.

  • NO – No certificate was presented.

  • NOT – No certificate was requested.

  • FAIL – The certificate that was presented could not be verified.

  • NONESTARTTLS has not been performed.

  • TEMP – Temporary error occurred.

  • PROTOCOL – SMTP error occurred.

  • SOFTWARESTARTTLS handshake failed.

${server_name}

Holds the name of the server with the current outgoing SMTP connection. 

${server_addr}

Holds the address of the server with the current outgoing SMTP connection. 

Rule Sets for Running SMTP With TLS

The following table describes rule sets that determine whether an SMTP connection that uses TLS should be accepted, continued, or refused.

Table 14–15 Rule Sets for Running SMTP With TLS

Rule Set 

Description 

tls_server

Acting as a client, sendmail uses this rule set to determine whether the server is currently supported by TLS.

tls_client

Acting as a server, sendmail uses this rule set to determine whether the client is currently supported by TLS.

tls_rcpt

This rule set requires verification of the recipient's MTA. This recipient restriction makes attacks such as DNS spoofing impossible. 

TLS_connection

This rule set checks the requirement that is specified by the RHS of the access map against the actual parameters of the current TLS connection. 

try_tls

sendmail uses this rule set to determine the feasibility of using STARTTLS when connecting to another MTA. If the MTA cannot properly implement STARTTLS, then STARTTLS is not used.

For more information, see http://www.sendmail.org/m4/starttls.html.

Security Considerations Related to Running SMTP With TLS

As a standard mail protocol that defines mailers that run over the Internet, SMTP is not an end-to-end mechanism. Because of this protocol limitation, TLS security through SMTP does not include mail user agents. Mail user agents act as an interface between users and a mail transfer agent such as sendmail.

Also, mail might be routed through multiple servers. For complete SMTP security the entire chain of SMTP connections must have TLS support.

Finally, the level of negotiated authentication and privacy between each pair of servers or a client and server pair must be considered. For more information, see Authentication Services in System Administration Guide: Security Services.

Additional Command-Line Options in Version 8.13 of sendmail

The following table describes additional command-line options that are available in version 8.13 of sendmail. Other command-line options are described in the sendmail(1M) man page.

Table 14–16 Command-Line Options Available in Version 8.13 of sendmail

Option 

Description 

-D logfile

Sends debugging output to the indicated logfile, instead of including this information with the standard output.

-q[!]Qsubstr

Specifies the processing of quarantined jobs that have this substr, which is a substring of the quarantine reason. See the description of the -Qreason option. If ! is added, this option processes quarantined jobs that do not have this substr.

-Qreason

Quarantines a normal queue item with this reason. If no reason is given, the quarantined queue item is unquarantined. This option works with the -q[!]Qsubstr option. The substr is a portion (or substring) of the reason.

Additional and Revised Configuration File Options in Version 8.13 of sendmail

The following table describes the added and revised configuration file options. If you declare any of these options, use one of the following syntaxes.


O OptionName=argument          # for the configuration file
-O OptionName=argument         # for the command line
define(`m4Name',argument)     # for m4 configuration
Table 14–17 Configuration File Options Available in Version 8.13 of sendmail

Option 

Description 

ConnectionRateWindowSize

m4 name: confCONNECTION_RATE_WINDOW_SIZE

Argument: number

Default value: 60

Sets the number of seconds for incoming connections to be maintained. 

FallBackSmartHost

m4 name: confFALLBACK_SMARTHOST

Argument: hostname

To ensure that mail gets delivered to the clients, this option provides a well-connected host that serves as a backup (or failover) for MX records that fail. 

InputMailFilters

m4 name: confINPUT_MAIL_FILTERS

Argument: filename

Lists the input mail filters for the sendmail daemon.

PidFile

m4 name: confPID_FILE

Argument: filename

Default value: /var/run/sendmail.pid

As in previous releases, the file name is macro-expanded before it is opened. Additionally, in version 8.13, the file is unlinked when sendmail exits.

QueueSortOrder

m4 name: confQUEUE_SORT_ORDER

Added argument: none

In version 8.13 none is used to specify no sorting order.

RejectLogInterval

m4 name: confREJECT_LOG_INTERVAL

Argument: period-of-time

Default value: 3h, which represents three hours.

When a daemon connection is refused for the period-of-time specified, the information is logged.

SuperSafe

m4 name: confSAFE_QUEUE

Short name: s

Added argument: postmilter

Default value: true

If postmilter is set, sendmail defers synchronizing the queue file until all milters have signaled acceptance of the message. For this argument to be useful, sendmail must be running as an SMTP server. Otherwise, postmilter operates as if you are using the true argument.

Additional and Revised FEATURE() Declarations in Version 8.13 of sendmail

The following table describes the added and revised FEATURE() declarations. This m4 macro uses the following syntax.


FEATURE(`name', `argument')
Table 14–18 FEATURE() Declarations Available in Version 8.13 of sendmail

Name of FEATURE()

Description 

conncontrol

Works with the access_db rule set to check the number of incoming SMTP connections. For details, see /etc/mail/cf/README.

greet_pause

Adds the greet_pause rule set, which enables open proxy and SMTP slamming protection. For details, see /etc/mail/cf/README.

local_lmtp

The default argument continues to be mail.local, which is the LMTP-capable mailer in this Solaris release. However, in version 8.13, if a different LMTP-capable mailer is used, its path name can be specified as a second parameter and the arguments that are passed to the second parameter can be specified in the third parameter. For example:


FEATURE(`local_lmtp', `/usr/local/bin/lmtp', `lmtp')

mtamark

Provides experimental support for “Marking Mail Transfer Agents in Reverse DNS with TXT RRs” (MTAMark). For details, see /etc/mail/cf/README.

ratecontrol

Works with the access_db rule set to control connection rates for hosts. For details, see /etc/mail/cf/README.

use_client_ptr

If this FEATURE() is enabled, the rule set check_relay overrides its first argument with this argument, $&{client_ptr}.

Changes From Version 8.12 of sendmail

This section contains information about the following topics.

Support for TCP Wrappers From Version 8.12 of sendmail

TCP wrappers provide a way of implementing access controls by checking the address of a host requesting a particular network service against an access control list (ACL). Requests are granted or denied, accordingly. Besides providing this access control mechanism, TCP wrappers also log host requests for network services, which is a useful monitoring function. Examples of network services that might be placed under access control include rlogind, telnetd, and ftpd.

Starting with version 8.12, sendmail enables the use of TCP wrappers. This check does not bypass other security measures. By enabling TCP wrappers in sendmail, a check has been added to validate the source of a network request before the request is granted. See the hosts_access(4) man page.


Note –

Support for TCP wrappers in inetd(1M) and sshd(1M) started with the Solaris 9 release.


For information about ACLs, see Using Access Control Lists to Protect UFS Files in System Administration Guide: Security Services.

submit.cf Configuration File From Version 8.12 of sendmail

Starting with version 8.12, sendmail includes an additional configuration file, /etc/mail/submit.cf. This file, submit.cf, is used to run sendmail in mail-submission program mode instead of daemon mode. Mail-submission program mode, unlike daemon mode, does not require root privilege, so this new paradigm provides better security.

See the following list of functions for submit.cf:

Note the following:

Functions That Distinguish sendmail.cf From submit.cf

The sendmail.cf configuration file is for the daemon mode. When using this file, sendmail is acting as a mail transfer agent (MTA), which is started by root.


/usr/lib/sendmail -L sm-mta -bd -q1h

See the following list of other distinguishing functions for sendmail.cf:

Functional Changes From Version 8.12 of sendmail

With the addition of submit.cf, the following functional changes have occurred:

Additional or Deprecated Command-Line Options From Version 8.12 of sendmail

The following table describes additional or deprecated command-line options for sendmail. Other command-line options are described in the sendmail(1M) man page.

Table 14–19 Additional or Deprecated Command-Line Options From Version 8.12 of sendmail

Option 

Description 

-Ac

Indicates that you want to use the configuration file, submit.cf, even if the operation mode does not indicate an initial mail submission. For more information about submit.cf, refer to submit.cf Configuration File From Version 8.12 of sendmail.

-Am

Indicates that you want to use the configuration file, sendmail.cf, even if the operation mode indicates an initial mail submission. For more information, refer to submit.cf Configuration File From Version 8.12 of sendmail.

-bP

Indicates that you are printing the number of entries in each queue. 

-G

Indicates that the message that is being submitted from the command line is for relaying, not for initial submission. The message is rejected if the addresses are not fully qualified. No canonicalization is done. As is noted in the Release Notes that are part of the sendmail distribution on ftp://ftp.sendmail.org, improperly formed messages might be rejected in future releases.

-L tag

Sets the identifier that is used for syslog messages to the supplied tag.

-q[!]I substring

Processes only jobs that contain this substring of one of the recipients. When ! is added, the option processes only jobs that do not have this substring of one of the recipients.

-q[!]R substring

Processes only jobs that contain this substring of the queue ID. When ! is added, the option processes only jobs that do not have this substring of the queue ID.

-q[!]S substring

Processes only jobs that contain this substring of the sender. When ! is added, the option processes only jobs that do not have this substring of the sender.

-qf

Processes saved messages in the queue once, without using the fork system call, and runs the process in the foreground. Refer to the fork(2) man page.

-qGname

Processes only the messages in the name queue group.

-qptime

Processes saved messages in the queue at a specific interval of time with a single child that is forked for each queue. The child sleeps between queue runs. This new option is similar to the -qtime, which periodically forks a child to process the queue.

-U

As is noted in the Release Notes that are part of the sendmail distribution on ftp://ftp.sendmail.org, this option is not available as of version 8.12. Mail user agents should use the -G argument.

Additional Arguments for the PidFile and ProcessTitlePrefix Options From Version 8.12 of sendmail

The following table describes additional macro-processed arguments for the PidFile and ProcessTitlePrefix options. For more information about these options, see the sendmail(1M) man page.

Table 14–20 Arguments for the PidFile and ProcessTitlePrefix Options

Macro 

Description 

${daemon_addr}

Provides daemon address (for example, 0.0.0.0) 

${daemon_family}

Provides daemon family (for example, inet, and inet6)

${daemon_info}

Provides daemon information (for example, SMTP+queueing@00:30:00) 

${daemon_name}

Provides daemon name (for example, MSA) 

${daemon_port}

Provides daemon port (for example, 25) 

${queue_interval}

Provides queue run interval (for example, 00:30:00) 

Additional Defined Macros From Version 8.12 of sendmail

The following table describes additional macros that are reserved for use by the sendmail program. The macros' values are assigned internally. For more information, refer to the sendmail(1M) man page.

Table 14–21 Additional Defined Macros for sendmail

Macro 

Description 

${addr_type}

Identifies the current address as an envelope sender or a recipient address. 

${client_resolve}

Holds the result of the resolve call for ${client_name}: OK, FAIL, FORGED, or TEMP.

${deliveryMode}

Specifies the current delivery mode sendmail is using instead of the value of the DeliveryMode option.

${dsn_notify}, ${dsn_envid}, ${dsn_ret}

Holds the corresponding DSN parameter values. 

${if_addr}

Provides the interface's address for the incoming connection if the interface does not belong to the loopback net. This macro is especially useful for virtual hosting. 

${if_addr_out}, ${if_name_out}, ${if_family_out}

Avoids the reuse of ${if_addr}. Holds the following values respectively:

The address of the interface for the outgoing connection 

The host name of the interface for the outgoing connection 

The family of the interface for the outgoing connection 

${if_name}

Provides the interface's host name for the incoming connection and is especially useful for virtual hosting.  

${load_avg}

Checks and reports the current average number of jobs in the run queue. 

${msg_size}

Holds the value of the message size (SIZE=parameter) in an ESMTP dialogue before the message has been collected. Thereafter, the macro holds the message size as computed by sendmail and is used in check_compat. For information about check_compat, refer to Table 14–25.

${nrcpts}

Holds the number of validated recipients. 

${ntries}

Holds the number of delivery attempts. 

${rcpt_mailer}, ${rcpt_host}, ${rcpt_addr}, ${mail_mailer}, ${mail_host}, ${mail_addr}

Holds the results of parsing the RCPT and MAIL arguments, which is the resolved right-hand side (RHS) triplet from the mail delivery agent ($#mailer), the host ($@host), and the user ($:addr).

Additional Macros From Version 8.12 of sendmail

In this section, you can find a table that describes the additional macros that are used to build the sendmail configuration file.

Table 14–22 Additional Macros Used to Build the sendmail Configuration File

Macro 

Description 

LOCAL_MAILER_EOL

Overrides the default end-of-line string for the local mailer. 

LOCAL_MAILER_FLAGS

Adds Return-Path: header by default.

MAIL_SETTINGS_DIR

Contains the path (including the trailing slash) for the mail settings directory. 

MODIFY_MAILER_FLAGS

Improves the *_MAILER_FLAGS. This macro sets, adds, or deletes flags.

RELAY_MAILER_FLAGS

Defines additional flags for the relay mailer. 

Additional MAX Macros From Version 8.12 of sendmail

Use the following macros to configure the maximum number of commands that can be received before sendmail slows its delivery. You can set these MAX macros at compile time. The maximum values in the following table also represent the current default values.

Table 14–23 Additional MAX Macros

Macro 

Maximum Value 

Commands Checked by Each Macro 

MAXBADCOMMANDS

25 

Unknown commands 

MAXNOOPCOMMANDS

20 

NOOP, VERB, ONEX, XUSR

MAXHELOCOMMANDS

HELO, EHLO

MAXVRFYCOMMANDS

VRFY, EXPN

MAXETRNCOMMANDS

ETRN


Note –

You can disable a macro's check by setting the macro's value to zero.


Additional and Revised m4 Configuration Macros From Version 8.12 of sendmail

This section contains a table of additional and revised m4 configuration macros for sendmail. Use the following syntax to declare these macros.


symbolic-name(`value')

If you need to build a new sendmail.cf file, refer to Changing the sendmail Configuration in Chapter 13, Mail Services (Tasks).

Table 14–24 Additional and Revised m4 Configuration Macros for sendmail

m4 Macro

Description 

FEATURE()

For details, refer to Changes to the FEATURE() Declaration From Version 8.12 of sendmail.

LOCAL_DOMAIN()

This macro adds entries to class w ($=w).

MASQUERADE_EXCEPTION()

A new macro that defines hosts or subdomains that cannot be masqueraded. 

SMART_HOST()

This macro can now be used for bracketed addresses, such as user@[host].

VIRTUSER_DOMAIN() or VIRTUSER_DOMAIN_FILE()

When these macros are used, include $={VirtHost} in $=R. As a reminder, $=R is the set of host names that are allowed to relay.

Changes to the FEATURE() Declaration From Version 8.12 of sendmail

Refer to the following tables for information about the specific changes to the FEATURE() declarations.

To use the new and revised FEATURE names, use the following syntax.


FEATURE(`name', `argument')

If you need to build a new sendmail.cf file, refer to Changing the sendmail Configuration in Chapter 13, Mail Services (Tasks).

Table 14–25 Additional and Revised FEATURE() Declarations

Name of FEATURE()

Description 

compat_check

Argument: Refer to the example in the following paragraph. 

This new FEATURE() enables you to look for a key in the access map that consists of the sender address and the recipient address. This FEATURE() is delimited by the following string, <@>. sender@sdomain<@>recipient@rdomain is an example.

delay_checks

Argument: friend, which enables a spam-friend test, or hater, which enables a spam-hater test.

A new FEATURE() that delays all checks. By using FEATURE(`delay_checks'), the rule sets check_mail and check_relay are not called when a client connects or issues a MAIL command respectively. Instead, these rule sets are called by the check_rcpt rule set. For details, refer to the /etc/mail/cf/README file.

dnsbl

Argument: This FEATURE()accepts a maximum of two arguments:

  • DNS server name

  • Rejection message

A new FEATURE() that you can include multiple times to check the return values for DNS lookups. Note that this FEATURE() enables you to specify the behavior of temporary lookup failures.

enhdnsbl

Argument: domain name. 

A new FEATURE() that is an enhanced version of dnsbl, which enables you to check the return values for DNS lookups. For more information, refer to /etc/mail/cf/README.

generics_entire_domain

Argument: None. 

A new FEATURE() that you can also use to apply genericstable to subdomains of $=G.

ldap_routing

Argument: For details, refer to the “Release Notes” in http://www.sendmail.org.

A new FEATURE() that implements LDAP address routing.

local_lmtp

Argument: Path name of an LMTP-capable mailer. The default is mail.local, which is LMTP capable in this Solaris release.

A FEATURE() that now sets the delivery status notification (DSN) diagnostic-code type for the local mailer to the proper value of SMTP.

local_no_masquerade

Argument: None. 

A new FEATURE() that you can use to avoid masquerading for the local mailer.

lookupdotdomain

Argument: None. 

A new FEATURE() that you can also use to look up the .domain in the access map.

nocanonify

Argument: canonify_hosts or nothing.

A FEATURE() that now includes the following features.

Enables a list of domains, as specified by CANONIFY_DOMAIN or CANONIFY_DOMAIN_FILE, to be passed to the $[ and $] operators for canonification.

Enables addresses that have only a host name, such as <user@host>, to be canonified, if canonify_hosts is specified as its parameter.

Adds a trailing dot to addresses with more than one component. 

no_default_msa

Argument: None. 

A new FEATURE() that turns off sendmail's default setting from m4–generated configuration files to “listen” on several different ports, an implementation of RFC 2476.

nouucp

Argument: reject, which does not allow the ! token, or nospecial, which does allow the ! token.

A FEATURE() that determines whether to allow the ! token in the local part of an address.

nullclient

Argument: None. 

A FEATURE() that now provides the full rule sets of a normal configuration, allowing antispam checks to be performed.

preserve_local_plus_detail

Argument: None. 

A new FEATURE() that enables you to preserve the +detail portion of the address when sendmail passes the address to the local delivery agent.

preserve_luser_host

Argument: None. 

A new FEATURE() that enables you to preserve the name of the recipient host, if LUSER_RELAY is used.

queuegroup

Argument: None. 

A new FEATURE() that enables you to select a queue group that is based on the full email address or on the domain of the recipient.

relay_mail_from

Argument: The domain is an optional argument.

A new FEATURE() that allows relaying if the mail sender is listed as a RELAY in the access map and is tagged with the From: header line. If the optional domain argument is given, the domain portion of the mail sender is also checked.

virtuser_entire_domain

Argument: None. 

A FEATURE() that you can now use to apply $={VirtHost}, a new class for matching virtusertable entries that can be populated by VIRTUSER_DOMAIN or VIRTUSER_DOMAIN_FILE.

FEATURE(`virtuser_entire_domain') can also apply the class $={VirtHost} to entire subdomains.

The following FEATURE() declarations are no longer supported.

Table 14–26 Unsupported FEATURE() Declarations

Name of FEATURE()

Replacement 

rbl

FEATURE(`dnsbl') and FEATURE(`enhdnsbl') replace this FEATURE(), which has been removed.

remote_mode

MASQUERADE_AS(`$S') replaces FEATURE(`remote_mode') in /etc/mail/cf/subsidiary.mc. $S is the SMART_HOST value in sendmail.cf.

sun_reverse_alias_files

FEATURE(`genericstable').

sun_reverse_alias_nis

FEATURE(`genericstable').

sun_reverse_alias_nisplus

FEATURE(`genericstable').

Changes to the MAILER() Declaration From Version 8.12 of sendmail

The MAILER() declaration specifies support for delivery agents. To declare a delivery agent, use the following syntax.


MAILER(`symbolic-name')

Note the following changes.

For more information about mailers, refer to Mailers and sendmail. If you need to build a new sendmail.cf file, refer to Changing the sendmail Configuration in Chapter 13, Mail Services (Tasks).

Additional Delivery Agent Flags From Version 8.12 of sendmail

The following table describes additional delivery agent flags, which by default are not set. These single-character flags are Boolean. You can set or unset a flag by including or excluding it in the F= statement of your configuration file, as shown in the following example.


Mlocal,    P=/usr/lib/mail.local, F=lsDFMAw5:/|@qSXfmnz9, S=10/30, R=20/40,
Mprog,     P=/bin/sh, F=lsDFMoqeu9, S=10/30, R=20/40, D=$z:/,
Msmtp,     P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990,
Mesmtp,    P=[IPC], F=mDFMuXa, S=11/31, R=21, E=\r\n, L=990,
Msmtp8,    P=[IPC], F=mDFMuX8, S=11/31, R=21, E=\r\n, L=990,
Mrelay,    P=[IPC], F=mDFMuXa8, S=11/31, R=61, E=\r\n, L=2040,
Table 14–27 Additional Mailer Flags

Flag 

Description 

%

Mailers that use this flag do not attempt delivery to the initial recipient of a message or to queue runs unless the queued message is selected by using an ETRN request or one of the following queue options: -qI, -qR, or -qS.

1

This flag disables the ability of the mailer to send null characters (for example, \0).

2

This flag disables the use of ESMTP and requires that SMTP be used instead. 

6

This flag enables mailers to strip headers to 7 bit. 

Additional Equates for Delivery Agents From Version 8.12 of sendmail

The following table describes additional equates that you can use with the M delivery-agent definition command. The following syntax shows you how to append new equates or new arguments to the equates that already exist in the configuration file.


Magent-name, equate, equate, ...

The following example includes the new W= equate. This equate specifies the maximum time to wait for the mailer to return after all data has been sent.


Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990, W=2m

When you modify the definition of a value for m4 configuration, use the syntax that is provided in the following example.


define(`SMTP_MAILER_MAXMSGS', `1000')

The preceding example places a limit of 1000 on the number of messages that are delivered per connection on an smtp mailer.

If you need to build a new sendmail.cf file, refer to Changing the sendmail Configuration in Chapter 13, Mail Services (Tasks).


Note –

Typically, you modify the equate definitions in the mailer directory only when you fine-tune.


Table 14–28 Additional Equates for Delivery Agents

Equate 

Description 

/=

Argument: Path to a directory 

Specifies a directory to apply chroot() to before the mailer program is executed

m=

Argument: Any of the following m4 values that have previously been defined with the define() routine

    SMTP_MAILER_MAXMSGS, for the smtp mailer


    LOCAL_MAILER_MAXMSGS, for the local mailer


    RELAY_MAILER_MAXMSGS, for the relay mailer


Limits the number of messages that are delivered per connection on an smtp, local, or relay mailer

W=

Argument: An increment of time 

Specifies the maximum time to wait for the return of the mailer after all data has been sent 

Additional Queue Features From Version 8.12 of sendmail

The following list provides details about additional queue features.

For task information, refer to Administering the Queue Directories (Task Map).

Changes for LDAP From Version 8.12 of sendmail

The following list describes changes in the use of the Lightweight Directory Access Protocol (LDAP) with sendmail.

The following example shows how these tokens differ for a “*” lookup.

Table 14–29 Comparison of Tokens

LDAP Map Specification 

Specification Equivalent 

Result 

-k"uid=%s"

-k"uid=*"

Matches any record with a user attribute 

-k"uid=%0"

-k"uid=\2A"

Matches a user with the name “*

The following table describes additional LDAP map flags.

Table 14–30 Additional LDAP Map Flags

Flag 

Description 

-1

Requires a single match to be returned. If more than one match is returned, the results are the equivalent of no records being found. 

-r never|always|search|find

Sets the LDAP alias dereference option. 

-Z size

Limits the number of matches to return. 

Change to the Built-In Mailer From Version 8.12 of sendmail

The old [TCP] built-in mailer is not available. Use the P=[IPC] built-in mailer instead. The interprocess communications ([IPC]) built-in mailer now enables delivery to a UNIX domain socket on systems that support it. You can use this mailer with LMTP delivery agents that listen on a named socket. An example mailer might resemble the following.


Mexecmail, P=[IPC], F=lsDFMmnqSXzA5@/:|, E=\r\n, 
S=10, R=20/40, T=DNS/RFC822/X-Unix, A=FILE /var/run/lmtpd

The first mailer argument in the [IPC] mailer is now checked for a legitimate value. The following table provides possible values for the first mailer argument.

Table 14–31 Possible Values for the First Mailer Argument

Value 

Description 

A=FILE

Use for UNIX domain socket delivery 

A=TCP

Use for TCP/IP connections 

A=IPC

Is no longer available as a first mailer argument 

Additional Rule Sets From Version 8.12 of sendmail

The following table lists the additional rule sets and describes what the rule sets do.

Table 14–32 New Rule Sets

Set 

Description 

check_eoh

Correlates information that is gathered between headers and checks for missing headers. This rule set is used with the macro storage map and is called after all of the headers have been collected.  

check_etrn

Uses the ETRN command (as check_rcpt uses RCPT).

check_expn

Uses the EXPN command (as check_rcpt uses RCPT).

check_vrfy

Uses the VRFY command (as check_rcpt uses RCPT).

The following list describes additional rule set features.

Changes to Files From Version 8.12 of sendmail

Note the following changes.

sendmail Version 8.12 and IPv6 Addresses in Configuration

Starting with version 8.12 of sendmail, IPv6 addresses that are used in configuration should be prefixed with the IPv6: tag to identify the address properly. If you are not identifying an IPv6 address, a prefix tag is not used.