Setting Up Mail Aliases

This message is for anyone who ever edits the aliases database. I have just completed the painstaking project of documenting every alias in the database, which as a back burner project has taken over two years to get done. It is now very important that under no circumstances does anyone EVER EVER add a static alias to the database which is not properly documented and in the correct format. Ultimately there will be scripts that read the aliases file and act as a search engine, and the search engine will absolutely depend on the aliases file being in the expected format. That format is:

# One or more commment lines ending with
# the responsible person for this alias in parentheses (Bozo the Clown)
alias_name: alias_member, ...., last_alias_member

The alias itself must be a SINGLE LINE, no matter how long it is. Several related aliases can be grouped together:

# One generic comment (Responsible Person)
alias1: ...
alias2: ...
...
aliasN: ...

In particular, this means that you must obtain a one-line description of this alias from the person requesting that one be set up, and make note of who requested the alias. Note that most people I ask to describe an alias mistake the request for a request to justify that the alias is needed. This is not the point. We will set up an alias on the central post office for anyone at UCAR for any purpose as long as it does not violate UCAR policy with regard to use of UCAR resources. It doesn't have to be strictly work related but it can't be promoting any political, charitable, or commercial causes that have not been explicitly approved by UCAR management. All we need is a one-line description of the purpose of the alias that can be used by a search engine.

Aside from UCAR policy, there are only a few other criteria I use for allowing or denying an alias.

1. Do not set up aliases for individual users who don't like their user name. We have over 2000 users in our database and this can and will get out of hand in a big hurry. It also screws up the online directory, since these aliases do not show up there.
2. I dislike aliases that point to aliases maintained by another division. If we absolutely must set one up, then it must be accompanied by an "owner" alias to redirect bounces. I do not want to deal with bounces caused by errors committed by another postmaster. This refers to aliases like this:

   name: name@division.ucar.edu

   What we need then is an accompanying alias of the form:

   owner-name: divisional-sysadmin-username (or postmaster@division.ucar.edu)

3. Always use UCAR user names on the right hand side of the alias definition whenever they exist. We will not forward alias mail to a different location than the user@ucar.edu mail goes. If the user's address is wrong, it should be changed in the MEF. The reason for this is that if a user changes where s/he reads mail, we don't have to go back and change every &*$#*@! alias that user is on. Use of UCAR user names means that all alias mail automatically follows the change.

Your cooperation in following these policies would be greatly appreciated by the guy who gets blamed when anything goes wrong with the e-mail system.

These policies apply to static aliases only. Majordomo aliases are documented by means of the official list owner alias and the info file.