Re: [rt-users] permanently squelching a user
--- On Fri, 5/23/08, Kimberly McKinnis <[EMAIL PROTECTED]> wrote:
> 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=;
@[EMAIL PROTECTED];
# 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:
[EMAIL PROTECTED]@
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.
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] permanently squelching a user
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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
Re: [rt-users] permanently squelching a user
--- On Fri, 5/23/08, Kimberly McKinnis <[EMAIL PROTECTED]> 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. ___ http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users Community help: http://wiki.bestpractical.com Commercial support: [EMAIL PROTECTED] Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
[rt-users] permanently squelching a user
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/ [EMAIL PROTECTED]/){
$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
___
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: [EMAIL PROTECTED]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
