[rt-users] Strategies for coping with spam

[Brian Shellabarger]

Here's how I do it:

I use spamassassin -- it's wonderful, it really really is!! And this
configuration presents 0 risk of losing a customer email. Here's how:


-- In your /etc/aliases file, direct the mail to the queues like this:

customerservice: "|/usr/bin/procmail -m /etc/rt2.procmailrc
customerservice correspond"



-- The contents of /etc/rt2.procmailrc might look like this:

### This tells spamassassin not to process mail with large attachments
:0fw
* < 256000
| /usr/local/bin/spamassassin

### If the spam level is above 12, trash it. It's DEFINITELY not from a
customer
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*
/dev/null

### Send the mail to a separate queue if we think it's spam (DON'T
change the header!)
:0:
* ^X-Spam-Status: Yes
| /usr/local/rt2/bin/rt-mailgate --queue spam --action $2

### Otherwise, deliver to the queue we specified in /etc/aliases
:0:
* .*
| /usr/local/rt2/bin/rt-mailgate --queue $1 --action $2


.. You can also configure SpamAssassin to alter the header and add a
[spam] tag to the subjects if you wish that to show up in RT.. But it's
not really necessary since it gets diverted to the spam queue.

This makes it so that you accomplish a number of things:
1> DEFINITE spam is deleted and you are not bothered with it
2> Possible spam is delivered to a specific queue where it can be sorted
through and re-assigned to other queues if needs be -- or it can be mass
deleted. This leaves 0 risk of losing a customer email.
3> You can use procmail to assist you with other functions of filtering
if you wish
4> All other email is completely unaffected.
5> I don't have to change anything with RT itself. All filtering is done
externally.

This is working splendidly for me.

Brian





-----Original Message-----
From: Tony Aiuto [mailto:tony at ics.com] 
Sent: Friday, November 22, 2002 8:08 AM
To: rt-users at lists.fsck.com
Subject: [rt-users] Strategies for coping with spam



Does anyone have any thoughts to share about coping with spam in the
context of a customer support?   We chose not to use a filter like
spamassassin on our support email because we don't want to risk ignoring
customer mail.  What we end up seeing is at least 5 or 10 spams a day
which create tickets.

Right now we hand kill the junk ticket.   I made a shortcut to help
with that.  In WebRt/html/Ticket/Elements/Tabs:

      if ($Ticket->Status ne 'open') {
          $actions->{'Open'} =
            {
             path => "Ticket/Display.html?Status=open&id=". $id,
             title => 'Open'
            };
      }
+     if ($Ticket->CurrentUserHasRight('OwnTicket')) {
+      $actions->{'SPAM'} = {
+      path  =>
"Ticket/Display.html?Status=dead&KeywordSelectMagic7&KeywordSelect7=67&i
d=".$id,
+      title => 'SPAM'
+      };
+     }
  }

  if (defined $session{'tickets'}) {
      my $items = $session{'tickets'}->ItemsArrayRef();
      my @indexs = grep(($items->[$_]->id == $Ticket->Id), 0 ..
$#{$items});

And in WebRT/html/Ticket/Display.html

*** 142,149 ****
--- 147,156 ----
        }
  #Process status updates
  my @BasicActions = ProcessTicketBasics(ARGSRef => \%ARGS,
TicketObj=>$Ticket);
+ my @keywordActions = ProcessTicketObjectKeywords(TicketObj => $Ticket,

+ ARGSRef => \%ARGS);
  
  push (@Actions, @BasicActions);
+ push (@Actions, @keywordActions);
  }
  </%INIT>
  

Together, this adds a [SPAM] link which marks the ticket dead and sets a
'reason for closure' keyword to 'SPAM'.   The magic #'s 7 and 67 are,
of course, site specific.

But that only eases some of the pain.

Most of these emails have invalid sender addresses.  RT generates
the autoresponse, and it bounces.   One thing for certain, you should
never make the outgoing mail envelope address be a live queue address!
That will give you an evil loop.   What I do for that is change the
sendmail args to spoof the sender, like so (config.pm)

	$SendmailArguments="-oi -t -fsupport-admin";

and then I also have to allow the user which runs the web server and
mailer processes be trusted by sendmail.  On my installation, apache
runs as httpd, and incoming mail becomes mailnull, so you have to add

	Thttpd mailnull

to sendmail.cf (and also submit.cf - for newer versions of sendmail).


So now, support-admin (me) gets a bunch of mails like this every day.

	From MAILER-DAEMON at ics.com  Fri Nov 22 08:17:17 2002
	Date: Fri, 22 Nov 2002 10:16:59 -0300 (GMT)
	From: Mail Delivery Subsystem
<MAILER-DAEMON at sirsield.sinectis.com.ar>
	To: <support-admin at ics.com>
	Subject: Returned mail: see transcript for details
	Auto-Submitted: auto-generated (failure)

	This is a MIME-encapsulated message
	--gAMDGxRT003562.1037971019/sirsield.sinectis.com.ar
	The original message was received at Fri, 22 Nov 2002 10:15:56
-0300 (GMT)
	from ics.com [216.112.183.3]
	   ----- The following addresses had permanent fatal errors
-----
	<debra5427 at uole.com>
	    (reason: User unknown)

	   ----- Transcript of session follows -----

	.... snip snip snip ....

	Subject: [ICS #291] Support case acknowledged: Lender's Network
Mortgage
	From: "keys" <keys at ics.com>
	Reply-To: keys at ics.com
	To: debra5427 at uole.com

These have to be hand checked and deleted.  Does anyone else have a
similar problem?   Have they whacked rt-mailgate to look for bounces
like this and kill the corresponding ticket?  I think the The criteria
would be

	Mail is from MAILER-DAEMON
	Body contains
	   ----- The following addresses had permanent fatal errors
-----
	Body contains
	   Subject: [<valid RT ticket ident>] Support case acknowledged:
......


Again, does anyone have interesting spam mitigation hacks to share?

-tony

_______________________________________________
rt-users mailing list
rt-users at lists.fsck.com http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm