Request Tracker

What is this?
Spam avoidance

What is this?

Nothing much. I use Request Tracker to manage system administration and network administration requests, as well as to deal with service feedback, at my site. I've already started taking off the hood and poking around. It's possible that some of the changes will be interesting to other people, so here's a little corner of the web where I can take notes on what I'm doing. Maybe it'll be useful to you.

Feel free to copy anything from here, but please link back to this site.

Spam avoidance

Spam was flowing into RT through the mail gateway. It was beginning to cost me a lot of time to go through and delete all of it. I didn't particularly care that the spam was accumulating in my database, but I did care not to lose a single legitimate email. Putting a spam filter in front of RT and destroying the messages that didn't pass was not acceptable. TMDA and similar solutions were too complicated, and wouldn't work so well at a site where many different email addresses fed the same RT instance. I crawled through the mailing list archives for rt-users and found solutions that were almost there, but not quite.

The solution that made the most sense was posted by Phil Homewood in a message entitled "HOWTO v2: protect RT queues with SpamAssassin". Every incoming message was sent to RT, and RT would track every incoming message by ticket number, but anything caught as spam by SpamAssassin would be hidden in a spam queue unless the original sender said otherwise. It was perfect. The only problem was that it was for RT 2, and I was running RT 3.0.9. I was also hampered by the very limited documentation (i.e. none) on scrips and how to write them and use them available outside of reading the RT code. Fortunately a couple of hours of fiddling got everything working just fine.

Here's how it works:

Spammer sends spam to RT mail gateway address
SpamAssassin guesses it's spam
procmail delivers it to spam queue in RT via rt-mailgate
RT auto-replies with ticket number
RT's auto-reply bounces (surprise!)
RT users never see the ticket

Or...

Luser sends plea for help to RT mail gateway address
Oops, SpamAssassin guesses it's spam
procmail delivers it to spam queue in RT via rt-mailgate
RT auto-replies with ticket number
Luser reads auto-reply and learns the mail was set aside
Luser replies to auto-reply
Reply to auto-reply is delivered to RT via rt-mailgate
RT moves ticket to whatever queue the ticket was supposed to be in
RT sends acknowledgement of this to luser
RT users see ticket and deal with it

Sounds pretty good. And now, here's an updated for RT 3 procedure for implementing this solution.

First, get procmail and formail and SpamAssassin working. Sorry, that's outside of the scope of this document.

Next, make some changes in RT:

Make a spam queue in RT. The Everyone system group must be able to CreateTicket and ReplyToTicket. Nobody else needs access to this queue, unless you're curious.
Make a Template inside the new spam queue called Autoreply. This will override the Autoreply template defined globally. This template should explain (gently) that the original email was set aside and will not be seen unless a reply to this message is received. You should probably include {$Transaction->ContentObj()->Headers()} so any replies to spam that get delivered are useful to the (faked) recipient.

Make a Scrip inside the spam queue called Auto-Close:

	Description: Auto-Close
	Condition: On Create
	Custom condition:
	Action: User Defined
	Custom action preparation code: 1;
	Custom action cleanup code: $self->TicketObj->SetStatus('resolved'); 1;
	Template: Global template: Blank

Make a Template inside the spam queue called ReOpenAcknowledgement. This can be pretty much a copy of your global Autoreply, but you might want to say a few words on how the original email is still in the database.

Make a Scrip inside the spam queue called Acknowledge Re-Open:

	Description: Acknowledge Re-Open
	Condition: On Correspond
	Custom condition:
	Action: Autoreply To Requestors
	Custom action preparation code:
	Custom action cleanup code:
	Template: ReOpenAcknowledgement

And make one more Scrip inside the spam queue called MoveToOriginalQueue, a slightly modified version of what was posted to rt-users:

	Description: MoveTicketToOriginalQueue
	Condition: On Correspond
	Custom condition:
	Action: User Defined
	Custom action preparation code: 1;
	Custom action cleanup code:
		
		# Stolen from:
		# MoveTicketToOriginalQueue.pm - Move ticket to the queue it was
		# originally destined for.
		# Phil Homewood  20020623
		
		my $queue;
		my $txn = $self->TicketObj->Transactions->First->Message->First;
		
		if ($queue = $txn->GetHeader('X-RT-Queue'))
		{
				return $self->TicketObj->SetQueue($queue);
		}
		
		return 0;
	
	Template: Global template: Blank

Good. That's it for the RT side. Now comes the mail side. Let's edit the RT user's .procmailrc file.

There are two things that must be done here. First, the X-RT-Queue header must be added with the name of the queue where the original email would go if it weren't spam. This is so the reply-to-reply coming in afterwards can send the original email to the original queue. Next, spam detected by SpamAssassin (or whatever spam detector you choose to use, keeping in mind that filters that depend on training are probably a very bad idea for this purpose) must be diverted to the spam queue.

Adding the header is simple, assuming you've done a RTQUEUE=queuename somewhere above:

	:0 Wf
	* RTQUEUE ?? .
	| /usr/bin/formail -i "X-RT-Queue: $RTQUEUE"

And redirecting spam is only slightly more difficult, and now you should have done RTACTION=action (correspond or comment) as well somewhere above:

	:0 Wc
	| spamc -c

	:0 Wa
	* RTQUEUE ?? .
	| rt-mailgate --queue $RTQUEUE --action $RTACTION --url http://rt/

	:0 W
	* RTQUEUE ?? .
	| rt-mailgate --queue spam --action $RTACTION --url http://rt/

That should be it.

Sun, 25 Apr 2004 23:11:26 -0700

Back to home page

Comments? a1qltmex@tinny.soundwave.net

Last updated: Sun, 25 Apr 2004 23:11:26 -0700