Controlling SPAM under Mandrake Linux, Part 2
Revision/Modified: Dec 11, 2001
Author: Vincent Danen		
In Part 1 we discussed using RBL to help secure the email server to help prevent SPAM. In this final part we look at securing the client.
Securing the Client
You can likewise use tools to secure the end-user (client) from SPAM as well. There are a number of tools, such as procmail filters, other filtering systems, and so forth. A quick visit to Freshmeat turns up a number of projects in the "anti-spam" category. However, I'm not a big fan of filtering programs. They are prone to error (filtering out legitimate email in some cases) and they require constant updating as spammers learn new tricks. Using a SPAM filter, while adequate, takes a lot of energy to maintain properly.
Because of this, we're going to look at a tool called TMDA, or Tagged Message Delivery Agent. TMDA was added to the Mandrake Linux contribs on December 7th, 2001, so you will be unable to find it for older distributions. However, because it is a python-based application, it is extremely simple to download the source RPM for TMDA and rebuild it (in fact, you should do this because the versions of python differ and the TMDA files need to be installed in the proper location).
The thing that makes TMDA different from traditional anti-spam tools is that it does not attempt to filter mail. It uses a cryptographically-enhanced confirmation system to confirm incoming email. What this means is that every message sent to you triggers a confirmation request from TMDA that is sent to the message sender. The sender then needs to confirm the request by replying to the mail. Once this is done, TMDA will release the message from a pending queue and allow it to be delivered to your inbox. To make it even easier, TMDA also uses a "whitelist" which contains email addresses or expressions for known and trusted senders, and a "blacklist" for the undesireables. TMDA can also be configured to append email addresses from those who confirm their messages automatically to your whitelist, so a person will only need to confirm their message once, after that, they are permanently added to your whitelist and never need to confirm messages again.
The benefits here should be obvious. TMDA works on a few basic assumptions that are true based on today's internet email standards. The first is that you cannot keep your email address secret from spammers. The second is that content-based filtering programs can't distinguish SPAM from legitimate email with a high degree of accuracy. The third is an assumption on the economies of large-scale bulk mailings, in that they often use an impersonal process where the recipient is not distinguish and that they utilize a one-way communication channel (spammer to victim). Finally, that SPAM will not cease until it becomes financially prohibitive, and too expensive for spammers to operate.
This is particularly true. More often than not, the email address used to send the mail is spoofed and is not a real address. Replying to the message will likely get you a bounce message back. Because of this, SPAM messages sent to TMDA, which are in return sent a confirmation request, will never be confirmed as the spammer will never see it. After a few days in the pending queue, the message is silently removed and you never see it.
The only draw-back to TMDA is that it can be somewhat difficult to configure initially. It also requires some specific settings on the mail server that it is being run on in order for it to work properly. If you don't have access to your mail server, you can still use TMDA in some instances, but it takes a little more work. What we will do here is take a look at setting up and configuring TMDA on both a qmail and postfix system. The differences between the two will be noted.
The first step is to install TMDA. TMDA really should be installed on the primary MX system for your domain if at all possible. So if you're email address is joe@mydomain.org, then it should be installed and used on the primary MX for mydomain.org (let's assume mail.mydomain.org). If this is not possible, we can still use TMDA on the next jump (ie. if you pop your mail using fetchmail to your local workstation, you can use TMDA there), but it takes a little more effort. You must also use something like fetchmail to retrieve your mail (if you use Evolution or Netscape mail or some other email client that can only fetch via POP3 on it's own, you won't be able to use TMDA, unless it's on the primary MX system). Previously I had noted that you could use getmail; that was incorrect. getmail doesn't forward to the localhost SMTP server and doesn't provide TMDA with the environment information it needs so cannot be used.
Once you have TMDA installed, you can begin to configure it. If you use qmail, you do not need to perform any "pre-configuration" steps. If you are using postfix, you will need to edit your /etc/postfix/main.cf and include the following directive:
recipient_delimiter = -

This tells postfix to deliver user-*@ to user's mailbox. Without this, user-*@ would be rejected or discarded as undeliverable, which will prevent TMDA from working. By default, postfix wants to use a delimiter of "+" instead of "-" which will make TMDA addresses look like user+ext+ext2...@ instead of user-ext-ext2...@. This is really a matter of personal preference, but I find that using a delimiter of "-" rather than "+" just looks better. But you can use either delimiter by specifying it as shown above.
Setting up .qmail/.forward Files
Throughout this example, we will assume your username is "joe" and your home directory is /home/joe.
If you're using qmail, you will be familiar with your ~/.qmail file. Postfix users will know the equivalent file as being ~/.forward. In qmail, it will likely contain:
./Maildir/
by default. In postfix, unless you are forwarding or otherwise processing messages, you probably don't have a .forward file. This is due to postfix delivering to /var/spool/mail/$username and qmail delivering to $HOME/Maildir/. At any rate, if you're using qmail, your .qmail file should now contain:
|/usr/bin/tmda-filter
./Maildir/
The first thing we do is tell qmail to execute /usr/bin/tmda-filter on all incoming mails first. You will also want to symlink .qmail-default to .qmail as well, ie:
$ ln -s .qmail .qmail-default
This will ensure that all of joe's aliases (joe-test, joe-confirm, joe-dated, joe-blech, etc.) will be delivered the same as joe@. The reason for this is that TMDA creates email addresses in a specific way. For instance, using TMDA, joe@mydomain.org must also be able to receive and handle the email address joe-dated-1008450500.132x7b@mydomain.org. Without having ~/.qmail-default, all mail to joe-* would be rejected as undeliverable.
It's subjective whether or not postfix is easier to setup in this regard. A postfix user only has to create ~/.forward containing:
|/usr/bin/tmda-filter
to have postfix execute tmda-filter on the incoming message and on approved messages, deliver to their spool file. A .forward file in postfix will handle joe-* by default; there is no .forward-default.
The disadvantage here is that in postfix, using TMDA is all or nothing; you can't use it for some addresses and not for others. In qmail, however, you can have ~/.qmail-tmda and ~/.qmail-tmda-default that call tmda-filter, so only messages to joe-tmda-* will be processed, leaving joe@ or joe-mlists@ untouched by TMDA. This also allows qmail users the chance to play with and test TMDA somewhat before putting it into action for their primary account, whereas a postfix user would need an entirely different account to do the testing (ie. joe2-*@ for testing TMDA). However, if you want to use non-filtered accounts under postfix, you could set up a ~/.forward-nontmda file and use the address joe-nontmda@mydomain.org; just don't call tmda-filter in the ~/.forward-nontmda file.
Just as an aside, I would not put the call to tmda-filter until after you have configured TMDA, or your mail will sit in your mailer's queue as delayed or, worst-case scenario, bounced back to the sender as undeliverable.
The ~/.tmdarc File
The meat and potatoes of TMDA is the configuration file which is either /etc/tmdarc for global configuration settings or ~/.tmdarc for personal configuration settings. If you look in /usr/share/doc/tmda-*/contrib/sample.tmdarc you will find a sample configuration file that you can use as a basis for your own configuration file. Unfortunately, TMDA 0.42 (the current version) doesn't come with a very verbose sample file, so a lot of the options are not very well described (if at all). The author indicates that reading the Defaults.py file will give you the information on each option that you need (and he's right, but Defaults.py, buried in the Python directory tree, is not a very intuitive place for peopel to look). We'll take a look at them here.
The first thing to do is generate a private key for TMDA. This is a personal key and should be kept secret. To generate the key, use the tmda-keygen utility like this:
$ tmda-keygen
Generating a unique, 160-bit private key, please wait a moment..

