Over the years, spam has become a reality of the Internet, and receiving it has become something that too many IT pros simply accept as a part of the e-mail landscape. The reason behind this course of action is that too many antispam programs are faulty, creating lost mail while still allowing some spam to get through. With Tagged Message Delivery Agent (TMDA), however, there are no such mistakes. In this Daily Drill Down, you’ll see how to set up and configure TMDA so that your e-mail is spam-free.

Background on antispam programs
There are many antispam programs out there, each with its own strengths and weaknesses. Most antispam solutions work on the “Allow everything that is not explicitly denied” principle, otherwise known as a blacklist-centric approach. This strategy means that mail will be permitted unless it meets certain criteria for deletion. Unfortunately, this approach sometimes deletes nonspam items (known as false positives) and it can also periodically allow spam to make it through to your inbox. Despite its inadequacies, this is the most popular approach.

Another strategy is the whitelist-centric approach, which works in an opposite fashion. This approach denies all mail except for mail that meets certain whitelist criteria. This is the “Deny everything that is not explicitly allowed” approach. It also works on a confirmation system. This means that if someone who is not in your whitelist tries to e-mail you, that sender must respond to a confirmation message, which simply asks the sender to reply to a robot server indicating that the e-mail is not unsolicited bulk e-mail. This strategy also requires senders to use valid e-mail addresses, something most spammers do not do. Very few programs use this particular approach to fight spam, but it is arguably the most effective method of combating it. TMDA is a whitelist-centric approach that can help to eradicate the spam in your inbox. Here’s how you can use it to your advantage.

Installing TMDA
TMDA is a series of programs written in Python. In order to install TMDA, you must have Python version 2.2 or higher installed on your machine. You also must have shell access to your incoming mail server, which means that TMDA will not work effectively with e-mail addresses such as hotmail. On the plus side, TMDA will stop spam at the server level, so you will never have to download spam, which will save you a little bandwidth. Other spam solutions filter on the client system, which means you end up downloading the mail to filter it.

You will have to install TMDA on both the client system and the server. The server installation will work on defined incoming filters, holding unconfirmed messages in a pending queue. On the client system, you will use TMDA to tag your outgoing mail. This will allow TMDA to change your e-mail address based on certain outgoing filters.

To begin, you have to download TMDA. As of this writing, 0.61 is the latest version. Download the tar archive and, assuming you have root access on both the client and server systems, install TMDA site-wide so that all users can take advantage of it. You can also download RPM or DEB packages that might help to ease the installation process.

Once you have downloaded the package, decide where you want TMDA to live. It does not, by default, install into the /usr directory hierarchy but is executed from the source directory instead. You may want to uncompress it in the /usr/localdirectory tree. When you uncompress it, you will have a directory called /usr/local/tmda-0.61. Change to this directory and execute:
# ./compileall

You will be executing the TMDA programs from the /usr/local/tmda-0.61/bin directory. For those users who will be using TMDA, you may wish to add this directory to their path. If this will be a personal versus a site-wide installation, you can install TMDA directly into your home directory.

Configuring TMDA
To configure TMDA, you must first execute the tmda-keygen program to generate a cryptographic key. This will generate a 160-bit unique key. The key must be saved to the file crypt_key in the ~/.tmda/directory, which is where TMDA’s configuration files and filters are typically stored. It is essential that this key be kept secret, so make sure that you chmod the file and give it 0600 permissions so that only the owner can read and write to the file. Next, create a ~/.tmdarc file. This is the default configuration file for TMDA. What follows is a very simplistic ~/.tmdarc:
import os
CRYPT_KEY_FILE = “/home/user/.tmda/crypt_key”
ACTION_INCOMING = “confirm”
ACTION_OUTGOING = “dated”
CONFIRM_APPEND = “/home/user/.tmda/lists/whitelist”
FILTER_INCOMING = “/home/user/.tmda/filters/incoming”
FILTER_OUTGOING = “/home/user/.tmda/filters/outgoing”
LOGFILE_INCOMING=”/home/user/.tmda/incoming.log”
LOGFILE_DEBUG = “/home/user/.tmda/debug.log”
USERNAME = “user”
HOSTNAME = “myhost.com”
FULLNAME = “Joe User”
DATADIR = “/home/user/.tmda”
TIMEOUT = “5d”

There are many more options you can use with your TMDA configuration file, but this is enough to get started. This ~/.tmdarc file basically specifies paths to various files, such as your whitelist, your incoming and outgoing filters, your secret cryptographic key, and the base TMDA directory (or data directory, below which your pending queue will be stored). It also specifies that, as the default action for incoming mail, a confirmation message should be sent out. This e-mail message indicates user information such as e-mail username and hostname. (In this example, the username is “user” and the hostname is “myhost.com,” which results in the e-mail address “user@myhost.com”.) It also indicates the user’s full name (Joe User) and the timeout for dated e-mail addresses (five days).

