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&id=".$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@ics.com  Fri Nov 22 08:17:17 2002Date: Fri, 22 Nov 2002 10:16:59 -0300 (GMT)
From: Mail Delivery Subsystem <MAILER-DAEMON@sirsield.sinectis.com.ar>
To: <support-admin@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@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@ics.com>
Reply-To: keys@ics.com
To: debra5427@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

Tony Aiuto wrote:

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.

Spamassassin doesn’t have to be used to delete mail. We use it
to shuffle the suspected spam into a “spam” queue. That queue
has a different autoack which the user must reply to for the
ticket to jump from the spam queue to the intended queue.
The hackery to do this has been posted to this list before;
a search should find it. If enough people think it’s useful,
I’ll add it to RT/FM, too.

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!

Er. No. That way lies pain. :^)

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

These have to be hand checked and deleted. Does anyone else have a
similar problem?

Yes. but not enough to have annoyed me yet.

Have they whacked rt-mailgate to look for bounces
like this and kill the corresponding ticket?
I think the The criteria

It’s been mentioned here before but I don’t know if anyone’s
actually done it.

I’d actually recommend against hacking rt-mailgate for this.
If you don’t identify a bounce as such (${DEITY} knows, there
are enough weirdo MTAs with oddball bounce boilerplate out there)
you’ll end up in evil loopville once again.

Instead…

Mail is from MAILER-DAEMON
Body contains
----- The following addresses had permanent fatal errors -----
Body contains
Subject: [] Support case acknowledged: …

could be checked from a procmail (or similar) recipe running
as the support-admin user, and the ticket gets killed using
rt’s command line tools. The fun part would be pulling the
ticket number out of the bounce mess and communicating it to
/path/to/rt/bin/rt.

Also, watch out for real users whose mail bounces due to
transient problems.

: From: luser@example.com
: To: helpdesk@example.com
: Subject: Help, my mailbox is full
:
: My mailbox is full. Mail to me is bouncing.
: Can you please clean it out? Thanks.
Phil Homewood, Systems Janitor, www.SnapGear.com
pdh@snapgear.com Ph: +61 7 3435 2810 Fx: +61 7 3891 3630
SnapGear - Custom Embedded Solutions and Security Appliances

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@ics.com]
Sent: Friday, November 22, 2002 8:08 AM
To: rt-users@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@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@sirsield.sinectis.com.ar
To: support-admin@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@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@ics.com
Reply-To: keys@ics.com
To: debra5427@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@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