An `alias' is a way to set up a pseudo-address that simply directs mail to another (single) address. There are two kinds of aliases: MUA aliases and MTA aliases.
An MUA alias is one you set up in your MUA as a kind of personal shorthand. Other people will not be able to see or use this alias. For example, you could write:
alias esr Eric S. Raymond <esr@thyrsus.com> |
in your mutt configuration file. This would tell mutt that when it sees `esr' in an address line, it should behave as through you had typed `esr@thyrsus.com', Or you can type `mutt esr' and the expanded address will be automatically filled in on the `to' line.
An MTA alias is one your MTA expands; it will be usable by everyone, both on your machine and remotely. To create MTA aliases you must modify a system file, usually but not always /etc/aliases or /etc/mail/aliases (the location depends on your MTA). It may be instructive for you to look at the the aliases on your system; it should contain a number of standard aliases such as `postmaster'.
Your MTA may also allow the target of an alias to be a filename, which will be treated as a mailbox the mail is to be appended to (this is useful for archiving mail). It may also allow the target of an alias to be a program, in which case mail to that alias will be passed to an instance of the program on its standard input.
MTA aliases usually require administrator privileges to set up. But it is desirable for mail users to be able to set up forwarding of their own mail without administrator intervention.
To support this, most MTAs follow sendmail's lead and look for a file called .forward in your home directory. The contents of this file is interpreted like the target of an alias which should receive all your mail. The most common use for this facility is to redirect your mail to an account on another machine.
Another common use for the .forward facility is to pass your mail to a `vacation' program. A vacation program reads incoming mail and automatically generates a canned reply to it; they are so called because the most common form of canned reply is to inform the sender that you are on vacation and will not be reachable until a given date.
There is no one standard vacation program that is in universal use. There are two good reasons for this: one, that such a program is very easy to write as a shellscript or filter rule (see below); and two, that vacation programs interact badly with mailing lists.
You should temporarily unsubscribe from all mailing lists you are on before setting up auto-answering; otherwise, all members of the mailing lists mail find they are being flooded with canned messages by your vacation program. This is considered very rude behavior and will guarantee you quite a frosty reception on your return.
A mailing list is a pseudo-address that sends mail to more than one user.
In its simplest form, mailing list is just an MTA alias with more than one recipient. Some small mailing lists are maintained this way. Sendmail assists by supporting a syntax in /etc/aliases that includes the contents of a given mailing list file in the target side of an alias. It looks like this:
admin-list: ":include:/usr/home/admin/admin-list" |
with the advantage that the admin-list file can live in unprivileged-user space somewhere (root is only needed to set up the original inclusion). Some other MTAs have similar features.
These simple lists are commonly called `mail reflectors'. There are a couple of problems with mail reflectors. One is that bounce messages from failed attempts to broadcast goes to all users. Another is that all subscriptions and unsubscriptions have to be done manually by the mailing list administrator.
A kind of software called a mailing list manager has evolved to address these problems and other related ones. Its most important function is to permit mailing list users to subscribe and unscubscribe without going through the list maintainer.
A mailing-list manager keeps its own user-list information and hooks up to the MTA through a program alias in /etc/aliases. For example, if the admin-list above were going through the mailing list manager called SmartList on a sendmail system, a portion of /etc/aliases might look like this:
admin-list: "|/usr/home/smartlist/bin/flist admin-list" admin-list-request: "|/usr/home/smartlist/bin/flist admin-list-request" |
Note that this is a pair of aliases. It is conventional for real mailing lists to have a request address to be used for user subscription and unsubscription requests. It is considered rude and ignorant to send subscription/unsubscription requests to the main address of such a list -- don't do it.
The robot sitting behind the request address may offer other features besides just subscription/unsubscription. It may respond to help requests, allow you to query who is on the list, or give you automated access to list archives. It may also allow list administrators to restrict posting to known members, set the list to auto-subscribe nonmembers when they first post, or set various security policy options. Mailing-list managers differ primarily in the design and range of these secondary features.
Unfortunately, the format for sending commands to mailing-list request robots is not standard. Some expect commands in the subject line, some ignore the subject line and expect commands in the message body. You need to pay attention to the response mail you get when you first subscribe; it's a good idea to save such mail to a subscriptions mailbox for later reference.
The most important mailing-list managers to know about are majordomo, listserv, listproc, and smartlist; majordomo is the most popular by a considerable margin. Recently, mailman, a list manager with a rather nice Web-based signon/signoff/administration interface, has become very popular and may be in the pricess of obsolescing the older programs. There is a rather comprehensive list of such packages on the Web.
For more about mailing list managers, consult the resources at the List-Managers Mailing List, including the FAQ (note: this list is not appropriate for how-to questions).
A mail filter is a program that sits between your local delivery agent and you, automatically dispatching or rejecting mail before you see it.
Mail filters have a number of uses. The most important are spam filtering, dispatching to multiple mailboxes by topic or sender, and auto-answering mail.
Typically, you set up mail filtering by putting a program alias for the filter program in your .forward file, and writing a file of filtering rules. The format and location of the filter rules file varies between filter programs.
There are good feature summaries of the three major mail filters (procmail, mailagent, and deliver) in part 3 of Chris Lewis's Email Software Survey. The most popular of these is (despite its rather nasty rule syntax) procmail, which is universally present on Linux systems (and, indeed, is generally used as the system's local delivery agent).
Spam is sometimes known as `UCE' (Unsolicited Commercial Email) or `UBE' (Unsolicited Bulk Email). As these names imply, it is an obnoxious form of advertising that stuffs your mailbox with form letters. (The term `spam' comes from a Monty Python's Flying Circus skit in which a choir of Vikings endlessly repeats the chant "Spam spam spam spam...").
Most spam seems to consist of solicitations for pyramid schemes, ads for pornography, or (annoyingly) attempts to sell spam-sending programs. A few individual spams (like MAKE MONEY FAST or the Craig Shergold postcard hoax) have been so persistent as to become legendary. Spam tends to be both verbose and illiterate. It's a waste of time and a huge waste of network bandwidth.
The spam epidemic seems to have peaked in mid-1997 and been slowly in decline since, but it can still be a serious annoyance. If you're being deluged with spam, get educated. Browse the Fight Spam on the Internet! page. The Death To Spam! page is particularly effective on methods for stopping or backtracking spam.