This configuration file can be used on both the client and server systems by modifying paths to suit either environment. On the server, the incoming filter is used, while on the client, the outgoing filter is employed. The log files are also generated only on the server. Finally, your crypt_key file must be present on both the client and the server.

TMDA-style addresses
TMDA uses unique e-mail addresses for particular needs. This is part of what makes TMDA so flexible. In the above example, TMDA will generate “dated” addresses by default on all outgoing mail that is sent by your e-mail client. A dated address is an address consisting of a special key that indicates when the e-mail address will expire, based on the time the mail was sent. When mail is sent to a dated address, TMDA determines the expiration time of the dated address to see if it will challenge the mail or let it in without requiring confirmation. In our example, the dated address timeout is five days, so if you send a message to someone, they have five days in which to reply to the message without being asked to confirm their message. After five days, they will be asked to confirm any message they send to that, or any other, address. This allows you to post to mailing lists and allow legitimate replies to your messages to reach you, without leaving you vulnerable to marketers’ harvesting techniques of using online archives of the mailing list or newsgroup.

The dated address may look something like this: user-dated-1030158624.a0a03b8d@myhost.com. It’s quite long and convoluted and requires some extra support in order to receive MTA, but it is effective. Other addresses that TMDA can generate include keyword-based addresses and sender-based addresses. A keyword address is useful to hand out to Web sites when they request your e-mail for whatever reason. Many of these sites will be legitimate and won’t give out or sell your e-mail address, but if they do, you’ll have a very easy way to determine what site gave out your e-mail address, provided you use a unique keyword for each site you give your address to. The TMDA Address utility will let you generate these special addresses. A sender-based address is useful for mailing lists or robot addresses. The special address that TMDA generates is based on the e-mail address that is supposed to be sending the mail. For instance, assume you sign up for a mailing list where messages come from list-owner@somesite.com. When subscribing to this list, you could use a sender-address, which can be determined using TMDA Address. For example:
$ tmda-address -slist-owner@somesite.com
user-sender-06cfce9d@myhost.com

In this instance, only the address list-owner@somesite.com can e-mail this special address. Anyone else who e-mails this address will be asked for confirmation. In a mailing list situation, you would set your From address as the sender address, and your Reply-To as your dated address. This allows the mailing list messages to get to you without a problem, and it also allows anyone who may wish to respond to your e-mail to do so by using your dated address.

At first glance, this configuration may sound complicated, but it isn’t. TMDA comes with a sendmail wrapper, which will do all of this work for you. If your e-mail client delivers mail using a command line, such as /usr/bin/sendmail, then you can easily change this to use the wrapper program tmda-sendmail instead. If your e-mail client will only send to an SMTP server, you can use the tmda-ofmipd daemon, which will listen to a specified port for incoming e-mail, apply your outgoing filters, and forward the message to the real SMTP server. Using tmda-sendmail is recommended whenever possible because, even though tmda-ofmipd requires authentication before accepting a message, it is still one more open port on your system that could potentially be abused.

TMDA filters
TMDA makes use of incoming and outgoing filters to handle your mail. The syntax for both of these filter types is basically the same. Here are a few examples of outgoing filters that you can use. If you work in a company and do not want to use a dated address with your coworkers because you have whitelisted the entire domain for your company, you could use:
to *@=mycompany.com bare

Or, if you use your e-mail client to read both personal and work mail and wish to send mail to your company with your work address, yet default to using your personal e-mail for all other mails, you could use this filter instead:
to *@=mycompany.com as=user@mycompany.com

This will send all mails to anyone at the mycompany.com domain as user@mycompany.com, while all other mails will default to coming from user@myhost.com. For instance, from the previous mailing list example, you could use the following outgoing filter to send mail from a sender address with a Reply-To set to your dated address:
tolist@somesite.comtag
    from sender=list-owner@somesite.com
    reply-to dated

This filter will send all mail to list@somesite.com (the mailing list address) with the From header set to the sender address and the Reply-To header set to the dated address. You can also include lists of e-mail addresses that you wish to send to with a bare address. This is useful if you automatically whitelist addresses that have confirmed a single message. This tweak can be configured in your main configuration file with the CONFIRM_APPEND keyword. To include this list, you would use:
to-file ~/.tmda/lists/whitelist bare

Since this file is created on the server, you may wish to use something like rsync or FTP to download this file from the server and place it on the client for referencing. This file is simply a list of e-mail addresses (one address per line), which will not have to confirm messages sent to you.

Not just for Linux users anymore
With the number of spam programs available, TMDA may seem too complex for some. While it can be daunting at first, it’s not nearly as complex as it first appears. Plus, as perhaps one of the most powerful antispam tools available for administrators, it’s well worth your consideration. Since it is written in Python and includes the tmda-ofmipd program, it is not limited to Linux systems alone. Windows users can take advantage of TMDA as long as they first install the Python program for Windows and as long as the server receiving the messages is running Linux and a supported MTA (such as qmail, postfix, sendmail, or exim).