Who gets to be a Requestor?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

(I’m running RT 3.4.2).

I’ve been under the impression that RT will add to the Requestor list for
a ticket the origin email address of anyone who corresponds on a ticket,
either to create it or for an existing ticket.

Yet, today I’m seeing a ticket that has been receiving correspondence from
an interested party, who was not the ticket’s creator, and he’s not
getting added as a Requestor. This means our ‘On Correspondence Notify
Requestors’ is not causing subsequent correspondence by others to get back
to this person. (As it happens, he’s the true responsible party to the
incident; the creator of the ticket was an outsider who reported the
incident to us and we subsequently notified the responsible party).

This person’s email address is already defined as a user to RT, because he
created a ticket with us some time ago. And the history of the ticket in
question does show his email userid in a ‘Correspondence added’ entry.

Meanwhile, this same person later created a new ticket on our RT system
and he did become the Requestor. So at least that part is working as I
would expect.

Could someone tell me the rules RT follows in adding Requestors to a
ticket?

Thanks.

Mike

Mike Friedman System and Network Security
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://ack.Berkeley.EDU/~mikef http://security.berkeley.edu

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBRCtKE60bf1iNr4mCEQJk+ACg5bq87OZd8KFAQoKjRsSqGRXmTGwAnR3n
RH5/iSUDVxhxxhM1TKGZZmCb
=KQMO
-----END PGP SIGNATURE-----

I’ve been under the impression that RT will add to the Requestor list for
a ticket the origin email address of anyone who corresponds on a ticket,
either to create it or for an existing ticket.

That’s not the case. If it were, I could add myself as a requestor on
all your tickets by spamming you. That could be kinda dangerous :wink:

Could someone tell me the rules RT follows in adding Requestors to a
ticket?

RT doesn’t automatically add requestors to tickets, though one could do
that with a scrip.

Jesse

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Wed, 29 Mar 2006 at 22:07 (-0500), Jesse Vincent wrote:

I’ve been under the impression that RT will add to the Requestor list
for a ticket the origin email address of anyone who corresponds on a
ticket, either to create it or for an existing ticket.

That’s not the case. If it were, I could add myself as a requestor on
all your tickets by spamming you. That could be kinda dangerous :wink:

Jesse,

That makes sense. I guess I was confused because we have a perl script
that sends notices to people and also updates RT, including setting the
Requestors to the recipients of our notices.

Also, since we already get so much spam, we have many tickets whose
Requestors are spam addresses (i.e., the creators of tickets). We are
planning to put up a spam interceptor, but we need to decide on the best
way to design this, because some incoming mail parcels that look like spam
actually are legitimate reports of spam (where the actual spam is being
forwarded by the complainant) that we are obligated to handle and track in
RT as well.

Anyway, thanks for helping me clear my mind.

Mike

Mike Friedman System and Network Security
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://ack.Berkeley.EDU/~mikef http://security.berkeley.edu

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBRCtvja0bf1iNr4mCEQLn+wCggQL1RjY5kPTLTeCb72gIsTIsA28An2Sm
IALsatZ9SZK7v05jMiZyZHNB
=wh/s
-----END PGP SIGNATURE-----

How about funnelling the SPAM reports through a known host so that the SPAM filter can whitelist that host and those messages will get through unscathed… Or create a separate alias for the spam e-mails that is whitelisted (and different from the e-mail address of the RT box).

Michael Eraña, CISSP
CTO
PC Network, Inc.
eranam@lanusa.com

