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"

• "Solaris sendmail Differences"

• "How Mail Addressing Works"

• "How sendmail Interacts With a Name Service"

• "Other Mail-Related Topics"

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:

• A new system for building configuration files. Instructions for using the new system is included in "Building a sendmail Configuration File".

• The permissions and the ownership of several directories have been changed in order to increase security. When the Solaris 7 release is installed, /etc/mail and /var/spool/mqueue and the parent directories will have the correct permissions.

• Increased security on .forward files requires that the default shells (as listed in /etc/passwd) of all users trying to employ a .forward file to forward mail to a program or to a file must be listed in /etc/shells for the file to be accessed. See "How to Create and Populate /etc/shells" for more information.

• Additional restrictions have been put in place on .forward and :include: files. These files and the directory structure that they are placed in cannot be group- or world-writable. A script called /usr/lib/mail/sh/check-permissions is included to help identify files with unsafe permissions.

• The use of .forward files has been enhanced. A .forward.hostname file can be used to reroute mail sent to a user at a specific host. Also, a .forward+detail file can be used to determine who is using an alias. These files are described in ".forward Files".

• The way sendmail acts when an owner alias exists has changed. A full description of the change can be found in "Mailbox". You can download a script called check-aliases.sh, which checks all alias files listed in /etc/mail/sendmail.cf for misconfigured owner-aliases.

• The sendmail program requires a fully qualified host name when starting. A script called /usr/lib/mail/sh/check-hostname is included with the release to identify host configurations that do not support fully qualified host names.

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.

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.

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.

• SOLARIS=20700 -- Support for the Solaris 7 operating environment

• NDBM -- Support for ndbm databases

• NEWDB -- Support for db databases

• NIS -- Support for nis databases

• NISPLUS -- Support for nisplus databases

• USERDB -- Support for the User database

• MAP_REGEX -- Support for regular expression maps

• SUN_EXTENSIONS -- Solaris-specific flag; support for Sun-specific extensions included in sun_compat.o

• VENDOR_DEFAULT=VENDOR_SUN -- Solaris-specific flag; selects Sun as the default vendor

• USE_VENDOR_CF_PATH -- Solaris-specific flag; allows for the configuration file to be placed in /etc/mail

• _FFR_MAXALIASRECURSION_OPTION -- Solaris-specific flag; enables selection of MaxAliasRecursion option

• _FFR_MAX_MIME_HEADER_LENGTH -- Solaris-specific flag; enables selection of MaxMimeHeaderLength option

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.

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.

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:

• The current host is not authorized to send packets directly to a host outside the mail domain.

• The mail host is capable of forwarding the mail to an authorized host that can transmit packets directly to an external host. (In fact, the mail host can itself be an authorized host.)

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:

• A.B.C.D

• B.C.D

• C.D

• D

When first established, the mail domain name is often identical to the name service domain. As the network grows 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:

• mailhost - Some name service configurations satisfy this requirement automatically.

• Full host name (for example, smith.admin.acme.com) - Many name service configurations satisfy this requirement.

• Short host name (for example, smith) - sendmail must connect to the mail host to forward external mail. To determine if a mail address is within the current mail domain, gethostbyname() is invoked with the full host name. If the entry is found, the address is considered internal.

  NIS, NIS+, and DNS all support gethostbyname() with a short host name as an argument, so this requirement is automatically satisfied.

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.

mail domain name -- If you are setting up NIS as the primary name service, sendmail automatically strips off the first component of the NIS domain name and uses the result as mail domain name. For example, ebs.admin.acme.com becomes admin.acme.com.




mail host host name -- You must have a mailhost entry in the NIS host map.




full host names -- The normal NIS setup does not "understand" the full host name. Rather than trying to make NIS understand the full host name, turn off this requirement from the sendmail side by editing the sendmail.cf file and replacing all occurrences of %l with %y. This turns off sendmail's inter-domain mail detection. As long as the target host can be resolved to an IP address, a direct SMTP delivery is attempted. Make sure that your NIS host map does not contain any host entry that is external to the current mail domain. Otherwise, you need to further customize the sendmail.cf file.




