I’m looking at RT for handling an “abuse” queue. Does anyone
have any experience with this that he’d care to share? (See
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?).
% 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.
% 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.
% 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