Previous Section Next Section

12.4 Special Aliases

The behavior of the sendmail program requires that two specific aliases (Postmaster and MAILER-DAEMON) be defined in every aliases file.[10] Beginning with V8.7 sendmail, aliases that contain a plus character can be used to route mail on the basis of special needs. Also, beginning with V8.7 sendmail, databases that allow duplicates can be declared to help automate the creation of those files.

[10] RFC2142 adds others to this list (Section 12.4.3), such as abuse, webmaster, etc.

12.4.1 The Postmaster Alias

RFC2822 requires every site to accept for delivery mail that is addressed to a user named postmaster. It also requires that mail accepted for postmaster always be delivered to a real human being—someone who is capable of handling mail problems. If postmaster is not an alias, or a real user, sendmail syslog(3)s the following error: 

can't even parse postmaster!

Unless a site has a real user account named postmaster, an alias is required in every aliases file for that name. That alias must be a list of one or more real people, although it can also contain a specification for an archive file or filter program. One such alias might look like this: 

postmaster: bill, /mail/archives/postmaster,
       "|/usr/local/bin/notify root@mailhost"

Here, postmaster is lowercase. Because all aliases are converted to lowercase for lookup, Postmaster or even POSTMASTER could have been used for equal effect.

Note that there are three aliases to the right of the colon: a local user named bill, the full path of a file onto which mail messages will be appended, and a program to notify the user root at the machine mailhost that postmaster mail has arrived on the local machine. Naturally, a user should not have to be root to read mail, so on mailhost there would be a further alias of root to the address of a normal user.

As a convention, the special name postmaster can also be that of the user who gets duplicate copies of some bounced mail. This is enabled by using the PostmasterCopy option (PostmasterCopy) in the configuration file: 

OPpostmaster               pre-V8.7
O PostmasterCopy=postmaster    V8.7 and above

To disable sending copies of bounced mail to a special user (perhaps to protect privacy), omit this option from the configuration file.

Note that V8 sendmail does not send a copy of error mail to the postmaster if the error mail includes a Precedence: header with a value less than zero, such as junk, bulk, or list used by mailing lists.

Also note that some sites define this user as one who is always aliased to a filter program in the aliases file. For example, if the PostmasterCopy option is declared as: 

OPmail-errors               pre-V8.7
O PostmasterCopy=mail-errors    V8.7 and above

and the corresponding aliases file entry is declared as: 

mail-errors: "|/etc/mail/filter postmaster"

a program filter can be designed that discards all common error messages, such as mistyped addresses, and forwards what remains to postmaster.

Many sites have developed just such filters. One is distributed with the V8 sendmail source in the file contrib/mmuegel. Written by Michael S. Muegel of Motorola's Corporate Information Office, it is a shar(1) file of several useful perl(1) scripts. One (postclip.pl) is a tool that filters out the body of bounced mail messages to prevent postmasters from potentially violating the privacy of senders.[11] It tries to retain all headers, regardless of how deeply they are buried in what appears to be the message body.

[11] Note that this can also be done with the nobodyreturn keyword (See this section) with the PrivacyOptions option.

12.4.2 The MAILER-DAEMON Alias

When mail is bounced, the notification of failure is always shown as being from the sender whose name is defined by the $n sendmail macro (see $n). Traditionally, that macro is given the value mailer-daemon. The following, for example, shows how to use the confMAILER_NAME mc macro to assign the value mailer-daemon to the $n sendmail macro: 