CRYPT_KEY = "604544eff51bbc244bf9d9e5a92d042778ec6162"

Now paste the above line into your ~/.tmdarc file,
and make sure to keep your key secret!
$
This string (CRYPT_KEY) should be the second line of your ~/.tmdarc file, where the first line is:
import os
That is very important; without it TMDA will not work. The next options are for postfix only; by default qmail users need not do anything special here and should not use the following keywords:
MAIL_TRANSFER_AGENT = "postfix"
LOCAL_DELIVERY_AGENT = "/usr/bin/procmail"
RECIPIENT_DELIMITER = "-"
Here we are telling TMDA that our MTA is postfix and we also tell it to use procmail as the local delivery agent. Finally, we tell TMDA that our recipient_delimiter (set in postfix further back), is the "-" character. If you enable recipient_delimiter in postfix as "+", then you must use RECIPIENT_DELIMITER = "+" here.
One note on using procmail with TMDA. You can filter your mail with procmail, just as you used to, if you like. You just need to invoke it twice. The first thing is to modify ~/.forward to look like this:
| /usr/bin/procmail -p
Next, change the value of LOCAL_DELIVERY_AGENT in ~/.tmdarc to something like this:
LOCAL_DELIVERY_AGENT = "/usr/bin/procmail ~/.procmailrc-tmda"
This tells procmail to run with a different configuration file to avoid infinite loops. You must have, in your ~/.procmailrc-tmda file, a minimum of the following so that mail gets delivered to your inbox:
DEFAULT=/home/joe/mail/inbox
This will have procmail deliver all TMDA-approved messages to /home/joe/mail/inbox, which will be your new inbox rather than /var/spool/mail/joe. Finally, you will need to add to the end of your existing ~/.procmailrc the following for final delivery:
# Run the message through tmda-filter.
:0 w
| /usr/bin/tmda-filter
# Take the exit code from TMDA
EXITCODE=$?
# TMDA takes care of final delivery
DEFAULT=/dev/null
This means that all mail that gets to this point and has not matched any procmail filters (ie. all your mailing list filters would be above this recipe), would be handled by tmda-filter; anything getting passed it (which should be nothing) will get delivered to /dev/null and you'll never see it.
That's about all that is qmail or postfix specific for TMDA. The rest is similar regardless of your MTA.
What follows is an example of an entire ~/.tmdarc file. We'll look at each option afterwards. Note that a number of the values here are essentially identical to the default values, however they are being illustrated as part of the configuration to provide a more complete picture of how TMDA is configured and where it looks for things. Your configuration file does not necessarily need to contain all of this information.
# ~/.tmdarc
import os

