UNIX System Administration Handbook - Evi Nemeth [328]
The target program uses sendmail’s queue directory as its working directory, which some shells object to. If you try this approach and it doesn’t work, look in the documentation for the mailer D= flag to see how to fix it.
Mailing to programs is a major potential security hole. To be safe, don’t use /bin/sh as your program mailer; use sendmail’s restricted shell, smrsh, instead. See Security and sendmail on page 607 for more information about smrsh.
Examples of aliases
Here are some typical aliases that a system administrator might use.
# Required aliases10
postmaster: trouble, evi
postmistress: postmaster
MAILER-DAEMON: postmaster
hostmaster: trent
abuse: postmaster
webmaster: trouble, trent
root: trouble, trent
usenet: newsmaster
# include for local trouble alias
trouble: :include:/usr/local/mail/trouble.alias
troubletrap: "/usr/local/mail/logs/troublemail"
tmr: troubletrap,:include:/usr/local/mail/tmr.alias
# sysadmin conveniences
diary: "/usr/local/admin/diary"
info: "|/usr/local/bin/sendinfo"
# class aliases that change every semester
sa-class: real-sa-class@nag
real-sa-class: :include:/usr/local/adm/sa-class.list
In this example, we would like users from all over campus to be able to send mail to a single alias “trouble” whenever problems occur. Problem reports should always be routed to an appropriate group of local system administrators. In particular, we’d like to set up the mail aliases so that
• Trouble mail always goes to an appropriate group.
• A single version of the aliases file is used on all hosts.
• Individual admin groups control their own distribution lists.
• A copy of all trouble mail goes to a local log file for each group.
The configuration above satisfies these goals by taking the definition of the trouble alias from a file on each machine. Mail sent to the addresses trouble@anchor and trouble@boulder would end up in different places even though anchor and boulder use the same /etc/mail/aliases file.
Trouble mail is usually handled on one particular machine in each locale. For example, the trouble.alias file on a slave machine could contain the address
trouble@master
to make trouble mail go to the appropriate master machine.
When a trouble message is resolved, it is sent to the alias “tmr”, which stands for “trouble mail readers.” The tmr alias archives the message to the troubletrap alias and also sends it to a list of users taken from a file on the master machine. Adding novice administrators to the tmr list is a great way to let them see the support questions that arise, the administrators’ replies, and also the proper sycophantic tone that should be used with users (i.e., customers).
This mechanism is just the tip of the iceberg of a complete trouble ticket tracking system called queuemh, which is based on the mh user agent.
The sa-class alias has two levels so that the data file containing the list of students only needs to be maintained on a single machine, nag. The sabook alias example earlier should really have this same type of indirection so that the include file does not need to be replicated.
The “diary” alias is a nice convenience and works well as a documentation extraction technique for squirrelly student sysadmins who bristle at documenting what they do. Sysadmins can easily memorialize important events in the life of the machine (OS upgrades, hardware changes, crashes, etc.) by sending mail to the diary file. Don’t put the file on a filesystem that contains your log files; that would allow hackers to fill up the filesystem and prevent syslog from writing log entries (thus covering their tracks).
Mail forwarding
The aliases file is a system-wide config file that should be maintained by an administrator. If users want to reroute their own mail (and your site doesn’t use POP