define(`confMAILER_NAME', `mailer-daemon')

That tradition is enforced by the fact that if $n is not defined, it defaults to mailer-daemon.

There needs to be an alias for whatever name is defined for $n because users occasionally make the mistake of replying to bounced mail. Two typical choices (one or the other) are: 

mailer-daemon: postmaster
mailer-daemon: /dev/null

Here, the name to the left of the colon should be whatever was defined for $n in the configuration file, traditionally (and recommended to be) mailer-daemon. The first alias forwards all mailer-daemon reply mail to the postmaster. Many site administrators prefer the second, which discards such mail by using /dev/null.

12.4.3 Other Possible Required Aliases

Depending on the nature of your site, other aliases might be required, usually on the basis of conventions and courtesy rather than by formal rules.[12] As with Postmaster, these aliases should result in delivery of mail messages to an eventual human who can handle and fix problems.

[12] RFC2142 defines many local address names that are mandatory, such as abuse, and requires that they be case-insensitive. Currently, sendmail only considers postmaster in a case-insensitive manner. Future releases of sendmail will likely add other names that should be considered case-insensitive.

If you are running a web server you should maintain an alias for the address webmaster. When problems are discovered with your web site, such as missing pages, missing images, or bad links, outsiders will almost always send email to webmaster at one of your web servers. If you run many web servers, you might want to put the following in the aliases file of each: 

webmaster: webmaster@sysadmin.host.domain

Then, on the central system administration host, sysadmin.host.domain you could install an alias for webmaster that delivers to a real person.

If you are in the business of sending email to others as a service, you will almost certainly need an alias for the address abuse. Nobody, including you, would ever send spam email, but unintended email can always find its way out, regardless of the protections you put in place. If you are a business, perhaps one of your employees will send spam email. Or if you are a nonprofit ISP, one of your members might. But, regardless of how it happens, the offended recipient will almost always send a complaint to the address abuse at your site: 

abuse:        "|/usr/local/bin/handle-abuse.pl"

The intention here is to pipe mail to abuse through a filter that will convert notification into a job list for some group.[13] At your site, you might find it more useful to deliver abuse messages to a human.

[13] We illustrate with a fictional filter program.

As the Internet grows, new services will undoubtedly cause you to maintain new and currently unforeseen addresses. Each time you add a new service, consider the need to maintain a special email address in support of that service.

12.4.4 Plussed Detail Addressing

Plussed detail addressing is a simple way to achieve more versatile aliasing. It is available only with V8.7 sendmail and above, and it requires that you use a configuration file that comes with V8 sendmail. To illustrate its use, consider the need to have mail routed to different sets of administrators depending on how the address root is augmented: 

root: hans, george
root+db:   root, dbadmin@server.db.here.edu
root+*:    root, root@here.edu

Here, the first line shows a normal sort of alias in which mail sent to root will instead be delivered to the local users hans and george. The second line is still not all that special because we could as easily have used an alias such as root_db to accomplish the same thing. It sends mail to root+db to the local root users and to the database administrators in another department, dbadmin@server.db.here.edu.

The third line is where things start to get interesting. The +* in it will match anything or nothing following the plus, so mail sent to root+ will be sent both to the local root users and to the central administrators at root@here.edu. But so will anything following the plus that is not db, such as root+foo.

If the +* form is omitted:

root: hans, george
root+db:   root, dbadmin@server.db.here.edu

the default for plussed addresses other than root+db becomes root. That is, when sendmail looks up a plussed address (for example, root+foo) it does so in the following order:

  • Look for an exact match. Does root+foo match root+db?

  • Look for a wildcard match. Does root+* exist? If so, use that alias for root+foo.

  • Look for a base match. Does the root of root+foo exist as an alias? If so, use that alias for root+foo.

Note that plussed users is a simple mechanism that is intended to solve simple needs. In distributing a common aliases file to many machines, for example, plussed users can furnish a hook that allows customization based on simple alias extensions. Because plussed users is simple, attempts to extend it to handle complex needs will likely fail. If your needs are complex, consider using the User Database (userdb) or writing custom hooks in checkcompat( ) (Appendix D) instead.

Beginning with V8.12, a new mc feature allows you to preserve the plus sign and what follows it, and to pass that whole address to your delivery agent. That feature is called preserve_local_plus_detail (FEATURE(preserve_local_plus_detail)), and is useful with cyrusbb, cyrus, and other delivery agents.

12.4.5 Duplicate Entries and Automation

Ordinarily, duplicate local names on the lefthand side of the colon in an alias file will result in an error. For example, consider this abstract from an aliases file: 

staff: bob
staff: george

Running newaliases on this file would produce the following error message and would cause the first entry to be ignored: 

Warning: duplicate alias name george

Sometimes, however, it is advantageous to produce an alias file with duplicates. Consider this abstract from a script that adds new users: 

if [ $GROUP = "staff" ]
then
        echo "staff: $USER" >> /etc/aliasdir/groups
fi

Here, we seek to add the user whose login name is stored in $USER to the mailing list called staff. To prevent sendmail from complaining, we declare the /etc/aliasdir/groups file like this in the configuration file: 

O AliasFile=dbm:-A /etc/aliasdir/groups

Here, the dbm tells sendmail this is a ndbm(3)-type file (it could also be btree or hash for db(3)-type files). The -A switch tells sendmail to append duplicates rather than rejecting them. Too illustrate, revisit the earlier alias file: 

staff: bob
staff: george

The first alias line is read and stored normally with this key and value pair: 

staff    bob
         
key     value

The second line is then appended to the first line, because of the -A switch, to form: 

staff    bob,george
         
key      value

The comma is intelligently inserted by sendmail.

Although this technique can simplify the maintenance of some alias files, it should not be overused. Each append requires the prior entry to be read, the space for it and the new entry to be allocated, the old and new entries to be concatenated, and the result to be stored in such a way as to replace the original. This process slows down sendmail noticeably when it rebuilds large files with many duplicates.

As an alternative, consider using the :include: mechanism described in the next chapter (Section 13.2).

    Previous Section Next Section