CRYPT_KEY = "604544eff51bbc244bf9d9e5a92d042778ec6162"

# comment the following three if using qmail
MAIL_TRANSFER_AGENT = "postfix"
LOCAL_DELIVERY_AGENT = "/usr/bin/procmail"
RECIPIENT_DELIMITER = "-"

# default incoming action: confirm messages
ACTION_INCOMING = "confirm"

# default outgoing action: leave it bare
ACTION_OUTGOING = "bare"

# automatically append to this file once confirmed
CONFIRM_APPEND = "/home/joe/.tmda/lists/whitelist"

# confirmation accept template
CONFIRM_ACCEPT_TEMPLATE = "/home/joe/.tmda/confirm_accept.txt"

# confirmation request template
CONFIRM_REQUEST_TEMPLATE = "/home/joe/.tmda/confirm_request.txt"

# incoming filter file
FILTER_INCOMING = "/home/joe/.tmda/filters/incoming"

# outgoing filter file
FILTER_OUTGOING = "/home/joe/.tmda/filters/outgoing"

# logfile
LOGFILE = "/home/joe/.tmda/Log"

# email parts
USERNAME = "joe"
HOSTNAME = "mydomain.org"
FULLNAME = "Joe User"

MESSAGE_FROM_STYLE = "angles"
Your ~/.tmdarc file can contain any comments you want, prefixed with a hash symbol. Let's examine each option.
ACTION_INCOMING = "confirm"
This tells TMDA that the default action is to request confirmation for all messages. You can also choose "bounce" to bounce all messages, "drop" to silently drop the message, or "ok" to deliver the message without asking for confirmation. This is only applicable to messages that don't match anything in FILTER_INCOMING and are not sent to a tagged address.
ACTION_OUTGOING = "bare"
This tells TMDA that the default action on outgoing messages it to be sent bare, without any tags. You can choose "dated" to use a dated address or "sender" to use a sender address. This is only used if there is no match in FILTER_OUTGOING and no X-TMDA header placed in the message.
CONFIRM_APPEND = "/home/joe/.tmda/lists/whitelist"
This tells TMDA to append the sender's email address to the file /home/joe/.tmda/lists/whitelist, which is our whitelist of addresses. This is used to implement an "auto-whitelisting" feature. This ensures that people who confirm a message once will automatically be placed in the file and will never have to confirm another message to you.
CONFIRM_ACCEPT_TEMPLATE = "/home/joe/.tmda/confirm_accept.txt"
This tells TMDA to use /home/joe/.tmda/confirm_accept.txt as the basis for it's confirmation acceptance messages (ie. "your message has been accepted"). This is sent to a user if they confirm a request. If you don't wish to have acceptance messages sent to users, you can include the following in your file:
CONFIRM_ACCEPT_NOTIFY = 0
The value 0 tells TMDA not to send a notification. A value of 1 is the default.
CONFIRM_REQUEST_TEMPLATE = "/home/joe/.tmda/confirm_request.txt"
This tells TMDA to use /home/joe/.tmda/confirm_request.txt as the basis for the confirmation request message sent to senders (ie. "your confirmation is required for me to read this message"). The TMDA package isntalls the default templates that TMDA uses into /usr/share/tmda, so you can view those files to see what macros are available to use.
FILTER_INCOMING = "/home/joe/.tmda/filters/incoming"
This is your incoming filter file. This is where TMDA looks to see if there are any special rules that match the incoming sender's email address. More on this in a moment.
FILTER_OUTGOING = "/home/joe/.tmda/filters/outgoing"
This is your outgoing filter file. This is where TMDA looks to see if there are any special rules that match your message's recipient email address. Again, more on this in a moment.
LOGFILE = "/home/joe/.tmda/Log"
This tells TMDA where to log it's delivery actions and statistics.
USERNAME = "joe"
HOSTNAME = "mydomain.org"
FULLNAME = "Joe User"
MESSAGE_FROM_STYLE = "angles"
These all make up the email parts of your email address. USERNAME is the left-hand side of your email address (prior to "@"); HOSTNAME is the right-hand side of your email address (after the "@"). If HOSTNAME is not set, it defaults to the FQDN (fully qualified domain name) of your computer. The FULLNAME setting just tells TMDA what your name is. So for instance, your full email address string would be $FULLNAME <$USERNAME@$HOSTNAME> (or "Joe User "), which is what MESSAGE_FROM_STYLE determines. The "angles" value specifies the address type just shown. You can also choose "address" (joe@mydomain.org) or "parens" (joe@mydomain.org (Joe User)).
There are a few other keywords you can use, but those previously illustrated are likely the ones you will use the most. The others are for more fine-tuning. These are:
ALLOW_MODE_640 = 0
This tells TMDA to allow mode 0640 ~/.tmdarc files. By default, TMDA will only run if ~/.tmdarc is mode 0600 or 0400. Mode 0600 means it is read/write by the user only; mode 0400 means it is read-only by the user only. Mode 0640 means read/write user and read-only group. If you want to have mode 0640 ~/.tmdarc files, set this to "1".
BARE_APPEND = "/home/joe/.tmda/filters/whitelist"
This tells TMDA to write the recipient's email address to the file /home/joe/.tmda/filters/whitelist if the outgoing action in the filter file is "bare=append". This is useful if you are sending an email to a person or organization that you expect to reply, but don't wish to inconvenience with a confirm request. This is only used on outgoing messages that you send.
CONFIRM_CC = "joe-confirm@mydomain.org"
This tells TMDA to send a copy of any email message that triggers a confirmation request. This address should not be TMDA-controlled. In this instance, every message that triggers a confirmation request will also be sent to joe-confirm@mydomain.org.
CONFIRM_MAX_MESSAGE_SIZE = 50000
This is the maximum message size (in bytes) that a message can be before it's body is excluded from the confirmation request/acceptance notice messages. This is to prevent sending back extremely large messages (perhaps with file attachments) back to the sender, and is used to control the amount of bandwidth used. The default is 50k (50,000 bytes).
DATADIR = os.patch.expanduser("~/.tmda/")
This is the top-level directory TMDA uses to store files and directories. This should be writable by the user as TMDA will need to create files and directories under DATADIR. You must include the trailing slash ("/"). The default is ~/.tmda/.
FILTER_BOUNCE_CC = "joe-bounce@mydomain.org"
This is the email address TMDA will send copies of any message that bounces due to a match in FILTER_INCOMING. When you first setup TMDA, it is a good idea to utilize these addresses to ensure you don't lose any mail accidentally.
FILTER_DROP_CC = "joe-drop@mydomain.org"
This is the email address TMDA will send copies of any message that is dropped due to a match in FILTER_INCOMING.
HMAC_BYTES = 3
This is an integer that determines the length of the HMACs used in TMDA's "cookies". Changing this value will invalidate all previously-generated HMACs. The default is "3", which corresponds to a 24-bit HMAC. The HMAC is the cryptographic portion of TMDA and utilizes the CRYPT_KEY (which is why you want to keep it secret). Larger HMACs afford greater security, but as a consequence email addresses that use cookies (dated addresses, sender addresses, confirmation request addresses, etc.) are also longer. For instance, using the default 24-bit HMAC results in a 6 character string with a 1 in 16,777,216 chance of forgery. A single HMAC_BYTE is an 8-bit HMAC of two characters, but with a 1 in 256 chance of forgery. A HMAC_BYTES value of 5 is a 40-bit HMAC with ten characters and a 1 in 1,099,511,627,776 chance of forgery. The default 24-bit HMAC is likely more than sufficient to prevent forgeries, however. You can get more information on reading the /usr/share/doc/tmda-*/CRYPTO file.
TIMEOUT = "5d"
The timeout interval for "dated" addresses. You can use the specifiers of Y=year, M=months, w=weeks, d=days, h=hours, m=minutes, s=seconds. The default is five days.
USEVIRTUALDOMAINS = 1
This enables TMDA's support for qmail virtualdomains. By default, TMDA has this enabled. If you are using postfix or if you don't use qmail virtualdomains, set this to "0" to turn it off.
VIRTUALDOMAINS = "/var/qmail/control/virtualdomains"
This is the qmail virtualdomains file that TMDA reads. This is only required if you are using qmail virtualdomains and USEVIRTUALDOMAINS is enabled. This should remain at the default location, and is only useful if this file is located elsewhere (ie. a home-brewn qmail install in /usr/local or something).
The TMDA package installs a sample.tmdarc file in /usr/share/doc/tmda-*/contrib/ that you can also view. And that's all there is to the ~/.tmdarc file.
TMDA Filters
By default TMDA has two filter files: ~/.tmda/filters/incoming and ~/.tmda/filters/outgoing. Each is used independently of the other. The incoming filter is to match against sender email addresses for incoming messages. The outgoing filter is to match against recipient email addresses for outgoing messages.
Each line in the filter file is expected to be a string containing three unquoted fields separated by whitespaces. Filters are read from top to bottom and the first matching filter is used. The three fields used are:
source match action
The source specifies the source of the match and can be one of the following types:
•	to (recipient address) (incoming/outgoing) 
•	to-file (incoming/outgoing) 
•	to-cdb (incoming/outgoing) 
•	to-dbm (incoming/outgoing) 
•	from (sender address) (incoming) 
•	from-file (incoming) 
•	from-cdb (incoming) 
•	from-dbm (incoming) 
•	body (message body) (incoming) 
•	headers (message headers) (incoming) 
•	headers-file (incoming) 
•	size (message size) (incoming) 
The match is an expression, or the full path to textfile, CDB database, or DBM database containing more expressions if source was suffixed with "-file", "-cdb", or "-dbm" respectively. The second field within a textfile, CDB database, or DBM database is optional, but it overrides the action if it is present. For example:
jim@somedomain.com
alice@somedomain.com bounce
This table, taken from the TMDA website, indicates what the match expression should be for any given source:
source:	match:	
to*	recipient email address or wildcard expression	
from*	sender email address or wildcard expression	
body*	regular expression matching message body content	
headers*	regular expression matching message header content	
size	comparison operator and number of bytes to compare to the sizee of the message. Only "<" and ">" are supported.	
You can also use wildcards, as noted in the table, to match addresses. These are based on UNIX shell-style wildcard characters and can be used in the match field of a line or within a textfile. These characters are not recognized in CDB or DBM database files.
character(s):	description:	
*	matches everything	
?	matches any single character	
[seq]	matches any character in seq	
[!seq]	matches any character not in seq	
@=	matches both @ and @*	
Finally, the action field specifies an action to take on the message and can be one of the following types for the incoming filter:
•	bounce, reject: bounce the message 
•	drop, exit, stop: silently drop the message 
•	ok, accept, deliver: deliver the message 
•	confirm: request confirmation for the message 
and the outgoing filter:
•	bare: don't tag 
•	bare=append: don't tag and add recipient to your BARE_APPEND file 
•	sender: tag with a sender address based on recipient 
•	sender=address: tag with a sender address based on address 
•	dated: tag with a dated address 
•	dated=timeout_interval: tag with a dated address using timeout_interval 
•	exp, explicit, as=full_address: use an explicit address 
•	ext,extension=address_extension: add an extension to the address 
•	kw, keyword=keyword: tag with a keyword address 
Let's look at a quick example of each type of filter. Here is a sample incoming filter:
# tmda incoming filter: ~/.tmda/filters/incoming
# first match wins

