Permanently squelching a user

RT Users
1

So here’s my setup: I have an ‘alert’ email for tickets, and a ‘support’
email for tickets. Alert cc’s our cell phones (via /etc/aliases) and
sets the ticket to a high priority (via a scrip based on to: email
headers) . Support goes to the same queue but simply notifies the
adminCCs via email. The problem is that since I’m using the script from
the wiki to add ccs as watchers, the alert email keeps getting added to
tickets as a cc, even though support owns them. This results in
everyone’s cell phones getting sms’d every time there is a reply to an
alert ticket. Even after I remove alert from the ticket, users continue
to reply to the initial email where alert was cc’d.

For some reason the part of the script that doesn’t add the cc if a user
is an RT user isn’t working for this email.

I attempted to shove the alert email into @blacklist in SendEmail.pm,
which seemed to work, but unrelated scrips are now failing. (Errors
below.) I’m open to suggestions if I’m going about this completely
wrong.

I added the following code into SendEmail.pm:

foreach my $address (qw/ alert@tivo.com/){

  $RT::Logger->debug("squelching alert");

   push @blacklist, $address;

   }

/var/log/rt/rt.log displays the following when replying to a ticket with
alert cc’d:

[Fri May 23 01:26:14 2008] [debug]: Found 5 scrips
(/usr/lib/rt/RT/Scrips_Overlay.pm:356)

[Fri May 23 01:26:14 2008] [error]: Scrip Prepare 3 died. - Can’t locate
object method “new” via package “RT::Action::Autoreply” at
/usr/lib/rt/RT/ScripAction_Overlay.pm line 178.

Stack:

[/usr/lib/rt/RT/ScripAction_Overlay.pm:178]

[/usr/lib/rt/RT/Scrip_Overlay.pm:473]

[/usr/lib/rt/RT/Scrips_Overlay.pm:236]

[/usr/lib/rt/RT/Transaction_Overlay.pm:162]

[/usr/lib/rt/RT/Record.pm:1438]

[/usr/lib/rt/RT/Ticket_Overlay.pm:720]

[/usr/local/rt/lib/RT/Interface/Email.pm:793]

[/var/rt/html/REST/1.0/NoAuth/mail-gateway:58]

(/usr/lib/rt/RT/Scrip_Overlay.pm:481)

[Fri May 23 01:26:14 2008] [error]: Scrip Prepare 4 died. - Can’t locate
object method “new” via package “RT::Action::Notify” at
/usr/lib/rt/RT/ScripAction_Overlay.pm line 178.

Stack:

[/usr/lib/rt/RT/ScripAction_Overlay.pm:178]

[/usr/lib/rt/RT/Scrip_Overlay.pm:473]

[/usr/lib/rt/RT/Scrips_Overlay.pm:236]

[/usr/lib/rt/RT/Transaction_Overlay.pm:162]

[/usr/lib/rt/RT/Record.pm:1438]

[/usr/lib/rt/RT/Ticket_Overlay.pm:720]

[/usr/local/rt/lib/RT/Interface/Email.pm:793]

[/var/rt/html/REST/1.0/NoAuth/mail-gateway:58]

(/usr/lib/rt/RT/Scrip_Overlay.pm:481)

[Fri May 23 01:26:14 2008] [debug]: About to commit scrips for
transaction #3535 (/usr/lib/rt/RT/Transaction_Overlay.pm:169)

Kimberly McKinnis

System Operations Engineer

Service Provider Division, TiVo Inc

408-519-9607

2

So here’s my setup: I have an ‘alert’ email for
tickets, and a ‘support’
email for tickets. Alert cc’s our cell phones (via
/etc/aliases) and
sets the ticket to a high priority (via a scrip based on
to: email
headers) . Support goes to the same queue but simply
notifies the
adminCCs via email. The problem is that since I’m using
the script from
the wiki to add ccs as watchers, the alert email keeps
getting added to
tickets as a cc, even though support owns them. This
results in
everyone’s cell phones getting sms’d every time
there is a reply to an
alert ticket. Even after I remove alert from the ticket,
users continue
to reply to the initial email where alert was cc’d.

I attempted to shove the alert email into @blacklist in
SendEmail.pm,
which seemed to work, but unrelated scrips are now failing.
(Errors
below.) I’m open to suggestions if I’m going about
this completely
wrong.

I’ve written a multi purpose ‘spam/text/sender/receiver filter’ which sits between sendmail/postfix and RT. Basicially, it works like this:

