HOWTO: protect RT queues with SpamAssassin

Well, this proved trivial enough to do, but is such a neat
arrangement that I thought I’d summarise it for the list.

SpamAssassin (www.spamassassin.org) is a mail filter to identify
spam.

We, like many others no doubt, receive a lot of spam to RT
queues. And we don’t like it. (I know Bruce has also mentioned
this kind of thing before.)

Since we’ve been trialling SpamAssassin for end-user delivery
on (conveniently) the same host that RT runs on, I decided to
put RT behind SpamAssassin as well.

Rather than reject or lose any detected spam, I chose to shunt
it into its own queue for review and disposal. Of course others
may choose differently; this is very simple to change.

The procedure (under FreeBSD, using Sendmail at least) is very
simple:

  • procmail must be installed.

  • spamassassin must be installed (duh!), spamc/spamd installed,
    and spamd running. (If you don’t want to use spamc/spamd,
    replace the “spamc” command with the appropriate "spamassassin"
    command in the attached procmailrc.)

  • The user running spamassassin (I chose the MTA’s "mailnull"
    user) must have (or have permission to create) a .spamassassin
    directory under his home dir. This was the only roadblock I
    hit (as spamassasin’s “spamc” silently does nothing if this is
    not the case.)

    Under FreeBSD:
    mkdir ~mailnull/.spamassassin
    chown mailnull ~mailnull/.spamassassin

    (other OSs will be similar.)

  • Create a “spam” queue in RT, make sure “everyone” has the right
    to “create ticket” and season other rights to taste.

  • Drop the attached procmailrc into /usr/local/etc/procmailrcs/rt
    and correct any paths for your local installation. Change the
    ownership of this file to your chosen user (“mailnull” in the
    example above.)

  • Change the alias for each queue you wish to protect. For example,
    assuming I have a queue called “test”, with correspond address
    "test@example.com" and comment address "test-c@example.com", I’d
    use the following:

test:"|/usr/local/bin/procmail -m /usr/local/etc/procmailrcs/rt test correspond"
test-c:"|/usr/local/bin/procmail -m /usr/local/etc/procmailrcs/rt test comment"

That’s it! Told you it was simple. :slight_smile:

Variations to the procmailrc:

  • Change “spamc” to “spamassassin -P” if you don’t use spamd.
  • Change the “X-Spam-Status: Yes” delivery rule to bounce, or
    blackhole, or deliver to mailbox, or whatever, if you don’t
    want a “spam” queue. The choice is yours!

Enjoy :slight_smile:

-P.

Phil Homewood wrote:

  • Drop the attached procmailrc into /usr/local/etc/procmailrcs/rt
    and correct any paths for your local installation. Change the
    ownership of this file to your chosen user (“mailnull” in the
    example above.)

Stupid me. Got distracted by a developer and forgot to attach the file.
:frowning:

Here it is :slight_smile:

rt (174 Bytes)

Variations to the procmailrc:

  • Change “spamc” to “spamassassin -P” if you don’t use spamd.
  • Change the “X-Spam-Status: Yes” delivery rule to bounce, or
    blackhole, or deliver to mailbox, or whatever, if you don’t
    want a “spam” queue. The choice is yours!

A few more points

Vipul’s Razor ( http://razor.sourceforge.net/ ) has hit v2.09 and has better,
fuzzier signatures and a (better) trust system to strengthen the system’s
bozo resistance. It’s easy to install and configure and support for Razor is
already built into SpamAssassin; SpamAssassin will use Razor if it can find
it.

Also, a related project is the Distributed Checksum Clearinghouse (
http://www.rhyolite.com/anti-spam/dcc/ ). Read the SpamAssassin docs and then
install and configure dccproc. SpamAssassin also has hooks to DCC and will
use it if it finds it.

I upgraded all of these this morning (I’m running SuSE 7.2 with Postfix and
procmail, not that it matters) and I’m already seeing a bit more aggressive
tagging.

If you’re really, really bored you could dump the list of existing
requestors’ email addresses from RT and massage it into a whitelist for
SpamAssassin which should help allay fears of tagging legitimate mail.

– Bob