test

Mail Administration Guide

Chapter 3 sendmail Reference

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

What's New with sendmail

Version 8.9 of sendmail has been included with the Solaris 7 release. Here is a list of the important or user-visible changes that are included in this new version:

Additional information on the Solaris version of sendmail can be found at http://www.sendmail.org/sun-specific/migration+sun.html.

The New Configuration Files

In order to customize your mail system, it can be necessary to re-configure sendmail. Earlier Solaris releases contained a large file that included many cryptic options, that needed to be manually edited to make any changes to the way sendmail functions. In the Solaris 7 release, a new configuration system has been included, which uses m4 to build the configuration file (see the m4(1) man page).

Changes to the sendmail Command Line Options

The options listed in the following table are the new options for the Solaris 7 release. A complete description of these options can be found in sendmail, Second Edition, by Bryan Costales.

Table 3-1 sendmail Command-Line Arguments Changes

Argument 

Description 

-bD

Run as a daemon, but do not fork so that sendmail always runs in the foreground.

-bH

Purge persistent host status. 

-bh

Print persistent host status. 

-M

Assign a macro value. 

-N

Append the DSN NOTIFY command to the ESMTP RCPT command.

-O

Use to set a multicharacter configuration option. 

-p

Set the protocol and hostname. 

-R

Include the DSN RET command to the ESMTP MAIL command.

-U

Used to indicate that this is the very first step in this submission. 

-V

Specify the envelope indentifier for outgoing messages. 

Changes to the sendmail Configuration File Options

The options listed in the following table are the new configuration options for the Solaris 7 release. These options are sorted by their multicharacter name. If the option still has a single character name, it is displayed parenthetically. Many of the single character options supported in 2.6 are still supported in the Solaris 7 release. A complete description of these options can be found in sendmail, Second Edition, by Bryan Costales.

Table 3-2 sendmail Configuration File Option Changes

Argument 

Description 

AllowBogusHELO

Allow no hostname with HELO or EHLO.

ColonOkInAddr

Allow colons in addresses. 

ConnectionRateThrottle

Slow the acceptance rate of new connections. 

DefaultCharSet

Define default character set. 

DialDelay

Set delay time for second connect() attempt.

DontBlameSendmail

Disable parts of security checking. 

DontExpandCnames

Prevent canonical name expansion. 

DontInitGroups

Do not use initgroups().

DontProbeInterfaces

Disable automatic probing of interfaces. 

DoubleBounceAddress

Set email address for error notifications. 

EightBitMode

Specify how to handle unlabeled 8-bit data. 

ErrorHeader (E)

Append custom text ahead of error message text. 

ForwardPath (J)

Set alternative locations of the .forward file.

HostsFile

Specify an alternative location for the /etc/hosts file.

HostStatusDirectory

Set the location of the directory containing persistent host status data. 

MaxDaemonChildren

Limit the number of forked children of sendmail.

MaxMessageSize

Set the maximum messages size. 

MaxMimeHeaderLength

Set the maximum length of certain MIME header field values. 

MaxRecipientsPerMessage

Set the maximum number of message recipients. 

MaxQueueRunSize

Set the number of queued messages that can be processed in one run. 

MinQueueAge

Determine the minimum amount of time a message must be in the queue before processing. 

MustQuoteChars

Set the list of characters that must be quoted in nonaddress information. 

NoRecipientAction

Determine how to handle headers without recipients. 

OperatorChars or $o

Establishe the list of separation operators. 

QueueSortOrder

Specify how to sort the queue. 

RunAsUser

Run sendmail as a non-root user.

SafeFileEnvironment

Select the directory for safe file writes. 

ServiceSwitchFile

Specify the location of the switch file for name services. 

SingleLineFromHeader

Convert all newlines in the From: header to space characters.

SingleThreadDelivery

Select single threaded delivery. 

UnsafeGroupWrites

Check for unsafe group permissions. 

Solaris sendmail Differences

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

Flags Used When Compiling sendmail

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

Alternative sendmail Commands

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

Table 3-3 Alternate sendmail Commands

Alternate Name 

Included in Solaris? 

Options with sendmail

hoststat nosendmail -bh
mailq yessendmail -bp
newaliases yessendmail -bi
purgestat nosendmail -bH
smtpd nosendmail -bd

Define Configuration File Version

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

Table 3-4 Configuration File Version Values

Field 

Description 

V1/Sun

Use Solaris extensions of name service support. This option allows for old configuration files to be used with the new version of sendmail. This is the default setting if nothing is specified.

V7/Sun

Use for Version 8.8 of sendmail.

V8/Sun

Use for Version 8.9 of sendmail. This is the setting that is included in prebuilt configuration file in the Solaris 7 release.

How Mail Addressing Works

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    The mail will be delivered to a local mailbox.

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

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

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

How sendmail Interacts With a Name Service

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

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

Given these assumptions, it is the responsibility of the mail host to deliver or forward inter-domain mail.

Setting Up sendmail Requirements for Name Services

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

Establishing the Mail Domain Name with a Name Service

The mail domain name must be a suffix of the name service domain. For example, if the domain name of the name service is A.B.C.D, then 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 larger, the name service domain can be divided into smaller pieces to make the name service more manageable. However, the mail domain often remains undivided to provide consistent aliasing.

Host Name Space Data

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

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

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

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

Configuration Issues with NIS and sendmail

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

Configuration Issues with NIS and DNS while Using sendmail

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

Configuration Issues with NIS+ and sendmail

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

Configuration Issues with NIS+ and DNS while Using sendmail

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

Other Mail-Related Topics

This section includes specific information about the various forms of alias files that can be used on a Solaris system. In addition, a discussion of .forward files is included.

