[rt-users] RT and Spam

[freebsd at coal.sentex.ca]

Thus spake Chris Fewtrell (chris at uk.clara.net) [04/08/03 07:16]:
> Have setup RT3.0.2 a while ago and been using it since quite happily
> within my own department. We're now proceeding to roll out usage of the
> RT system into other departments with additional queues.
> 
> We have a large influx of spam on some of these mail accounts and I
> gather we won't be alone in this.
> 
> I wondered if anyone would be willing to detail how they handle spam
> with RT mailboxes, either if its generally considered better for an
> external filter or use things like the integrated SpamAssassin hooks.

(Side note: if you Queue abuse@, you can't filter it.  It's a PITA, and I'm
trying to find a way to filter abuse@ while still providing a useful queue.
No progress yet.)

We use procmail to split things off, which in an of itself, is a great spam
filter.  Essentially, we have one set of three recipes for every queue.
Here's our support queue, for example:

    :0
    * ^(To|Cc): .*support
    {
        :0
        * ^(To|Cc): .*support@
        ${RT-MAILGATE} --queue support --action correspond --url http://rt/

        :0E
        * ^(To:Cc): .*support-comment@
        ${RT-MAILGATE} --queue support --action comment --url http://rt/
    }

Then subsequent queues all start with ':0E'.  At the end of it all, we put
it through TMDA.  This means that any message that didn't have a To: or Cc:
address of any of the correspond or comment addresses configured in RT will
be punted through TMDA for verification.  If verification is received, and
we /still/ can't figure out the proper queue, then we put it into a queue
called Limbo, and just monitor that for new tickets.

That was good for a while, but has its problems.  So after we process the
Abuse queue, and before we process any other queue, we run the message
through SpamAssassin (spamc).  If it comes back tagged as spam, then we run
it through TMDA.  That's cut down on the volume of spam into RT by like 95%.