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.