[rt-users] HOWTO v2: protect RT queues with SpamAssassin

[Phil Homewood]

My previous RT/SpamAssassin HOWTO seems to have been quite 
enthiusiastically received. Thanks to those who offered
feedback.

After discussing some improvements with Niall (who gets
partial credit for the ideas herein :-) I've improved the
system somewhat.

Using the attached procmailrc (which supersedes the previous
one) and the MoveTicketToOriginalQueue scrip (posted a short
while ago to rt-users, and hopefully in the contrib area
soon), you can allow users to confirm their request is
genuine and have it move to the originally intended queue.

Basically: the "spam" queue will autoreply, asking the requestor
to reply to the autoack to confirm his request is legit. Once
the reply comes in, the ticket goes to the right queue.

This procmailrc also differs slightly in that SpamAssassin
reports and headers are no longer added to the ticket history,
nor are they sent back to the requestor. (If you do happen to
want the SpamAssassin fingerprints in the transaction, it's
a pretty obvious marriage of the first recipe from this rc
together with my original rc.

OK, here we go....

* procmail must be installed, together with formail.

* The MoveTicketToOriginalQueue ScripAction 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 -p ~mailnull/.spamassassin
	chown mailnull ~mailnull/.spamassassin

  (other OSs will be similar.)

* Create a "spam" queue in RT, make sure "everyone" has the right
  to "CreateTicket" and "ReplyToTicket", and season other rights
  to taste.

* Create a SpamReply template, which asks the requestor to reply
  to confirm his request. Some tact may be required to avoid
  accusing him of being a spammer. :-)

* If you use ParseNewMessageForTicketCcs, ensure the IsRTAddress()
  function in your config.pm lists any queue addresses that are
  subject to SpamAssassin. Else you'll end up with a few "RT Bounce"
  messages. (No big deal, just annoying.)

* Set up the scrips for the spam queue. I suggest:

  OnCreate AutoreplyToRequestors with template SpamReply 
  OnCorrespond MoveTicketToOriginalQueue with template Blank 
  OnCorrespond AutoreplyToRequestors with template AutoReply

* 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 at example.com" and comment address "test-c at 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"

And bingo! RT, without the spam.

Possible enhancement: Create a cron job to purge tickets older than
N days from the spam queue. Implementation is left as an exercise
for the reader. (Translation: I haven't bothered, yet. :-)

Enjoy :) Feedback always welcome....

-P.
-------------- next part --------------
:0fw
| /usr/local/bin/formail -i "X-RT-Queue: $1"

:0cw
| /usr/local/bin/spamc -c

:0aw
| /usr/local/rt2/bin/rt-mailgate --queue $1 --action $2

:0w
| /usr/local/rt2/bin/rt-mailgate --queue spam --action $2