RT for Abuse handling? Bounce mail?

I’m looking at RT for handling an “abuse” queue. Does anyone
have any experience with this that he’d care to share? (See
below.)

Right now I’m thinking about recording delivery notification
failures, since the subject is often changed. Taking into
account the formatting of our MTA’s bounce messages is one
thing, but has anyone tried compiling something to handle the
bounce format of a lot of MTA’s?

For those who didn’t follow the above paragraph, I’ll try to
restate it; I’m thinking about filtering RT mail through a
script that will recognize delivery failures for mail sent by
the RT users to the outside, and reformat those delivery notices
so that RT knows to put them into the right ticket.

FWIW, I include two mails I’ve written, searching for an abuse
solution. RT was recommended. I think RT1 can cut it nicely,
but RT2 seems to have extremely interesting additional features
such as super-tickets and sub-tickets (fifty people complained
abot this guy, the super-ticket is our correspondence with
that guy, and the sub-tickets are the correspondence with the
complainants, do I get the concept right?).

Mail1

% I’m in the market for an abuse desk solution, but I have
% trouble finding candidates. Maybe I just don’t know the
% magical words for Google et al. :frowning:
%
% After a first quick look, I’m afraid that the traditional
% client e-amil handling solutions don’t handle the fact that
% there are two (or even more) channels of communication: you
% reply to the complainant, you mail the accused’s provider, the
% accused himself if you get his e-mail, even the CERT. You have
% to take into account that there will (hopefully) be a lot of
% complaints for a single accused, the accused may not know who
% complains unless you do it on purpose, but it should be easy
% for the abuse handler to look up the status of a complaint
% starting from the complainant’s tracking number, etc. Of
% course you need lots of statistics, you need the history and
% status of an accused client of yours at your fingertips, etc.

Mail2

% My problem is that I just can’t find any software that even
% mentions abuse handling.
%
% Abuse handling, when it’s well done, is a rather special
% thing, after all. You have people writing in, and you reply to
% them, like a normal helpdesk. On the other hand, most of the
% incoming complaints give rise to a complaint created by us,
% which we have to track too. You can have a hundred incoming
% complaints for one outgoing complaint, so you have to have a
% link between the incoming and the outgoing complaints, but you
% can’t let the complainant know the address of the person we’re
% complaining to – legal problem. Then there way be multiple
% actions undertaken against one client (correspondence with
% him, correspondence with the guy who actually removes his
% access . . .).

#include <std_disclaim.h> Lorens Kockum

I’m a bit worried that I’ve not received more response to the
mail below.

Is there anyone out there actually using RT for abuse handling?
Does anyone know of other solutions that would be better at
handling abuse? I’ve looked around, but haven’t found anything.

As for handling bounces, I think I’ll be able to do it myself if
no one else has done it.On Mon, Jan 29, 2001 at 06:35:46PM +0100, Lorens Kockum wrote:

I’m looking at RT for handling an “abuse” queue. Does anyone
have any experience with this that he’d care to share? (See
below.)

Right now I’m thinking about recording delivery notification
failures, since the subject is often changed. Taking into
account the formatting of our MTA’s bounce messages is one
thing, but has anyone tried compiling something to handle the
bounce format of a lot of MTA’s?

For those who didn’t follow the above paragraph, I’ll try to
restate it; I’m thinking about filtering RT mail through a
script that will recognize delivery failures for mail sent by
the RT users to the outside, and reformat those delivery notices
so that RT knows to put them into the right ticket.

FWIW, I include two mails I’ve written, searching for an abuse
solution. RT was recommended. I think RT1 can cut it nicely,
but RT2 seems to have extremely interesting additional features
such as super-tickets and sub-tickets (fifty people complained
abot this guy, the super-ticket is our correspondence with
that guy, and the sub-tickets are the correspondence with the
complainants, do I get the concept right?).

Mail1

% I’m in the market for an abuse desk solution, but I have
% trouble finding candidates. Maybe I just don’t know the
% magical words for Google et al. :frowning:
%
% After a first quick look, I’m afraid that the traditional
% client e-amil handling solutions don’t handle the fact that
% there are two (or even more) channels of communication: you
% reply to the complainant, you mail the accused’s provider, the
% accused himself if you get his e-mail, even the CERT. You have
% to take into account that there will (hopefully) be a lot of
% complaints for a single accused, the accused may not know who
% complains unless you do it on purpose, but it should be easy
% for the abuse handler to look up the status of a complaint
% starting from the complainant’s tracking number, etc. Of
% course you need lots of statistics, you need the history and
% status of an accused client of yours at your fingertips, etc.

Mail2

% My problem is that I just can’t find any software that even
% mentions abuse handling.
%
% Abuse handling, when it’s well done, is a rather special
% thing, after all. You have people writing in, and you reply to
% them, like a normal helpdesk. On the other hand, most of the
% incoming complaints give rise to a complaint created by us,
% which we have to track too. You can have a hundred incoming
% complaints for one outgoing complaint, so you have to have a
% link between the incoming and the outgoing complaints, but you
% can’t let the complainant know the address of the person we’re
% complaining to – legal problem. Then there way be multiple
% actions undertaken against one client (correspondence with
% him, correspondence with the guy who actually removes his
% access . . .).


#include <std_disclaim.h> Lorens Kockum


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

