Approach for RT spam handling?

We use RT 3.2.1; looks sharp, and have been using RT since the 1.0 days.

Our users (internal and external) uses email to open RT tickets, and
appropriate personnel then works them via the web interface. Works out
great since the organization is pretty well geographically dispersed.

Since we deal with external customers, we get spam - usually due to
trojans scanning their address books and so forth. Nothing new there.

We run all inbound messages through a spam filter which is extremely
effective (prior to delivery to RT), but will never be 100% perfect so
some spam still slips through.

So we need to be able to select multiple tickets at once (the spam
stuff) and then mark them as being resolved (and preferrably,
auto-adding a generic explanation, like ‘spam; closing as resolved.’)
WITHOUT sending the usual resolved ticket reply to the spammer.

Any ideas or thoughts on how this might be best implemented?

Ideally, I’d like to be able to use the existing bulk ticket update
facilities since it meshes in well with the existing RT interface.

But how do I tell RT that the selected tickets (via bulk ticket update
screen) is spam and how to handle their resolution?

I was originally thinking of setting a custom field called 'MarkedSpam’
with a value of ‘IsSpam’ if set… and then modifying the global scrip
for On Resolve to check to see if this is enabled. If marked as spam,
don’t send a reply to the requestor. And also modify or add another
scrip to set ticket(s) to resolved.

But what puts an hole in that approach is there is no facility in the
bulk ticket update screen to mark a message as being spam.

The ultimate goal is to have an interface where the person working a RT
queue just selects a bunch of tickets, clicks on something to mark as
spam, and RT then closes these tickets without sending mail. That would
really save a lot of time when dealing with high traffic queues.

It would also offer us a way to skip tickets when doing the next bulk
export and save significant space and processing time on the import.

Also, I’m reluctant to customize the global scrips provided with RT
because I fear they could be overwritten by future RT upgrades… yet, I
don’t see a good way for an add-on scrip to conditionally suppress or
modify an existing global scrip’s behavior in certain situations.

If you were in my shoes, how would you approach a need to mark multiple
tickets as spam and resolve them without mail sent to the requestor…
thoughts?

-Dan

This could potentially help you:

http://tmda.net/

ShimiOn Sun, 2004-08-15 at 06:00, Dan Foster wrote:

We use RT 3.2.1; looks sharp, and have been using RT since the 1.0 days.

Our users (internal and external) uses email to open RT tickets, and
appropriate personnel then works them via the web interface. Works out
great since the organization is pretty well geographically dispersed.

Since we deal with external customers, we get spam - usually due to
trojans scanning their address books and so forth. Nothing new there.

We run all inbound messages through a spam filter which is extremely
effective (prior to delivery to RT), but will never be 100% perfect so
some spam still slips through.

So we need to be able to select multiple tickets at once (the spam
stuff) and then mark them as being resolved (and preferrably,
auto-adding a generic explanation, like ‘spam; closing as resolved.’)
WITHOUT sending the usual resolved ticket reply to the spammer.

Any ideas or thoughts on how this might be best implemented?

Ideally, I’d like to be able to use the existing bulk ticket update
facilities since it meshes in well with the existing RT interface.

But how do I tell RT that the selected tickets (via bulk ticket update
screen) is spam and how to handle their resolution?

I was originally thinking of setting a custom field called 'MarkedSpam’
with a value of ‘IsSpam’ if set… and then modifying the global scrip
for On Resolve to check to see if this is enabled. If marked as spam,
don’t send a reply to the requestor. And also modify or add another
scrip to set ticket(s) to resolved.

But what puts an hole in that approach is there is no facility in the
bulk ticket update screen to mark a message as being spam.

The ultimate goal is to have an interface where the person working a RT
queue just selects a bunch of tickets, clicks on something to mark as
spam, and RT then closes these tickets without sending mail. That would
really save a lot of time when dealing with high traffic queues.

It would also offer us a way to skip tickets when doing the next bulk
export and save significant space and processing time on the import.

Also, I’m reluctant to customize the global scrips provided with RT
because I fear they could be overwritten by future RT upgrades… yet, I
don’t see a good way for an add-on scrip to conditionally suppress or
modify an existing global scrip’s behavior in certain situations.

If you were in my shoes, how would you approach a need to mark multiple
tickets as spam and resolve them without mail sent to the requestor…
thoughts?

-Dan


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Be sure to check out the RT wiki at http://wiki.bestpractical.com

Never forget that:

  1. “Sure UNIX is user-friendly! It’s just picky about who its friends
    are!”
  2. “The day that Microsoft make a product that doesn’t suck,
    is the day they start making vacuum cleaners…”
  3. “Windows is a 32bit port for a 16bit GUI for an 8bit OS made for a
    4bit CPU by a 2bit company that can’t stand 1bit of competition!”

So we need to be able to select multiple tickets at once (the spam
stuff) and then mark them as being resolved (and preferrably,
auto-adding a generic explanation, like ‘spam; closing as resolved.’)
WITHOUT sending the usual resolved ticket reply to the spammer.
Any ideas or thoughts on how this might be best implemented?

I spent some time lookjing for a way to do this, and decided to do it
via a bookmarklet instead.

From the ‘new tickets’ page I just middle-click (to open in a new tab)
each obvous spam message, and then cycle through all those tabs just
clicking on my bookmarklet.

In our case we mark as ‘rejected’ rather than ‘resolved’ so that we get
distinct reporting, but you can always tweak it to your own needs:

javascript:void(document.location=document.location.href.replace(/Ticket/\w+.html?id=/,‘Ticket/Modify.html?Status=rejected;id=’))

I’m still open to better suggestions :slight_smile:

Tony

I would keep it simple, no customization

create spam queue, junk mail, phrase of your choice
configure it to not run standard resolved response
continue to use update all feature, just change queue and mark resolved
in one sweep

bonus - also allows you to passively keep a tally on number of spam
submissions.

rt@tmtm.com 8/15/2004 3:17:32 AM >>>

So we need to be able to select multiple tickets at once (the spam
stuff) and then mark them as being resolved (and preferrably,
auto-adding a generic explanation, like ‘spam; closing as
resolved.’)

We created a “Junk” queue. For spam, we mark as deleted and move to the Junk
Queue.

So we need to be able to select multiple tickets at once (the spam
stuff) and then mark them as being resolved (and preferrably,
auto-adding a generic explanation, like ‘spam; closing as resolved.’)
WITHOUT sending the usual resolved ticket reply to the spammer.

  1. Do a search that gets the spam tickets (and possibly others), then
    click on the “Update all these tickets at once” link.

  2. If your search has non-spam tickets, un-mark those.

  3. Change the status to “deleted”.

Steve

“Outlook not so good.” That magic 8-ball knows everything! I’ll ask
about Exchange Server next.
– (Stolen from the net)