How toTest One Single EmailWith Spamassassin

Testing One single email with Spamassassin.
It sounds so simple. Why has it taken me
so long to discover how to do this?

I suppose it took me this long for two reasons.

1. It never occurred to me to pipe the single
   email through spamassassin.
2. I was slow figuring out how to use the
   man pages to discover spamassassin command
   line options

Of the two discoveries, the first was discovering
command line options. I write about this in a
previous post:

Spamassassin Options

Next, I discovered the delete and
test options. You can read about
these on the man page called
spamassassin-run.

Here's how I put it all together:

cat spam.mbox | spamassassin -dt >testresults.txt

Here are the steps that puts it all
together:

1. Save the spam email that you are
   interested in testing to a file called
   spam.mbox
2. Run the spam email through
   spamassassin using the above pipe
3. At the end of the pipe, save the
   results to a file called testresults.txt
4. View testresults.txt with your
   favorite text editor

How do you save a spam email? My email client
is called kmail. With kmail, the spam
email is saved by using the file menu
in the upper left-hand corner of your screen.
The way you save a spam email to a file may
differ from the way I save a spam email to a
file.

When testing your single spam email, be sure
to include the -dt option. The -d
part of the option deletes spamassassin markup
that is in already in the email and that may
confuse the issue.

The -t option says that this is just a
test and is not the real deal. Basically, you
are testing how spamassassin will respond to
a specific email rather than running spamassassin
for its ability to classify and categorize spam.

In other words, -t is theory instead of
actual practice. With -t you can test
your brand new spamassasin rule before
putting it into production.

Of course, you want to be sure the new rule has
correct syntax before doing any of this. The
command for testing a rule for syntax correctness
is:

spamassassin --lint

It's nice to be able to immediately test a new
rule you've written for a specific spam email to
see how many points it will rack up. That's the
name of the game: racking up points.

The lesson? Sometimes it takes a long time to
discover the simplest little thing.

Being able to test a spam email for how many
points it will rack up is the simplest little
thing. Yet, it is very helpful to know how to
do this.

Update: February 7, 2012

I've since learned more about testing a single
email against spamassassin. I've learned that
it is probably better to run local tests only
when testing a single email.

What is a local test? It is a non-network test.
Some tests require a network access. To turn
off test that require a network access, you
use the -L option.

If I understand correctly, the spamassassin -L option
will only run tests that are stored on your hard
drive. These tests include tests that you have
written and tests that have been written by others..

The tests that I have written are stored in this
directory on my Debian Squeeze system:

~/.spamassassin/user_prefs

The tests that I did not write are stored here:

/var/lib/spamassassin/3.003001/updates_spamassassin_org/

It's when I run sa-update at the command line while
logged in as root that I acquire rules that I did not write
in the above directory. The point? Generally speaking, rules
that are stored on my hard drive are considered local rules.

The rules that are not local are the ones that require a
network access. In my rather limited experience, network
rules are rules that necessitate a lookup in a blocklist of
some kind. Perhaps there are other kinds of rules that
require a network access that I do not know about.

Generally speaking, blocklists are spammy IP addresses
that have been used to send spam in the past. If I
understand right, overuse of blocklist lookups can
get you categorized as a commercial user who is supposed
to pay for these lookups.

Using the spamassassin -L option can help you to
avoid excessive lookups in various blocklists. Therefore,
when I test a single email, I now add the -L option
like this:

cat spam.mbox | spamassassin -dtL >testresults.txt

Note that the above command line is the same as the
one I published up above a few months ago except that
the -L option is now present.

The lesson? No matter how much you learn about something,
there's always something else to know.

Ed Abbott