sendmail Aliasing

Aliasing is a method by which mail to a specific address is redirected somewhere else. Aliases can be redirected to one or more users, a file, a program, or a combination of these. Aliasing is often used to forward mail to a user's preferred mail drop, to filter incoming mail, to allow users to be referred to by more than one address, and to define mailing lists (mailing lists will be discussed in more detail in a later module). Aliases can be defined by either the system administrator or the user.

The aliases File

System-wide aliases can by defined by the system administrator in sendmail's aliases file. The location of this file is specified in the sendmail.cf (change it by defining the m4 macro ALIAS_FILE in your .mc), but it is typically in /etc. Table 1 (also available as plain text) shows the default location of this file on the systems covered in this course.

The format of the aliases file is as follows:

local-name: recipient1,recipient2,...

local-name is the address to alias, and the list of comma-separated addresses after the colon are all the recipients of that alias. Lines beginning with white space are continuation lines, and lines beginning with a "#" are comments and ignored by sendmail. The following are some example aliases from an aliases file:

# Unix Workstation Support Group
ajc: ajc@indiana.edu
brier: brier@indiana.edu
leighg: leighg@indiana.edu
rtompkin: rtompkin@indiana.edu
uthuppur: uthuppur@indiana.edu

group: ajc,brier,leighg,rtompkin,uthuppur

The first line is a comment, ignored by sendmail, as is the blank line before the group alias. The rest of the lines are aliases, which explain a lot about how aliasing works.

The first five aliases (ajc, brier, leighg, rtompkin, and uthuppur) are for those users, and they simply redirect each user's mail to user@indiana.edu. So, instead of being delivered locally, mail to each of those users will go to them @indiana.edu (which, incidentally, is another alias on IU's post office machines, which redirects mail to the user's preferred email address here at IU).

The last alias, group, is a bit more interesting in terms of demonstrating how aliasing works. The group alias does not correspond to an actual user of the system. Instead, it is an alias pointing to a group of users (in this case, the members of the UWSG). So, an alias can direct mail to more than one address, as long as addresses are separated by commas.