Instead of having an entry in /etc/aliases pointing to RT, the alias points to my script. The script analyzes the whole email and looks for certain text strings. If they exist (or don’t exist, depending on the need), it opens a pipe to RT and passes the email along; if the conditions are met where it shouldn’t go into RT, it’s dropped.
If you’d like a copy of my perl script, let me know.

3

Yes please! I’ll drop it onto my RT testbed and see how it incorporates
into the system. I originally thought there must be a simpler way to do
this, but procmail wasn’t working out either.-----Original Message-----
From: Joseph Spenner [mailto:joseph85750@yahoo.com]
Sent: Friday, May 23, 2008 11:46 AM
To: rt-users@lists.bestpractical.com
Cc: Kimberly McKinnis
Subject: Re: [rt-users] permanently squelching a user

— On Fri, 5/23/08, Kimberly McKinnis kmckinnis@tivo.com wrote:

So here’s my setup: I have an ‘alert’ email for
tickets, and a ‘support’
email for tickets. Alert cc’s our cell phones (via
/etc/aliases) and
sets the ticket to a high priority (via a scrip based on
to: email
headers) . Support goes to the same queue but simply
notifies the
adminCCs via email. The problem is that since I’m using
the script from
the wiki to add ccs as watchers, the alert email keeps
getting added to
tickets as a cc, even though support owns them. This
results in
everyone’s cell phones getting sms’d every time
there is a reply to an
alert ticket. Even after I remove alert from the ticket,
users continue
to reply to the initial email where alert was cc’d.

I attempted to shove the alert email into @blacklist in
SendEmail.pm,
which seemed to work, but unrelated scrips are now failing.
(Errors
below.) I’m open to suggestions if I’m going about
this completely
wrong.

I’ve written a multi purpose ‘spam/text/sender/receiver filter’ which
sits between sendmail/postfix and RT. Basicially, it works like this:

Instead of having an entry in /etc/aliases pointing to RT, the alias
points to my script. The script analyzes the whole email and looks for
certain text strings. If they exist (or don’t exist, depending on the
need), it opens a pipe to RT and passes the email along; if the
conditions are met where it shouldn’t go into RT, it’s dropped.
If you’d like a copy of my perl script, let me know.

4

Yes please! I’ll drop it onto my RT testbed and see how
it incorporates
into the system. I originally thought there must be a
simpler way to do
this, but procmail wasn’t working out either.

I’ve written a multi purpose
‘spam/text/sender/receiver filter’ which
sits between sendmail/postfix and RT. Basicially, it works
like this:

Instead of having an entry in /etc/aliases pointing to RT,
the alias
points to my script. The script analyzes the whole email
and looks for
certain text strings. If they exist (or don’t exist,
depending on the
need), it opens a pipe to RT and passes the email along; if
the
conditions are met where it shouldn’t go into RT,
it’s dropped.

Here’s my script:

#!/usr/bin/perl

put the contents of the message into an array

@originalMessage=;

@scanThis=@originalMessage;

weed out the html tags

foreach $line (@scanThis) {
$line =~ s/<[^>]*>//g;
}

get message into a string so we can search it

$messageString1=join(" “, @scanThis);
$messageString2=join(” ", @originalMessage);

$messageString = “$messageString1 $messageString2”;

get all the bad content lines from datafile

open (BADLINES, “/home/gman/scripts/badlines.txt”);
@badlines=;
close BADLINES;

if the message contains bad content, exit

foreach $line (@badlines) {
chomp $line;
if ($messageString =~ m/$line/i) {
exit 0;
}
}

we found nothing bad, so pass it through to RT

open (PIPE, “|/opt/rt2/bin/rt-mailgate --queue customer_probs --action correspond”);
print PIPE @originalMessage;
close PIPE;

I’m still using RT2, and the line:
“|/opt/rt2/bin/rt-mailgate --queue customer_probs --action correspond”

is directly from /etc/aliases. I’m not sure how it is done in RT3, but I’m sure it’s similar.

The file:
/home/gman/scripts/badlines.txt
Should contain text strings which have content to cause the message to never make it to RT. Each line should contain its own text to block.

You may need to escape certain characters, such as “@” and “*”. Here’s a section of my badlines.txt:

vi@gr@
F*R*E*E
health insurance rates
chat with singles
100% risk free
EXERC1SE

Each line of the badlines.txt should contain text you want to block.