HOWTO v2: protect RT queues with SpamAssassin

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 :slight_smile: 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. :slight_smile:

  • 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@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"

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. :slight_smile:

Enjoy :slight_smile: Feedback always welcome…

-P.

rt (207 Bytes)