A question about correspond

RT Users
1

I’d like to hack up RT so it will never send an email to the requester
based on another incoming email, whether its a comment or a correspond.
Correct me if I’m wrong. When someone replies to a comment in a
correspond queue, rt will forward that comment to the requestor.
This happens around line 131 in database.pm (in add_transaction).
If I don’t ever want an email to a requestor triggered by
an incoming email to the ticket, I should be able to comment that
whole “if ($queues{$queue_id}{m_user_trans}” statement out. The
only time I want an email sent out to a requestor is when I click
on reply in the web UI. Nothing else should generate an email to
the customer. Am I on the right track? The reason I ask, is that
I did comment all that stuff out (from line 131 to 137) and an email
was still sent to the requestor based on a reply to a cc’d comment
for a ticket in a correspond queue. Any ideas?

The problem I’m trying to solve is as follows. We have incoming complaints about
abuse (spam, etc) coming in to the incoming-abuse queue, which is a correspond
queue. This creates the ticket and sends off an autoreply. The next step is to
evaluate the ticket to see if its actual abuse or not. If it is, we move it to
the ‘incidents’ queue, which is a comment queue. We then send out comments (cc’d)
to the appropriate staff to deal with the user. The deal with them and reply back
to us. When this process works
correctly, we have no problem. The customer never see’s anything. But, if
someone, in the heat of the moment, forgets to switch the ticket from the
incoming-abuse queue, and sends out cc’d comments to internal personel, their
replies get sent to the customer, which leads to all sorts of messy situations
where we don’t want the requestor seeing what we are saying. Perhaps there’s an
easier solution to my problem that someone could suggest, but if not, I need some
help figuring out the problem in database.pm.

Thanks!

2

Well, my understanding is that incoming messages to a comment queue
cannot create a new ticket, which doesn’t work for us. Perhaps I’m
wrong? If I am wrong, this would solve my problem.

Under my install (1.0.2) I’ve got comment queues taking new requests.
I think you are covered here.

How do you hagve them configured? I just tried on 1.0.4 and its not working.
Bounces saying I need a ticket number

Nothing fancy:

from /etc/aliases (for the “testing” queue):
testing: “| /usr/local/rt/bin/rt-mailgate testing comment”

The queues are set with “Allow non-members to create requests”, but I
doubt that is your problem as you said it worked with correspond
queues.

To be honest, I’m not sure where to look to find a config parameter
that would affect this setting – I don’t recall changing anything
from the defaults to make this work. I’m cc:ing back to the list in
case someone else has more info.

— Eric

3

You can only create new tickets by sending mail to a “correspond” alias.On Mon, Aug 21, 2000 at 09:47:05AM -0700, Eric Goodman wrote:

At 6:25 PM -0600 8/20/2000, Wozz wozz+rt@wookie.net wrote:

Well, my understanding is that incoming messages to a comment queue
cannot create a new ticket, which doesn’t work for us. Perhaps I’m
wrong? If I am wrong, this would solve my problem.

Under my install (1.0.2) I’ve got comment queues taking new requests.
I think you are covered here.

How do you hagve them configured? I just tried on 1.0.4 and its not working.
Bounces saying I need a ticket number

Nothing fancy:

from /etc/aliases (for the “testing” queue):
testing: “| /usr/local/rt/bin/rt-mailgate testing comment”

The queues are set with “Allow non-members to create requests”, but I
doubt that is your problem as you said it worked with correspond
queues.

To be honest, I’m not sure where to look to find a config parameter
that would affect this setting – I don’t recall changing anything
from the defaults to make this work. I’m cc:ing back to the list in
case someone else has more info.

— Eric

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

jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
Linux is like a Vorlon. It is incredibly powerful, gives terse,
cryptic answers and has a lot of things going on in the background.

4

You can only create new tickets by sending mail to a “correspond” alias.

We’ve had trouble with this one, too. The problem usage goes like this:

(1) “Alice” creates ticket.
(2) “Bob” comments on ticket using the Web interface. Comment is copied
to all queue members via email.
(3) Queue member “Charlie” replies to the email comment received from Bob.
Since the email originates from RT, it goes back to RT.
(4) RT assumes the email is a correspondence and sends it back to Alice.
(5) Alice takes exception to Charlie’s comments!

We’ve basically had to turn off comments altogether because this happened
too many times.

I think there is a good solution to this:

(1) The queue admin sets up two aliases, “queue” and “queue-comment”.
(This is already supported.)
(2) If a queue member creates a reply, the email reply originates from
“queue”. (This is as it is today.)
(3) If a queue member creates a comment, the email comment originates from
“queue-comment”. (This needs to be added.
(4) Email replies to Reply messages (2) are sent back to “queue”;
Email replies to Comment messages (3) are sent back to
“queue-comment”.

I’m happy to help implement this is it isn’t already and if everyone
agrees it’s the right solution.

-Marc marc@popularpower.com

     Give your computer something to dream about.    (tm)
	 Popular Power - www.popularpower.com
5

You can only create new tickets by sending mail to a “correspond” alias.

Oh. Whoops. I did modify the code. Just plum forgot about it.

In …/rt/lib/rt/ui/mail/manipulate.pm I made the following changes
the the “if ($in_action eq …” switch that starts around line 33.
All I did was comment out the error message/posting and copy/pasted
the code from the ‘correspond’ case. The original RT code is still
there commented out, so it should be easy to find. This snippet
starts around line 62 in the v1.0.2 code:

elsif ($in_action eq 'comment') { if (!$serial_num) { #COPIED FROM 'correspond' case -- EJG #WE REALLY SHOULD PARSE THE TIME OUT OF THE DATE HEADER...BUT FOR NOW # THE CURRENT TIME IS GOOD ENOUGH 
   ($serial_num,$transaction_num, $message)=&rt::add_new_request(
             $in_queue,$area,
             $current_user,'','',$subject,
             $rt::queues{"$in_queue"}{'default_final_prio'},
             $rt::queues{"$in_queue"}{'default_prio'},'open',
             $rt::time,0,0,$content,$current_user);

#REMOVED FROM ‘comment’ case – EJG

$edited_content = "

#You did not specify a ticket number for these comments. Please resubmit them
#with a ticket number. Your comments appear below.
#$content.
#";

&rt::template_mail(‘error’, ‘_rt_system’, “$current_user”, ‘’, ‘’, “”,

“$transaction_num”, “RT Error: $subject”,

“$current_user”, “$edited_content”);

     exit(0);
     }

</END EXCEPRT>

Sorry about the initial misdirection.

— Eric

6

The hack I sent out just now addresses this problem by making all of
the emails default to comments. For all of my queues the aliases look
like this:

testing: "| /usr/local/rt/bin/rt-mailgate testing comment"
testing-reply: "| /usr/local/rt/bin/rt-mailgate testing correspond"
testing-admin: “| /usr/local/rt/bin/rt-mailgate testing action”

The result is that the requestors can still generate a new request,
but mail sent in response to the new request does not go back to the
requestor. In practice we tell queue members to use the web interface
to correspond, and if they complain I tell them about the special
Correspond and Action addresses, which must be hand entered
(appending -reply or -admin) to work properly.

This works very well for us.

— Eric