|=> -----Original Message-----
|=> From: rt-users-bounces@lists.bestpractical.com
|=> [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf
|=> Of Mike Friedman
|=> Sent: Thursday, March 30, 2006 12:41 AM
|=> To: Jesse Vincent
|=> Cc: rt-users@lists.bestpractical.com
|=> Subject: Re: [rt-users] Who gets to be a Requestor?
|=>
|=> -----BEGIN PGP SIGNED MESSAGE-----
|=> Hash: SHA1
|=>
|=> On Wed, 29 Mar 2006 at 22:07 (-0500), Jesse Vincent wrote:
|=>
|=> >> I’ve been under the impression that RT will add to the
|=> Requestor list
|=> >> for a ticket the origin email address of anyone who
|=> corresponds on a
|=> >> ticket, either to create it or for an existing ticket.
|=> >
|=> > That’s not the case. If it were, I could add myself as a
|=> requestor on
|=> > all your tickets by spamming you. That could be kinda dangerous :wink:
|=>
|=> Jesse,
|=>
|=> That makes sense. I guess I was confused because we have a
|=> perl script that sends notices to people and also updates
|=> RT, including setting the Requestors to the recipients of
|=> our notices.
|=>
|=> Also, since we already get so much spam, we have many
|=> tickets whose Requestors are spam addresses (i.e., the
|=> creators of tickets). We are planning to put up a spam
|=> interceptor, but we need to decide on the best way to
|=> design this, because some incoming mail parcels that look
|=> like spam actually are legitimate reports of spam (where
|=> the actual spam is being forwarded by the complainant) that
|=> we are obligated to handle and track in RT as well.
|=>
|=> Anyway, thanks for helping me clear my mind.
|=>
|=> Mike
|=>
|=> ____________________________________________________________
|=> _________
|=> Mike Friedman System and Network Security
|=> mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
|=> 1-510-642-1410 University of California at Berkeley
|=> http://ack.Berkeley.EDU/~mikef
|=> http://security.berkeley.edu
|=> ____________________________________________________________
|=> _________
|=>
|=> -----BEGIN PGP SIGNATURE-----
|=> Version: PGP 6.5.8
|=>
|=> iQA/AwUBRCtvja0bf1iNr4mCEQLn+wCggQL1RjY5kPTLTeCb72gIsTIsA28An2Sm
|=> IALsatZ9SZK7v05jMiZyZHNB
|=> =wh/s
|=> -----END PGP SIGNATURE-----
|=> _______________________________________________
|=> The rt-users Archives
|=>
|=> Community help: http://wiki.bestpractical.com Commercial
|=> support: sales@bestpractical.com
|=>
|=>
|=> Discover RT’s hidden secrets with RT Essentials from
|=> O’Reilly Media.
|=> Buy a copy at http://rtbook.bestpractical.com
|=>
|=>
|=> We’re hiring! Come hack Perl for Best Practical:
|=> http://bestpractical.com/about/jobs.html
|=>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

How about funnelling the SPAM reports through a known host so that the
SPAM filter can whitelist that host and those messages will get through
unscathed… Or create a separate alias for the spam e-mails that is
whitelisted (and different from the e-mail address of the RT box).

Michael,

The problem is not how to do the initial filtering. It’s that only a
human being (not a program or script) can tell the difference between
forwarded spam that’s part of a legitimate spam report and original
spam, both of which are likely to be flagged by spam detectors. (After
all, the format of a mail message containing forwarded spam could be
almost anything).

So, one possibility is to divert all apparent spam (before it reaches RT)
into a mailbox that a person would have to look at. This person would
bounce the legitimate reports on to RT, throwing away the rest (i.e., the
actual spam). Unfortunately, this promises to be such a waste of
someone’s time, because the legitimate reports are only a tiny percentage
of all mail that’s flagged as spam.

Mike

|=> We are planning to put up a spam interceptor, but we need to decide on
|=> the best way to design this, because some incoming mail parcels that
|=> look like spam actually are legitimate reports of spam (where the
|=> actual spam is being forwarded by the complainant) that we are obligated
|=> to handle and track in RT as well.
|=>
|=> Mike

Mike Friedman System and Network Security
mikef@ack.Berkeley.EDU 2484 Shattuck Avenue
1-510-642-1410 University of California at Berkeley
http://ack.Berkeley.EDU/~mikef http://security.berkeley.edu

-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.8

iQA/AwUBRC1oJ60bf1iNr4mCEQJo9wCaAz2RY0IP4fG6S7d6ui7sEHkClQsAn2ti
4lmeBIY028Y+ncysDkdyBKmW
=HYPR
-----END PGP SIGNATURE-----