Dealing with people who send email to Helpdesk and CC others

What’s the best way to avoid this scenario:

  1. Jeff sends a note with subject “Machine Broken” to Helpdesk and CC’s
    Barrett, Tony and John.
  2. Helpdesk opens a ticket titled “Machine Broken” with Requestors
    Jeff, Barrett, Tony, John and sends a receipt to Jeff with subject
    “[Helpdesk #2008] Helpdesk Update: Machine Broken” to note that it has
    received your request.
  3. Barrett does Reply All to Jeff’s note “Machine Broken”. When he
    does this, his “Re: Machine Broken” reply will go to Jeff, Tony, John
    and Helpdesk.
  4. This opens another ticket in the Helpdesk titled “Re: Machine
    Broken” and Barrett will receive a receipt from Helpdesk with Subject
    “[Helpdesk #2008] Helpdesk Update: Re: Machine Broken”.
  5. Tony then replies to Jeff’s note. Yet another ticket is created.
    Etc…

Right now I enable $ParseNewMessageForTicketCcs but I’m not sure that
setting comes into play here. The real issue is that people are used to
doing Reply All, and don’t bother to see if Helpdesk is one of the
people they are replying to.

I can’t figure out a graceful way to handle it. I want to be including
all of those others on the ticket, but I don’t want their replies to be
opening new tickets. Even if I don’t ParseNewMessageForTicketCcs,
they’ll still open duplicate tickets when they do Reply All. Is there
anything to be done here?

Thanks,
Fran

Fran Fabrizio
Senior Systems Analyst
Department of Computer and Information Sciences
University of Alabama at Birmingham

205.934.0653

If $ParseNewMessageForTicketCcs is true, RT will attempt to divine

Ticket ‘Cc’ watchers from the To and Cc lines of incoming messages

Be forewarned that if you have any addresses which forward mail to

RT automatically and you enable this option without modifying

“RTAddressRegexp” below, you will get yourself into a heap of trouble.

Set($ParseNewMessageForTicketCcs , undef);

RTAddressRegexp is used to make sure RT doesn’t add itself as a ticket

CC if

the setting above is enabled.

Fran Fabrizio wrote:

Disregard that. I mis-read your original message.

I’m not sure of a good way to handle this, except to start training them
to notice who they are emailing.

Drew Barnes wrote:

Yes, thanks. :slight_smile: I read that… right before I intentionally changed
the setting to 1, as I mentioned. :slight_smile: This isn’t the issue I’m
facing. I tried to point that out but apparently not very well.

User1 sends an email to user2, user3, and helpdesk.
User2 "reply all"s to user1’s email, sending an email to user1, user3,
helpdesk.
Two tickets have just been created.

Turning off the ParseNewMessageForTicketCcs won’t help at all here.

Besides user training to scan the email recipients and realize the
ramifications of having helpdesk in the recip list, is there anything
that RT can do to prevent this? Such as figuring out that “Re: Foobar”
as a subject line might be related to the “Foobar” subject line that it
just turned into a ticket earlier that day?

Maybe I should just have procmail drop anything headed to RT that has
Re: in it without an RT tag. Seems kludgy though and will definitely
kill some legitimate attempts to make a ticket.

-Fran

Drew Barnes wrote:

If $ParseNewMessageForTicketCcs is true, RT will attempt to divine

Ticket ‘Cc’ watchers from the To and Cc lines of incoming messages

Be forewarned that if you have any addresses which forward mail to

RT automatically and you enable this option without modifying

“RTAddressRegexp” below, you will get yourself into a heap of trouble.

Set($ParseNewMessageForTicketCcs , undef);

RTAddressRegexp is used to make sure RT doesn’t add itself as a

ticket CC if

the setting above is enabled.

Fran Fabrizio wrote:

What’s the best way to avoid this scenario:

  1. Jeff sends a note with subject “Machine Broken” to Helpdesk and
    CC’s Barrett, Tony and John.
  2. Helpdesk opens a ticket titled “Machine Broken” with Requestors
    Jeff, Barrett, Tony, John and sends a receipt to Jeff with subject
    “[Helpdesk #2008] Helpdesk Update: Machine Broken” to note that it
    has received your request.
  3. Barrett does Reply All to Jeff’s note “Machine Broken”. When he
    does this, his “Re: Machine Broken” reply will go to Jeff, Tony, John
    and Helpdesk.
  4. This opens another ticket in the Helpdesk titled “Re: Machine
    Broken” and Barrett will receive a receipt from Helpdesk with Subject
    “[Helpdesk #2008] Helpdesk Update: Re: Machine Broken”.
  5. Tony then replies to Jeff’s note. Yet another ticket is
    created. Etc…

Right now I enable $ParseNewMessageForTicketCcs but I’m not sure that
setting comes into play here. The real issue is that people are used
to doing Reply All, and don’t bother to see if Helpdesk is one of the
people they are replying to.
I can’t figure out a graceful way to handle it. I want to be
including all of those others on the ticket, but I don’t want their
replies to be opening new tickets. Even if I don’t
ParseNewMessageForTicketCcs, they’ll still open duplicate tickets
when they do Reply All. Is there anything to be done here?

Thanks,
Fran

Fran Fabrizio
Senior Systems Analyst
Department of Computer and Information Sciences
University of Alabama at Birmingham

205.934.0653

Maybe I should just have procmail drop anything headed to RT that has
Re: in it without an RT tag. Seems kludgy though and will definitely
kill some legitimate attempts to make a ticket.

I’ve been wondering how it could be happening the way you describe,
because it shouldn’t be opening a new ticket. I think the paragraph above
might answer my question. You’re saying that when people do a “reply
all”, the subject does not contain the tag for the ticket?

Russell Mosemann, Ph.D. * Computing Services * Concordia University, Nebraska
“You are displaying an early cephalo-caudal developmental pattern.”

  • the politically correct expression for “butthead”

Speaking with out mail administrator, I believe we are putting mail that
is directed to our rt address and has Re: in the subject in a hold
queue. He goes over the hold queue a few times a day and can manually
release the messages which may be necessary.

He is doing that in Postfix. Can you do something similar in procmail?

DB

Fran Fabrizio wrote:

User1 sends an email to user2, user3, and helpdesk.
User2 "reply all"s to user1’s email, sending an email to user1, user3,
helpdesk.
Two tickets have just been created.

Right. Here, RT will send the auto-reply to all the users.
So User2 now has the original note from user1, as well
as RT’s “Thanks for the ticket, here’s how to deal with it.”

Since RT is fast, probably User2 has both notes pretty much
simulateously. Obviously he should reply to the second
only. Sometimes mistakes happen, but in practice here,
it hasn’t been too bad. If user2 reads both before replying
to either, you have a fighting chance.

We have had it happen a few times, where user3 was
actually a separate, non-RT helpdesk! Dueling helpdesks
can create quite a few new tickets before I was able
to hit the STOP button :slight_smile:

  bobg

Russell Mosemann wrote:

Maybe I should just have procmail drop anything headed to RT that has
Re: in it without an RT tag. Seems kludgy though and will definitely
kill some legitimate attempts to make a ticket.

I’ve been wondering how it could be happening the way you describe,
because it shouldn’t be opening a new ticket. I think the paragraph above
might answer my question. You’re saying that when people do a “reply
all”, the subject does not contain the tag for the ticket?

No, because they are replying to a message that they receive from
joe@user.com.

Think of it this way… if you send an email to joe@user.com and
rt@user.com, joe is going to get a message that is from you@user.com.
If he Reply All’s that one, he will be sending it to you@user.com and
rt@user.com. But he’s not replying to an RT mail, he’s replying to your
mail, which never went through RT and thus does not have the RT tag on
the subject. So RT sees his reply as a completely new request.


Russell Mosemann, Ph.D. * Computing Services * Concordia University, Nebraska
“You are displaying an early cephalo-caudal developmental pattern.”

  • the politically correct expression for “butthead”

Fran Fabrizio
Senior Systems Analyst
Department of Computer and Information Sciences
University of Alabama at Birmingham

205.934.0653

I’m curious what you are using as your “STOP” button. We are currently
migrating from a home-grown system to RT. Our old system had deny and
silent lists which tell it to either completely disregard mail from an
address on the deny list, or to never auto-reply to an address on the
silent list. It also has the feature of introducing a 5-minute delay
into replies going to addresses outside our domain, which has saved our
bacon a few times and kept the database from exploding if there was a
loop with an outside 'bot that went unnoticed for a while.

I’m hoping to duplicate some or all of that functionality in RT. Deny
is pretty easy by just toggling the bit that allows an address/user to
use RT. For the other two we are debating on whether they should live
in RT scrips processing incoming mail, in a wrapper script for
rt-mailgate, or whether they can be implemented in some other clever
way.

How does everyone else do it?

Thanks,

OliverOn 4 Mar 2005, at 12:41 PM, Bob Goldstein wrote:

We have had it happen a few times, where user3 was
actually a separate, non-RT helpdesk! Dueling helpdesks
can create quite a few new tickets before I was able
to hit the STOP button :slight_smile:

Drew Barnes wrote:

Speaking with out mail administrator, I believe we are putting mail
that is directed to our rt address and has Re: in the subject in a
hold queue. He goes over the hold queue a few times a day and can
manually release the messages which may be necessary.

I’m also using Postfix so I could do it at that level. Could probably
manage something in procmail, but Postfix may be the more natural place
to do it. I’ll have to think about it some more, but that’s one
possible solution. I was hoping for something that didn’t require me to
remember to go review a queue :slight_smile: I wonder how feasible it is to have
RT look at all new requests and look for Re: in the subject, strip that,
and see if what’s left matches the subject of any of the tickets
currently in open or new status.

Fran Fabrizio
Senior Systems Analyst
Department of Computer and Information Sciences
University of Alabama at Birmingham

205.934.0653

Right. Here, RT will send the auto-reply to all the users.
So User2 now has the original note from user1, as well
as RT’s “Thanks for the ticket, here’s how to deal with it.”

Ah, that would help! I could add the rule to also include the CCs on
the reply…

That would lead to another issue - the “why am I getting a receipt from
the Helpdesk when I never sent them a request???” issue. I guess
eventually they’ll be trained to look and see what the issue subject is,
and map back to that other email they just received with that same
subject, and put it all together…

Since RT is fast, probably User2 has both notes pretty much
simulateously. Obviously he should reply to the second
only.

Eh…if they are a “sequential email processor”, they read, reply if
necessary, go to the next, read, reply if necessary… and although RT
is fast, it’s still slower than just emailing them directly, so that RT
email is going to arrive a few seconds later, and thus be later in the
queue. But, to be fair, I haven’t tested my theory to know if that’s
what the behavior would really be most of the time…

We have had it happen a few times, where user3 was
actually a separate, non-RT helpdesk! Dueling helpdesks

Yep, I’ve been there before, too. :slight_smile:

Fran Fabrizio
Senior Systems Analyst
Department of Computer and Information Sciences
University of Alabama at Birmingham

205.934.0653

Yes, thanks. :slight_smile: I read that… right before I intentionally changed
the setting to 1, as I mentioned. :slight_smile: This isn’t the issue I’m
facing. I tried to point that out but apparently not very well.

User1 sends an email to user2, user3, and helpdesk.
User2 "reply all"s to user1’s email, sending an email to user1, user3,
helpdesk.
Two tickets have just been created.

Turning off the ParseNewMessageForTicketCcs won’t help at all here.

Besides user training to scan the email recipients and realize the
ramifications of having helpdesk in the recip list, is there anything
that RT can do to prevent this? Such as figuring out that “Re: Foobar”
as a subject line might be related to the “Foobar” subject line that it
just turned into a ticket earlier that day?

I’m new to RT, so perhaps I’m missing something, but doesn’t the fact
that the message is identifiably for an already open ticket keep RT
from opening a new one? The Re: shouldn’t be throwing it; if that’s
really what’s happening, I would define it as a bug, unless someone
convinced me there was a good reason for it.

Cause you’re right, it’s not an uncommon scenario, IMHO, and there’s
not other good way to handle it.

Cheers,
– jra
Jay R. Ashworth jra@baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274

  If you can read this... thank a system adminstrator.  Or two.  --me

Yes, thanks. :slight_smile: I read that… right before I intentionally changed
the setting to 1, as I mentioned. :slight_smile: This isn’t the issue I’m
facing. I tried to point that out but apparently not very well.

User1 sends an email to user2, user3, and helpdesk.
User2 "reply all"s to user1’s email, sending an email to user1, user3,
helpdesk.
Two tickets have just been created.

Turning off the ParseNewMessageForTicketCcs won’t help at all here.

Besides user training to scan the email recipients and realize the
ramifications of having helpdesk in the recip list, is there anything
that RT can do to prevent this? Such as figuring out that “Re: Foobar”
as a subject line might be related to the “Foobar” subject line that it
just turned into a ticket earlier that day?

I’m new to RT, so perhaps I’m missing something, but doesn’t the fact
that the message is identifiably for an already open ticket keep RT
from opening a new one? The Re: shouldn’t be throwing it; if that’s
really what’s happening, I would define it as a bug, unless someone
convinced me there was a good reason for it.

“I will read the entire thread before posting comments.”
“I will read the entire thread before posting comments.”
“I will read the entire thread before posting comments.”
“I will read the entire thread before posting comments.”

:slight_smile:

It’s especially amusing since that exact issue is on topic for the
thread.

Cheers,
– jra
Jay R. Ashworth jra@baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274

  If you can read this... thank a system adminstrator.  Or two.  --me

but doesn’t the fact
that the message is identifiably for an already open ticket keep RT
from opening a new one?

The problem is that it is not identifiably open.

If Joe sends a message to Bob and to Helpdesk, Bob will actually get 2
messages. Bob will see Joe’s message, and Bob will get a message from
Helpdesk with the ticket number in the subject.

If Bob reads Joe’s message and does a reply all, then Bob’s message will
go to Joe and to the Helpdesk. Since this is not the message with the
ticket number in it, it appears to be a new message.

If Joe and Bob keeping replying to each other’s messages (instead of
Helpdesk messages) and including the Helpdesk, a lot of new tickets will
be created. It’s good there is a feature to merge tickets. :slight_smile:

Russell Mosemann, Ph.D. * Computing Services * Concordia University, Nebraska
“Such a process is cognitively effortful.” - Rachel K. E. Bellamy

I’ve got procmail running in front of rt-mailgate.
So I just put in a rule to drop anything from this
other helpdesk system. (With the exception of one
special address, which was set up expressly to allow
transfer of tickets between helpdesks.)

  bobg

but doesn’t the fact
that the message is identifiably for an already open ticket keep RT
from opening a new one?

The problem is that it is not identifiably open.

If Joe sends a message to Bob and to Helpdesk, Bob will actually get 2
messages. Bob will see Joe’s message, and Bob will get a message from
Helpdesk with the ticket number in the subject.

If Bob reads Joe’s message and does a reply all, then Bob’s message will
go to Joe and to the Helpdesk. Since this is not the message with the
ticket number in it, it appears to be a new message.

If Joe and Bob keeping replying to each other’s messages (instead of
Helpdesk messages) and including the Helpdesk, a lot of new tickets will
be created. It’s good there is a feature to merge tickets. :slight_smile:

Yeah; I’m on it now. Doesn’t Bob’s reply have an “In-Reply-To” header
with the Message-ID of the original message? Does RT currently cache
the Message ID of the opening message with each ticket? Cause that
might solve many of these…

Cheers,
– jra
Jay R. Ashworth jra@baylink.com
Designer Baylink RFC 2100
Ashworth & Associates The Things I Think '87 e24
St Petersburg FL USA http://baylink.pitas.com +1 727 647 1274

  If you can read this... thank a system adminstrator.  Or two.  --me

I’m curious what you are using as your “STOP” button. We are currently
migrating from a home-grown system to RT. Our old system had deny and
silent lists which tell it to either completely disregard mail from an
address on the deny list, or to never auto-reply to an address on the
silent list. It also has the feature of introducing a 5-minute delay
into replies going to addresses outside our domain, which has saved our
bacon a few times and kept the database from exploding if there was a
loop with an outside 'bot that went unnoticed for a while.

I’m hoping to duplicate some or all of that functionality in RT. Deny
is pretty easy by just toggling the bit that allows an address/user to
use RT. For the other two we are debating on whether they should live
in RT scrips processing incoming mail, in a wrapper script for
rt-mailgate, or whether they can be implemented in some other clever
way.

How does everyone else do it?

Thanks,

Oliver

It would be easy to extend RT to NOT create tickets when the
subject begins with “Re:”

-Todd