Mail Alias Files

You can use any of the following files to maintain aliases. Which type of file to use depends on who will be using the alias and who needs to be able to change the alias. Each type of alias file has unique format requirements. Each of these is defined in the following sections.

.mailrc Aliases

Aliases listed in a .mailrc file are accessible only by the user who owns the file. This allows users to establish an alias file they control and that is usable only by its owner. Aliases in a .mailrc file adhere to the following format: 


alias aliasname value value value ...

where aliasname is the name the user will use when sending mail, and value is a valid email address.

If a user establishes a personal alias for scott that does not match the email address for scott in the name space, mail will be routed to the wrong person when other people try to reply to mail generated by that user. The only workaround is to use any of the other aliasing mechanisms.

/etc/mail/aliases

Any alias established in the /etc/mail/aliases file can be used by any user who knows the name of the alias and the host name of the system that contains the file. Distribution list formats in a local /etc/mail/aliases file adhere to the following format: 


aliasname: value,value,value...

where aliasname is the name the user will use when sending mail to this alias and value is a valid email address.

The aliases in the /etc/mail/aliases file are stored in text form. When you edit the /etc/mail/aliases file, run the newaliases program to recompile the database and make the aliases available in binary form to the sendmail program. Or you can use Administration Tool's Database Manager to administer the mail aliases stored in local /etc files.

Normally, the root user only can edit this file. If using the Administration Tool, then all users in group 14, which is the sysadmin group, will be able to change the local file. Another option is to create an entry like: 


aliasname: :include:/path/aliasfile

where aliasname is the name the user will use when sending mail and /path/aliasfile is the full path to the file that includes the alias list. The alias file should include email entries, one entry on each line, and no other notations: 


user1@host1
user2@host2

You can define additional mail files in /etc/mail/aliases to keep a log or a backup copy. The following entry stores all mail sent to aliasname in filename.


aliasname: /home/backup/filename

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


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

NIS Aliases Map

All users in the local domain can use entries included in the NIS aliases map. The sendmail program can use the NIS aliases map instead of the local /etc/mail/aliases files to determine mailing addresses. See the nsswitch.conf(4) man page for more information.

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


aliasname: value,value,value...

where aliasname is the name the user will use when sending mail and value is a valid email address.

The NIS aliases map should contain entries for all mail clients. In general, only the root user on the NIS master can change these entries. This type of alias might not be a good choice for aliases that are constantly changing, but can be useful if the alias points to another alias file; as in this syntax example:


aliasname: aliasname@host

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

NIS+ mail_aliases Table

The NIS+ mail_aliases table contains the names by which a system or person is known in the local domain. The sendmail program can use the NIS+ mail_aliases table instead of the local /etc/mail/aliases files to determine mailing addresses. See the aliasadm(1M) and nsswitch.conf(4) man pages for more information.

Aliases in the NIS+ mail_aliases table adhere to the following format:


alias:			expansion					[options		# "comments"]

Table 3-5 describes the four columns.

Table 3-5 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

Reserved for future use 

comments

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. Or you can use Administration Tool's Database Manager to administer NIS+ mail aliases.

If you are creating a new NIS+ aliases table, you must initialize the table before you create the entries. If the table exists, no initialization is needed. See "To List Individual Entries in the NIS+ mail_aliases Table " for information about how to create a NIS+ mail_aliases table.

To use the aliasadm command, you must be a member of the NIS+ group that owns the aliases table or the person who created the table.

.forward Files

Users can create a .forward file in their home directories that sendmail uses to temporarily redirect mail or send mail to a custom set of programs without consulting a system administrator. When troubleshooting mail problems, particularly problems with mail not being delivered to the expected address, always check the user's home directory for a .forward file.

A common mistake users make is to put a .forward file in the home directory of host1 that forwards mail to user@host2. When the mail gets to host2, sendmail looks up user in the NIS or NIS+ aliases and sends the message back to user@host1, resulting in a loop, and more bounced mail.

Note -

The root and bin accounts should never have .forward files. Creating these files will create a large security hole. If necessary, forward mail using the aliases file instead.

In order for a .forward file to be consulted during the delivery of mail, the file must be writable only by the owner of the file. This prevents other users from breaking security. In addition, the paths leading up to the home directory must be owned and writable by root only. In particular, if a .forward file is in /export/home/terry, then /export and /export/home must be owned and writable only by root. The actual home directory should be writable only by the user. Other restrictions on a .forward file are that the file cannot be a symbolic link and cannot have more than one hard link.

In addition to the standard .forward file, a .forward.hostname file can be created to redirect mail sent to a specific host. For example, if a user's alias has changed from a sandy@phoenix.eng.acme.com to sandy@eng.acme.com, then it might be nice to place a .forward.phoenix file in the home directory for sandy. 


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

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

Sandy

This allows for the mail to be forwarded to the correct place while also notifying the sender of the alias change. Notice that since the vacation program allows only one message file, so this can be done for only one message at a time. However, if the message is not host-specific, one vacation message file can be used by .forward files for many hosts.

Another extension to the forwarding mechanism is the .forward+detail file. The detail string can be any sequence of characters as long as no operator characters are used. The operator characters are .:%&!^[]+. Using a file like this can make it possible to determine if someone else is giving your email address away. For instance, if a user told someone to use the email address sandy+test1@eng.acme.com, the user would be able to identify any future mail that was delivered to this alias. By default, any mail sent to sandy+test1@eng.acme.com alias is checked against the alias and .forward+detail files. If there are no matches, then the mail falls back to delivery to sandy@eng.acme.com, but the user is able to see a change in the To: header in their mail.