A: I'm not sure if you are talking about the MTA (Mail Transfer Agent, aka sendmail) or the MUA (Mail User Agent, aka Netscape Mail). However, there are solutions for both. Most graphical clients have built-in filtering that you can use.

On the server side, you can use a program called procmail. Procmail is installed by default on most Linux systems, and can be used system-wide or user by user. Procmail is a powerful program that uses recipes to define filtering mechanisms that result in certain actions.

For example, you can define a filter that states that any mail coming from the user bgates@microsoft.com is automatically redirected to /dev/null. Such a filter would look something like this:

:0
* ^From.*bgates@microsoft.com
{
:0
/dev/null
}

All procmail filters are kept in a procmailrc file. The procmailrc file is placed in /etc for global declarations, or in $HOME/.procmailrc for user declarations. $HOME is a variable for the home directory of the user. A typical procmailrc file looks like this:

#
#
# Begin /etc/procmailrc
#
#
ORGMAIL		/var/spool/mail/$LOGNAME
MAILDIR		$HOME/
SENDMAIL		/usr/sbin/sendmail
:0
* ^From.*bgates@microsoft.com
{
:0
/dev/null
}
#
# End /etc/procmailrc
#

MAILDIR is the current directory used when procmail is executing. I have declared that MAILDIR will be the / (root) of the user's home directory.

The SENDMAIL variable tells procmail where the sendmail MTA program is. In this case: /usr/sbin/sendmail.

As I mentioned, procmail is a very powerful program. Your recipes can be used to generate a slew of useful actions. What if we don't want to send all the email from bgates@microsoft.com to /dev/null? What if we want to keep it for an upcoming antitrust trial? To do this, we could use the following recipe instead:

:0
* ^From.*bgates@microsoft.com
{
:0
antitrust
}

This recipe will cause all email from bgates@microsoft.com to be saved to a file called antitrust. The file will be located in the area where the MAILDIR variable is set. To make the recipe a little more useful, we could set the file to be saved in a directory that is below the MAILDIR variable directory. For example:

:0
* ^From.*bgates@microsoft.com
{
:0
mail/antitrust
}

This recipe will cause the antitrust file to be used within the $HOME/mail directory. You may want to set this as global so you don't have a bunch of mail files within the / (root) of your home directory.

You can write recipes for procmail to support multiple conditions. Let's take the following:

:0
* ^From.*bgates@microsoft.com
* ^Subject:.*competition
{
:0
mail/antitrust
}

As before, we are using the bgates recipe. This time, if we receive email from bgates@microsoft.com that contains the subject "competition," the recipe will take action and move the email to the mail/antitrust location.

You can initiate multiple actions within a recipe by doing the following:

:0
* ^From.*bgates@microsoft.com
* ^Subject:.*competition
{
:0 c
! justicedept@us.gov
:0
mail/antitrust
}

The recipe now will forward all email from bgates@microsoft.com with the subject "competition" to justicedept@us.gov, and move the email message to mail/antitrust.

Using multiple recipes within procmailrc can be accomplished by doing the following:

:0
* ^From.*bgates@microsoft.com
* ^Subject:.*competition
{
:0 c
! justicedept@us.gov
:0
mail/antitrust
}
:0
* ^From.*sexcity
{
:0
/dev/null
}

The first recipe is the one we used for the earlier examples. The second will take any email from sexcity and dump it to /dev/null. You may have noticed that I did not put a domain on the end of sexcity. If you don't specify a domain in the recipe, it will grab all email from "sexcity" that comes to your box, regardless of domain. You should be careful with this type of recipe if you host multiple domain names on your machine.

As you can see from the above examples, procmail is not difficult, but you'll want to be careful. If you make a mistake in your procmail configuration, you can blow away your entire email configuration. Test each recipe and watch what happens with your email. Once you get it locked down, however, it works great.

One last point I need to make is that you must configure sendmail to understand that procmail exists, and to accept procmail as a mailer for the sendmail daemon. Configuring sendmail to use procmail isn't hard, but it's more involved than what the scope of this article will allow. Consult the procmail man pages and the sendmail FAQ for more information. As a side note, sendmail itself provides facilities to aid spam reduction, as well.

That's it for this week's Ask the Geek.

• Spam About the "CAN-SPAM" Act...from a US Government Office

• Procmail
• Sendmail