Now, one might think that mail sent to group would be delivered to each person in the alias on the local machine, since the addresses are specified as local (they don't contain any host information). However, this is not the case. Each member of the group alias is itself an alias, which points to user@indiana.edu. So, aliases are recursive. If, instead, there were not individual aliases for each of those users, mail would be delivered locally.

This last example brings up something to note. Aliases do not have to represent users in the passwd file, as the group alias demonstrates. Remember this when adding new users to the system. Check both the passwd file and the aliases file to make sure that a new user's username is unique. If there is already an alias (previously not representing an actual user) of the same name as the user which an administrator adds, then that user's mail will be delivered to the alias, rather than to the user, definitely not what was intended.

The alias file should always contain certain aliases. The alias files shipped with most systems usually contain these aliases, but it is important to check them and make sure. Specifically, the postmaster alias should point to whoever administrates the system (this is often root, but doesn't have to be). Also, sendmail itself needs an alias called MAILER-DAEMON, for sending automatic messages. MAILER-DAEMON is often aliased to the postmaster alias. Any of the pseudo-users in the passwd file (e.g. bin, sys, daemon, nobody) should also have aliases.

In general, it is a good idea to point aliases which do not represent humans (such as all of those mentioned above) to an actual human being who reads mail often. Most administrators point these types of aliases to the postmaster alias, and then point postmaster to themselves, or possibly an alias representing a group of system administrators. Also, don't forget to make sure that mail sent to root goes to a human, since most administrator's don't actually log in as root too often.

Special Aliases

As well as redirecting mail to users, aliases can redirect mail:

• To be appended to a file.
• To be sent to the standard input of a program.
• To a file which contains a list of addresses for which the mail should be delivered.

Redirecting To Files

To append messages to a file, the target of an alias must be an absolute pathname (i.e. it must begin with a slash character (/), which is, in fact, how sendmail recognizes it as a file). Mail messages are appended to this file, just as they are appended to the mail spool. This file must be writable by sendmail, so it must be either world-writable, or setuid but not executable. On many systems, allowing the file to be writable by the mail group will work as well.

Please note that when choosing setuid but not executable for the permissions of the file, the file may not be owned by root. Although not mentioned in any of the documentation we've found, sendmail (at least version 8.7.5) seems to have a security check whereby if the file is owned by root, sendmailwill not append to it. Just make it owned by another user.

For example, as a convenience, a sysadmin group might want to have an alias to which they could send mail which would then be dropped into a file as a record of the goings-on of the system:

admin-log: "/usr/local/adm/admin-log"

As an added bonus, this file is in Unix mailbox format, so members of the group could open it up as a mail folder to keep abreast of sysadmin activities.

Redirecting To Programs

To send messages to the standard input of a program, the target of an alias must begin with a pipe character (|) followed by the full pathname of the program and it's arguments. For example, the popular mailing list manager, majordomo, uses aliases like the following:

majordomo: "|/is/mail/majordomo/wrapper majordomo"

In this case, mail sent to majordomo is sent to the program /is/mail/majordomo/wrapper with the argument majordomo. Majordomo itself will be discussed further in a later section.

An important thing to note about redirecting mail to programs is that sendmail goes through a process of discarding duplicate recipients. If the same recipient is listed more than once, sendmail discards any duplicates and only delivers the mail one time.

Normally this is just the right thing, but in the case where the recipient is a program, it is often not. This is often a problem for users who forward their mail to a mail filtering program such as procmail. If three recipients of a message all have their mail forwarded to "|/usr/local/bin/procmail", sendmail sees this as one address and only delivers one message.

To defeat sendmail's duplicate discarding, make every address unique to the user. In the case of procmail, users forward their mail with something like "|/usr/local/bin/procmail #username" where the #username is a comment to procmail but serves to uniquely identify the address to a user to sendmail.

Redirecting To Included Files

To redirect mail to a file which contains a list of addresses for which the mail should be delivered, use the :include: directive. This allows the recipients of the alias to be taken from a file. For instance, for a large group of system administrators, an alias might look like:

sysadmins: :include:/usr/local/adm/sysadmins.members

The :include: directive is often used to maintain simple mailing lists. This usage will be discussed further in a later module.

The Alias Database

Although administrators modify the aliases file to configure aliases, the system doesn't actually use it. To increase speed and efficiency in parsing aliases, sendmail uses a database derived from the aliases file instead.

The files that make up the database are aliases.dir and aliases.pag in the same directory as the aliases file. The database files are only used by sendmail, alias configuration is still done in the aliases file, but remember to rebuild the aliases database each time you modify the file. To rebuild the alias database from the aliases file, issue the command newaliases (this is really just another way of invoking sendmail -bi, either will work).

.forward Files

While the aliases file is used for system-wide redirection of mail, users may redirect their own mail with a .forward file in their home directory. .forward files are often used by users to forward their mail to their preferred mail drop, or to send mail messages through a filtering program such as procmail or MH's slocal.

A .forward file contains a comma or newline separated list of recipients. These recipients can be users, or files to be appended to, or programs, just as in the aliases file. For example, examine the following .forward file:

\brier,"/home/brier/mail.bak","|/usr/sbin/vacation brier"

Here, the user brier is forwarding his mail to three different places. Putting a backslash (\) in front of the username in the first recipient is a special syntax for delivering mail to the local mail spool with no further aliasing. So, one copy of the message goes to the mail spool. The second recipient, "/home/brier/mail.bak" appends another copy of the mail to the file, basically providing a backup mail spool. The third recipient, "|/usr/sbin/vacation brier", sends a third copy of the message to the popular vacation program, which responds to the sender explaining that our faithful example user is on vacation. Notice that in the vacation example, the username is given to the vacation program as an argument, to uniquely identify this recipient to sendmail.

Terms used: mail drop, filter, sendmail.cf, m4, standard input, parse.