# accept all bounces (messages with an empty envelope sender)
from <> ok

# accept all messages to postmaster
to postmaster@* accept

# handle mailing lists
from qmail-return-*@mandrakesecure.net ok
from announce-return-*@mandrakesecure.net ok
from discuss-return-*@mandrakesecure.net ok
from exploits-return-*@mandrakesecure.net ok
from snf-return-*@mandrakesecure.net ok

# accept all mandrakesoft.com, linux-mandrake.com addresses
from *@=mandrakesoft.com ok
from *@=linux-mandrake.com ok

# include blacklist and whitelist
from-cdb ~/.tmda/lists/blacklist.cdb drop
from-cdb ~/.tmda/lists/whitelist.cdb accept

# examine message content
headers (Precedence:.*junk) reject
And an example outgoing filter:
# outgoing tmda filter: ~/.tmda/filters/outgoing
# first match wins

# all whitelisted contacts receive untagged messages
to *@=mandrakesoft.com bare
to *@=linux-mandrake.com bare
to *@=mandrakesecure.net bare

to-file ~/.tmda/lists/whitelist bare
And that's about all there is to filters. Much of this information was adapted from the TMDA config-filter page. More examples are available there, along with information on using DBM and CDB database files.
Using TMDA for Outgoing Messages
Finally, to use TMDA for outgoing messages you should have your mail client use the /usr/bin/tmda-sendmail binary rather than the traditional /usr/lib/sendmail or /var/qmail/bin/qmail-inject invocations. For instance, if you were to use the mutt email client, you would use the following in your ~/.muttrc file:
set sendmail="/usr/bin/tmda-sendmail"
The TMDA client configuration page has instructions for using other MUAs (Mail User Agents) such as Sylpheed, KMail, Pine, and even some usenet news clients.
The purpose of using tmda-sendmail in place of your current or traditional sendmail binary is to make use of the dated, keyword, or sender email addresses TMDA can generate for you. This gives you finer control over what email addresses you are using for what mailing lists, recipient domains, and so forth. The only thing you must be sure of is that you have TMDA installed on both the server and your client (workstation) computers. Both ~/.tmdarc files must contain the exact same CRYPT_KEY string in order for TMDA to work seamlessly. Because the HMACs are based on the CRYPT_KEY, they must be identical for messages from your email client to be processed properly by the server.
Other SPAM-Prevention Techniques
If you've read this far and have decided that perhaps TMDA isn't for you, there are other techniques you can use to reduce SPAM, or at the very least track who is selling or handing out your email address. Even if you do plan on making use of TMDA, these techniques may prove valuable regardless.
As we've illustrated before, you can use extension addresses for your email address using postfix and qmail provided that, in postfix, recipient_delimiter is set. In this way, if you sign up to a mailing list like discuss@mandrakesecure.net, you could sign up with the address joe-discuss@mydomain.org and only use this address for the discuss@mandrakesecure.net mailing list. You would then configure ~/.forward-discuss or ~/.qmail-discuss appropriately. Likewise, if you must submit your email address to a website, you could use a convention similar to joe-[web_url] for the address to give; for example if you provided an email address to www.somedomain.com, you could use joe-www_somedomain_com@mydomain.org for the address. You don't need to setup a ~/.forward-www_somedomain_com file necessarily, just let ~/.forward catch it (or ~/.qmail-default) and deliver it to your inbox as normal. If you find SPAM messages are coming to that particular address, you know that website has sold or otherwise given out your email address and you can either bounce messages based on that address, or send nasty email messages to the webmaster of the unscrupulous website.
If you keep in mind a few things, you can reduce the amount of SPAM you receive, and thus try to preserve the sanctity and security of your email client's inbox. TMDA is only one solution, but it is by far the best solution I've seen so far. Using RBL at the MTA level is likewise a somewhat effective means of blocking SPAM. While RBL cannot handle everything as spammers also use valid domain names such as @hotmail.com or @yahoo.com, it can be effective in cutting down a decent number of junkmail messages without the need for TMDA and other anti-spam programs.
While TMDA may sound difficult to use and tricky to configure, it is relatively straightforward. And it is an effective solution to the problem of SPAM; the only trade-off is that you must somewhat inconvenience people sending messages to you at least once. Considering the benefits, however, it is a trade-off you might find worthwhile.