matching full and short host names -- Follow the previous instructions on how to turn off gethostbyname() for a full host name.




multiple NIS domains in one mail domain -- All NIS host maps under a common mail domain should have the same set of host entries. For example, the host map in the ebs.admin.acme.com domain should be the same as the host map in the esg.admin.acme.com. Otherwise, one address might work in one NIS domain but fail in the other NIS domain.

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.

mail domain name -- If you are setting up NIS as the primary name service, sendmail automatically strips the first component of the NIS domain name and uses the result as mail domain name, for example, ebs.admin.acme.com becomes admin.acme.com.




mailhost host name -- When the DNS forwarding feature is turned on, queries that NIS cannot resolve are forwarded to DNS, so there is no need for a mailhost entry in the NIS host map.




full host names -- Although NIS does not "understand" full host names, DNS does. This requirement is satisfied when you follow the regular procedure for setting up NIS and DNS.




matching full and short host names -- For every host entry in the NIS host table, you must have a corresponding host entry in DNS.




multiple NIS domains in one mail domain -- All NIS host maps under a common mail domain should have the same set of host entries. For example, the host map in the ebs.admin.acme.com domain should be the same as the host map in the esg.admin.acme.com. Otherwise, one address might work in one NIS domain but fail in the other NIS domain.

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.

mail domain name -- If you are setting up NIS+ as your primary name service, sendmail can look up the mail domain from the NIS+ sendmailvars table, a two-column NIS+ table with one key column and one value column. To set up your mail domain, you must add one entry to this table. This entry should have the key column set to the literal string maildomain and the value column set to the your mail domain name (for example, admin.acme.com). Although NIS+ allows any string in the sendmailvars table, the suffix rule still applies for the mail system to work correctly. You can use nistbladm to add the maildomail entry to the sendmailvars table. For example:

nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain>

Notice that this mail domain is a suffix of the NIS+ domain.



mailhost host name -- You must have a mailhost entry in the NIS+ hosts table.




full host names -- NIS+ "understands" the full host name. Following the regular NIS+ setup procedure satisfies this requirement.




matching full and short host names -- To satisfy this requirement, you can duplicate the entries in the host table, or you can enter all host entries in the user name service domains into a master host table at mail domain level.




multiple NIS domains in one mail domain -- To satisfy this requirement, you can duplicate the entries in all the host tables, or you can type all host entries in the user name service domains into a master host table at mail domain level. Because you are merging (logical or physical) multiple host tables into one host table, the same host name cannot be reused in the multiple name service domain sharing a common mail domain.

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.

mail domain name -- If you are setting up NIS+ as your primary name service, sendmail can look up the mail domain from the NIS+ sendmailvars table, a two-column NIS+ table with one key column and one value column. To set up your mail domain, you must add one entry to this table. This entry should have the key column set to the literal string maildomain and the value column set to the your mail domain name (for example, admin.acme.com). Although NIS+ allows any string in the sendmailvars table, the suffix rule still applies for the mail system to work correctly. You can use nistbladm to add the maildomail entry to the sendmailvars table. For example:

nistbladm -A key="maildomain" value=<mail domain> sendmailvars.org_dir.<NIS+ domain>

Notice that this mail domain is a suffix of the NIS+ domain.




mailhost host name -- If your network uses both NIS+ and DNS as the source for the host database, you can put the mailhost entry in either the NIS+ or DNS host table. Make sure that your users list NIS+ and DNS as the source for the host database in the /etc/nsswitch.conf file.




full host names -- Both NIS+ and DNS "understand" full host names. Following the regular NIS+ and DNS setup procedures satisfies this requirement.




matching full and short host names -- For every host entry in the NIS+ host table, you must have a corresponding host entry in DNS.




multiple NIS domains in one mail domain -- To satisfy this requirement, you can duplicate the entries in all the host tables, or you can type all host entries in the user name service domains into a master host table at the mail domain level.

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.

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.

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.