Dealing with people who send email to HelpdeskandCCothers

RT Users
1

Jay R. Ashworth wrote:> On Fri, Mar 04, 2005 at 03:59:34PM -0800, Pei Ku wrote:

It’s kinda weird that you have to manage Watcher list via RT Web
interface, the but actual communication amongst the people can be
done either via the web interface or email. It would be nice if I can
do all that via email, but I don’t think it’s possible (without some
heavy hacking made to RT).

I’m not sure I think it is all that weird: if you think of RT as a
‘brilliant’ mailing list manager (which is what you’re sort of using it
as in that environment), then setting up groups through the web sounds
less weird.

I still think there might be a way to have the RT mail intake code to
look for In-Reply-To Message-ID, though.

With a certain amount of code tweaking, it is quite possible.

I run an RT instance which has no direct contact with requestors - instead
the response team are members of a mailing list, and RT listens to the
mailing list traffic, picking up on message ids to assign messages to
tickets.

I wish I could post some code, but it’s all tangled up with other local
modifications, and I’m unlikely to get time to untangle it for at least a
week.

Max.

2

Jay R. Ashworth wrote:

It’s kinda weird that you have to manage Watcher list via RT Web
interface, the but actual communication amongst the people can be
done either via the web interface or email. It would be nice if I can
do all that via email, but I don’t think it’s possible (without some
heavy hacking made to RT).

I’m not sure I think it is all that weird: if you think of RT as a
‘brilliant’ mailing list manager (which is what you’re sort of using it
as in that environment), then setting up groups through the web sounds
less weird.

I still think there might be a way to have the RT mail intake code to
look for In-Reply-To Message-ID, though.

With a certain amount of code tweaking, it is quite possible.

I run an RT instance which has no direct contact with requestors - instead
the response team are members of a mailing list, and RT listens to the
mailing list traffic, picking up on message ids to assign messages to
tickets.

I wish I could post some code, but it’s all tangled up with other local
modifications, and I’m unlikely to get time to untangle it for at least a
week.

That sounds like fun, actually.

Specifically the point I was making was that if RT logged the
Message-ID of messages which start tickets (or, better, all of them)
in a table with the associated ticket number, then it could check the
In-Reply-To ID on new messages, looking for a ticket that the message
could be in reference to, and treat it as being attached to that ticket
even if it can’t find any of it’s other headers.