#include <std_disclaim.h> Lorens Kockum

Lorens,

Is there anyone out there actually using RT for abuse handling?
Does anyone know of other solutions that would be better at
handling abuse? I’ve looked around, but haven’t found anything.

For what it’s worth, I’m looking at RT for the exact same reason.
I haven’t played with it enough to be able to consider how it
fills all my needs yet. (Still trying to get the e-mail portion
to work right – the webrt part is terrific!)

For those who didn’t follow the above paragraph, I’ll try to
restate it; I’m thinking about filtering RT mail through a
script that will recognize delivery failures for mail sent by
the RT users to the outside, and reformat those delivery notices
so that RT knows to put them into the right ticket.

I should think that procmail in front of RT might be a handy method.
It’s got a FROM_DAEMON pattern that matches many, many computer-sent
messages. Then code some sort of “if (FROM_DAEMON) then (create
reformatted mail and deliver to rt queue)” procmail action. Again,
I’m still green at RT, so take my advice with caution.

En paz,
Steve
Stephen W. Thompson, UPenn, ISC Information Security, 215-898-1236, WWW has PGP
thompson@isc.upenn.edu URL=http://pobox.upenn.edu/~thompson/index.html
The only safe choice: Write e-mail as if it’s public. Cuz it could be.

I’m a bit worried that I’ve not received more response to the
mail below.

Is there anyone out there actually using RT for abuse handling?

MAPS is, actually, but we're about to switch over to RT2.  The
bounce handling you mentioned sounds great; it's something we've
muttered about adding in a few months, after the more pressing
stuff has stabilized.

Does anyone know of other solutions that would be better at
handling abuse? I’ve looked around, but haven’t found anything.

There're a couple that might be equal to RT1, but I don't think
anything can beat RT2 for abuse queue handling.

As for handling bounces, I think I’ll be able to do it myself if
no one else has done it.

I'd love to see what you come up with.

J.D. Falk “The Internet isn’t just a publishing medium or a
Product Manager medium for commerce, it’s a social medium.”
Mail Abuse Prevention System LLC – Howard Rheingold

We are also using RT for abuse handling. 10k+ tickets so far with just a few
problems. JD, I’m curious as to how stable you find RT2 to be. My understanding
was that the mail gateway was still a little iffy, and thats the most important
part for my needs. Any comments?On Thu, Feb 08, 2001 at 02:24:42PM -0800, J.D. Falk wrote:

On 02/08/01, Lorens Kockum rt-id-45@lists.lorens.org wrote:

I’m a bit worried that I’ve not received more response to the
mail below.

Is there anyone out there actually using RT for abuse handling?

MAPS is, actually, but we’re about to switch over to RT2. The
bounce handling you mentioned sounds great; it’s something we’ve
muttered about adding in a few months, after the more pressing
stuff has stabilized.

Does anyone know of other solutions that would be better at
handling abuse? I’ve looked around, but haven’t found anything.

There’re a couple that might be equal to RT1, but I don’t think
anything can beat RT2 for abuse queue handling.

As for handling bounces, I think I’ll be able to do it myself if
no one else has done it.

I’d love to see what you come up with.


J.D. Falk “The Internet isn’t just a publishing medium or a
Product Manager medium for commerce, it’s a social medium.”
Mail Abuse Prevention System LLC – Howard Rheingold


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

We are also using RT for abuse handling. 10k+ tickets so far with just a few
problems.

Oooh, way cool. And how do you handle

  1. The fact that you get lots of complaints (n) for one user,
    so you have n+1 channels of communication. You can merge all
    the complaints, of course, but that’s still 2 channels of
    communication.

  2. Classification/stats? Wanna know how many spam complaints
    this week, how many scans of our corporate servers, etc. RT2
    keywords seem ideal, how to get around it in RT1?

JD, I’m curious as to how stable you find RT2 to be. My
understanding was that the mail gateway was still a little iffy,
and thats the most important part for my needs. Any comments?

Hear, hear.

#include <std_disclaim.h> Lorens Kockum

We are also using RT for abuse handling. 10k+ tickets so far with just a few
problems.

Oooh, way cool. And how do you handle

  1. The fact that you get lots of complaints (n) for one user,
    so you have n+1 channels of communication. You can merge all
    the complaints, of course, but that’s still 2 channels of
    communication.
Think of each ticket as a conversation, instead of an incident.
You've got a conversation going on with each complainant, and
with the accused abuser, each in an individual ticket.

With RT2 you can create relationships (parent/child, etc) between
tickets to help keep the incidents straight; that's just one of
the many places where RT2 will be better for abuse than RT1.
  1. Classification/stats? Wanna know how many spam complaints
    this week, how many scans of our corporate servers, etc. RT2
    keywords seem ideal, how to get around it in RT1?
Comments, grep, etc.

JD, I’m curious as to how stable you find RT2 to be. My
understanding was that the mail gateway was still a little iffy,
and thats the most important part for my needs. Any comments?

Hear, hear.

We're starting to move over to our internally frozen snapshot 
of RT2 this week; we want to rejoin Jesse's source tree as soon
as we're confident that the snapshot will be stable.

J.D. Falk “The Internet isn’t just a publishing medium or a
Product Manager medium for commerce, it’s a social medium.”
Mail Abuse Prevention System LLC – Howard Rheingold