Dealing with spam in RT (was Re: Fwd: [rt-users] Execute Arbitrary Perl Script on resolve)

[Niall Brady]

[this is a bit stream-of-conciousnessy, so bear with me ;-)]

On Fri, May 31, 2002 at 10:20:35PM +0200, Bruce Campbell wrote:
> 
> finish it as part of a ScripAction tutorial when I get spare time (and
> that'll probably be when I next get pissed off at spam in my queues and
> want SpamAssassin on it ;) )

:-)

I kinda had a think about that before, but I'm not sure about the best
way of dealing with spam.

Many sites have just one common request queue, where the email
address is commonly known, and hence a bit of a spam-trap.  It's
not really an option to go changing around your support addresses
to block spam ;-)

Filtering the spam by hand is simply unpractical in some sites, due to
the volume received.

The only (bad) way I could think of doing was something like...

	* Mail into a procmail script for the support address
	* Through SpamAssassin
	* If good, it goes into the normal queue
	* If bad...
		- Bounce back to sender, with a note
		  asking them to enter the ticket
		  number in some form (with an image
		  number on the page or the like that
		  they also have to enter, to avoid
		  bots defeating it).
		- Chuck the ticket into a *different*
		  queue, which contains suspected spam
	* If the user fills in the details required,
	  use RT to move the ticket back into the real
	  queue
	* Autokill tickets which aren't hit in that
	  queue after a week/month/whatever, through
	  a cron job.

It's bad because...

	* It would confirm that the account is active, for
	  harvesters... though as far as I can see, this is
	  unavoidable as...
	  	- we need to autoreply to requests
		- there's no way that I can think of to
		  differentiate between real spam, and
		  reports of spam!

	* A bit more awkward for the end users

	* The two queues thing probably isn't the best
	  idea design-wise... it might be better for it to be
	  integrated into RT, like

	  	- Call SpamAssassin from within RT(?!)
		- if SpamAssassin says it is spam, RT
		  replies with the appropriate note,
		  *doesn't* send the ticket to AdminCCs,
		  and tags it as dead.
		- If the webform stuff is done, then
		  re-open, and renotify the AdminCCs

	  (this approach would be better, as it could
	   be generically applied to any queue)

	* Reliant upon the external functionality of
	  SpamAssassin (or whatever) , and that remaining
	  constant.  That's probably not a big deal though...

Thoughts anyone?

-- 
	Niall