(I’m working this implementation out as I go along; could you tell? :slight_smile:

I’m tempted to say all MUA’s generate a parseable IRT header these
days; this might be a generally useful extension to the mail interface,
since it makes the system even more proof against failing to notice
that a message is on an already open ticket.

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
3

That sounds like fun, actually.

Specifically the point I was making was that if RT logged the
Message-ID of messages which start tickets (or, better, all of them)
in a table with the associated ticket number, then it could check the
In-Reply-To ID on new messages, looking for a ticket that the message
could be in reference to, and treat it as being attached to that ticket
even if it can’t find any of it’s other headers.

iirc, there’s a patch waiting for application which records message ids
into the attachments table (where there’s already a place for it). Point
me at the patch and I’ll get it into 3.4.2.

(I’m working this implementation out as I go along; could you tell? :slight_smile:

I’m tempted to say all MUA’s generate a parseable IRT header these
days;

Where in 2822 does it say I need to do that? /bin/mail sure doesn’t do
that.

this might be a generally useful extension to the mail interface,
since it makes the system even more proof against failing to notice
that a message is on an already open ticket.

I don’t know about you, but I’ve got a fair number of users who start a
new ticket by replying to an old ticket and changing the subject and
body. If this is really the behaviour you want, you should use the
–extension=ticket functionality in rt-mailgate to get ticket-specific
email addresses.

4

Specifically the point I was making was that if RT logged the
Message-ID of messages which start tickets (or, better, all of them)
in a table with the associated ticket number, then it could check the
In-Reply-To ID on new messages, looking for a ticket that the message
could be in reference to, and treat it as being attached to that ticket
even if it can’t find any of it’s other headers.

iirc, there’s a patch waiting for application which records message ids
into the attachments table (where there’s already a place for it). Point
me at the patch and I’ll get it into 3.4.2.

If I knew where to look. :slight_smile: I’ll check around.

(I’m working this implementation out as I go along; could you tell? :slight_smile:

I’m tempted to say all MUA’s generate a parseable IRT header these
days;

Where in 2822 does it say I need to do that? /bin/mail sure doesn’t do
that.

3.6.4 is as close as you’ll get: it says that Though optional, every
message SHOULD have a “Message-ID:” field. Furthermore, reply messages
SHOULD have “In-Reply-To:” and “References:” fields as appropriate, as
described below.

In practice, /bin/mail may be the only thing left that doesn’t.

I’ll do a little research on this. But given it’s usage, it’s not
required to be globally robust, anyway. If you can use it, you’ll get
it. If you want to be able to use it, you’ll know what you need to
tell people. If you’re corporate, you’ll likely be able to impose the
requirement, if you need to.

this might be a generally useful extension to the mail interface,
since it makes the system even more proof against failing to notice
that a message is on an already open ticket.

I don’t know about you, but I’ve got a fair number of users who start a
new ticket by replying to an old ticket and changing the subject and
body. If this is really the behaviour you want, you should use the
–extension=ticket functionality in rt-mailgate to get ticket-specific
email addresses.

I wasn’t the one who wanted it; I was trying to find a solution for
those people who did. And unless I misunderstand what you say in that
last graf, that won’t help either, because the reply will go to the
same ticket anyway. It’s still a training issue, there, although,
admittedly, “change the addressee” is much easier to teach than “delete
this hidden header”.

Or am I missing something?

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
5

those people who did. And unless I misunderstand what you say in that
last graf, that won’t help either, because the reply will go to the
same ticket anyway. It’s still a training issue, there, although,
admittedly, “change the addressee” is much easier to teach than “delete
this hidden header”.

When you’re sending To: ticket-2345@example.com, it’s obvious that
you’re appending to ticket 2345. Very few MTAs will even let you edit
an in-reply-to header.

6

those people who did. And unless I misunderstand what you say in that
last graf, that won’t help either, because the reply will go to the
same ticket anyway. It’s still a training issue, there, although,
admittedly, “change the addressee” is much easier to teach than “delete
this hidden header”.

When you’re sending To: ticket-2345@example.com, it’s obvious that
you’re appending to ticket 2345. Very few MTAs will even let you edit
an in-reply-to header.

You’re right, of course.

TheBet, for Windows, would let you edit it, if you had configured it to
display, and Mutt, on Linux, will let you ‘E’ the message, and put all
the headers in the editor buffer. But it is uncommon.

I hadn’t realized that there was such a prominent reason why you’d need
to do it, if you did. I suspect there’s still an audience for whom the
features outweigh the bugs, but I don’t know how large that audience is.

If the patch you mentioned goes in easily, then the remining necessary
support might be fairly trivial to add, as well.

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
7

TheBet, for Windows, would let you edit it, if you had configured it to

TheBat?

display, and Mutt, on Linux, will let you ‘E’ the message, and put all
the headers in the editor buffer. But it is uncommon.

I hadn’t realized that there was such a prominent reason why you’d need
to do it, if you did. I suspect there’s still an audience for whom the
features outweigh the bugs, but I don’t know how large that audience is.

If the patch you mentioned goes in easily, then the remining necessary
support might be fairly trivial to add, as well.

Yep. Several folks have posted versions of it over the years.

8

TheBet, for Windows, would let you edit it, if you had configured it to

TheBat?

From ritlabs.com. My recommended mailer if you’re stuck on Windows,
and Thunderbird isn’t powerful enough for you. A bit off-beat (the
author is Eastern Eurpoean), but I haven’t found anything it won’t do,
yet.

display, and Mutt, on Linux, will let you ‘E’ the message, and put all
the headers in the editor buffer. But it is uncommon.

I hadn’t realized that there was such a prominent reason why you’d need
to do it, if you did. I suspect there’s still an audience for whom the
features outweigh the bugs, but I don’t know how large that audience is.

If the patch you mentioned goes in easily, then the remining necessary
support might be fairly trivial to add, as well.

Yep. Several folks have posted versions of it over the years.

There may be a moral there. :slight_smile:

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
9

TheBet, for Windows, would let you edit it, if you had configured it to

TheBat?

From ritlabs.com. My recommended mailer if you’re stuck on Windows,
and Thunderbird isn’t powerful enough for you. A bit off-beat (the
author is Eastern Eurpoean), but I haven’t found anything it won’t do,
yet.

Right. You said “TheBet.”

display, and Mutt, on Linux, will let you ‘E’ the message, and put all
the headers in the editor buffer. But it is uncommon.

I hadn’t realized that there was such a prominent reason why you’d need
to do it, if you did. I suspect there’s still an audience for whom the
features outweigh the bugs, but I don’t know how large that audience is.

If the patch you mentioned goes in easily, then the remining necessary
support might be fairly trivial to add, as well.

Yep. Several folks have posted versions of it over the years.

There may be a moral there. :slight_smile:

Yep. “People keep trying this and hurting themselves badly” :wink: The
message id processing code should be in core. Someone should do the
mailgate hack as something other than a patch. (IE, something using an
extension mechanism)

10

I’m tempted to say all MUA’s generate a parseable IRT header these
days;

Where in 2822 does it say I need to do that? /bin/mail sure doesn’t do
that.

I suspect you could count the people using /bin/mail as their favorite
MUA on your toes.

I don’t know about you, but I’ve got a fair number of users who start a
new ticket by replying to an old ticket and changing the subject and
body. If this is really the behaviour you want, you should use the
–extension=ticket functionality in rt-mailgate to get ticket-specific
email addresses.

I fairly often get tickets CC:'d to my own address and reply to my
copy before noticing that an alias pointing to RT is also included in
the addresses. This, of course makes an unrelated ticket that is
hard to match up with the one made by the original email. When I
do this myself it is hard to complain about others doing it…

Perhaps for messages missing the ticket number in the subject line
you could check for a match on IRT with a known msg-id but only
merge it if the subject line still matches minus a leading RE:.

That should cover desired behavior either way.

Les Mikesell
les@futuresource.com

11

I’m tempted to say all MUA’s generate a parseable IRT header these
days;

Where in 2822 does it say I need to do that? /bin/mail sure doesn’t do
that.

I suspect you could count the people using /bin/mail as their favorite
MUA on your toes.

Aw, c’mon; I’m sure dmr loves it. :slight_smile:

I don’t know about you, but I’ve got a fair number of users who start a
new ticket by replying to an old ticket and changing the subject and
body. If this is really the behaviour you want, you should use the
–extension=ticket functionality in rt-mailgate to get ticket-specific
email addresses.

I fairly often get tickets CC:'d to my own address and reply to my
copy before noticing that an alias pointing to RT is also included in
the addresses. This, of course makes an unrelated ticket that is
hard to match up with the one made by the original email. When I
do this myself it is hard to complain about others doing it…

Perhaps for messages missing the ticket number in the subject line
you could check for a match on IRT with a known msg-id but only
merge it if the subject line still matches minus a leading RE:.

That should cover desired behavior either way.

Sounds like maybe. I wonder how much extension it would take to get
there. (Everybody remember now: this wasn’t my windmill; I’m merely
kibitzing, because I’m a better designer than coder.)

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