Making RT invisible - changing subject lines

I’m trying to ease some of our support aliases (and the people who read
them) into RT before it puts it’s ticket number stamp onto the subject
line of our correspondence (I realize these #'s are useful, but want to
turn it off until I get people used to using RT)

I’d like RT to be working (accepting mail, allowing status updates,
allow us to respond from the web interface).

  1. So I deleted Autoreply to new messages globaly
    (configuration->global->scrips “OnCreate AutoreplyToRequestors with
    template Autoreply”). For the queue that I wanted to keep Autoreply - I
    added that scrip (Queues -> select queue -> scrips -> add scrip etc…)

  2. Now when I respond from the web interface if a user email subject
    line says: “help with netscape” and we respond from the web interface I
    want the subject line to say “RE: help with netscape” instead of this
    subject line “[EECS Helpdesk #40] help with netscape”

Any tips on how to do that would be appreciated. Thanks.

Mike Patterson - UC Berkeley
Computer User Support Group
EECS Computing Helpdesk Manager

  1. Now when I respond from the web interface if a user email subject
    line says: “help with netscape” and we respond from the web interface I
    want the subject line to say “RE: help with netscape” instead of this
    subject line “[EECS Helpdesk #40] help with netscape”

Any tips on how to do that would be appreciated. Thanks.

If you do that, RT is going to create a new ticket for every message
it gets, even when they’re a reply to one of your support techs’
replies. Are you sure that’s what you want?

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | http://zapatopi.net/treeoctopus.html
rich@lafferty.ca -----------±----------------------------------------------

  1. Now when I respond from the web interface if a user email subject
    line says: “help with netscape” and we respond from the web interface I
    want the subject line to say “RE: help with netscape” instead of this
    subject line “[EECS Helpdesk #40] help with netscape”

Any tips on how to do that would be appreciated. Thanks.

If you do that, RT is going to create a new ticket for every message
it gets, even when they’re a reply to one of your support techs’
replies. Are you sure that’s what you want?

Hmm… I dunno… might be nifty to have the ticket # in an X-Header… like
X-RT-Ticket: or something along those lines… :slight_smile:

Just a thought,
G.

Glenn E. Sieb
System Administrator
Lumeta Corporation
+1 732 357-3514 (V)
+1 732 564-0731 (Fax)

  1. Now when I respond from the web interface if a user email subject
    line says: “help with netscape” and we respond from the web interface I
    want the subject line to say “RE: help with netscape” instead of this
    subject line “[EECS Helpdesk #40] help with netscape”

If you do that, RT is going to create a new ticket for every message
it gets, even when they’re a reply to one of your support techs’
replies. Are you sure that’s what you want?

Hmm… I dunno… might be nifty to have the ticket # in an X-Header… like
X-RT-Ticket: or something along those lines… :slight_smile:

No, the ticket number has to come back from the user. RT can’t set
custom headers in some guy’s Outlook.

You could put it in the email address – and rt-mailgate already
accepts that with some MTAs with --ticket-id-from-extension – but I
still suspect that the original poster hadn’t thought through his
request.

-Rich

Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | http://zapatopi.net/treeoctopus.html
rich@lafferty.ca -----------±----------------------------------------------

No, the ticket number has to come back from the user. RT can’t set
custom headers in some guy’s Outlook.

Ah… good pernt. :-/

G.

Glenn E. Sieb
System Administrator
Lumeta Corporation
+1 732 357-3514 (V)
+1 732 564-0731 (Fax)

Thanks for the ideas.

At this point, as I’m easing our group into the system I willing to live
with a users reply to a techs comments create a new queue (yes I thought
about that). Even with that limitation RT has a lot of great features
(e.g. central repository of information) that are worthwhile to start
using now. Once people start to see the beauty of RT and use it
regularly (and I resolve another database numbering scheme), they’ll be
ready use the full set of features.

But I’m unclear on how replies sent from the web interface get inserted
into the database. Does it simply do an insert or does it actually
email itself and make rt-mailgate insert it? As far as tech replies
original ticket. If it mails itself for an insert I can see that I need
the ticket number included in the email (at least for the
self-referential copy of the email).

My MTA is a fairly recent build of sendmail on FreeBSD and anyone can
suggest tricks to get it to insert itself (without modifying the
subject line to the user) would be greatly appreciated.

Thanks,
Mike

Message: 11Date: Thu, 31 Oct 2002 09:42:42 -0800
From: Mike Patterson map@eecs.berkeley.edu
To: rt-users@lists.fsck.com
Subject: [rt-users] Making RT invisible - changing subject lines

I’m trying to ease some of our support aliases (and the people who read
them) into RT before it puts it’s ticket number stamp onto the subject
line of our correspondence (I realize these #'s are useful, but want to
turn it off until I get people used to using RT)

I’d like RT to be working (accepting mail, allowing status updates,
allow us to respond from the web interface).

  1. So I deleted Autoreply to new messages globaly
    (configuration->global->scrips “OnCreate AutoreplyToRequestors with
    template Autoreply”). For the queue that I wanted to keep Autoreply - I
    added that scrip (Queues -> select queue -> scrips -> add scrip etc…)

  2. Now when I respond from the web interface if a user email subject
    line says: “help with netscape” and we respond from the web interface I
    want the subject line to say “RE: help with netscape” instead of this
    subject line “[EECS Helpdesk #40] help with netscape”

Any tips on how to do that would be appreciated. Thanks.

Mike Patterson - UC Berkeley
Computer User Support Group
EECS Computing Helpdesk Manager

Message: 12
Date: Thu, 31 Oct 2002 13:17:44 -0500
From: Rich Lafferty rich+rt@lafferty.ca
To: RT Users mailing list rt-users@lists.fsck.com
Subject: Re: [rt-users] Making RT invisible - changing subject lines

  1. Now when I respond from the web interface if a user email subject
    line says: “help with netscape” and we respond from the web interface I
    want the subject line to say “RE: help with netscape” instead of this
    subject line “[EECS Helpdesk #40] help with netscape”

Any tips on how to do that would be appreciated. Thanks.

If you do that, RT is going to create a new ticket for every message
it gets, even when they’re a reply to one of your support techs’
replies. Are you sure that’s what you want?

-Rich

– Rich Lafferty
--------------±---------------------------------------------- Ottawa,
Ontario, Canada | Save the Pacific Northwest Tree Octopus!
http://www.lafferty.ca/ | http://zapatopi.net/treeoctopus.html
rich@lafferty.ca
-----------±---------------------------------------------- –
Message: 13 Date: Thu, 31 Oct 2002 13:53:11 -0500 To: RT-Users
rt-users@lists.fsck.com From: Glenn Sieb ges@lumeta.com Subject: Re:
[rt-users] Making RT invisible - changing subject lines On 01:17 PM
10/31/2002 -0500, Rich Lafferty wrote:

  1. Now when I respond from the web interface if a user email subject
    line says: “help with netscape” and we respond from the web interface I
    want the subject line to say “RE: help with netscape” instead of this
    subject line “[EECS Helpdesk #40] help with netscape”

Any tips on how to do that would be appreciated. Thanks.

If you do that, RT is going to create a new ticket for every message
it gets, even when they’re a reply to one of your support techs’
replies. Are you sure that’s what you want?

Hmm… I dunno… might be nifty to have the ticket # in an X-Header… like
X-RT-Ticket: or something along those lines… :slight_smile:

Just a thought,
G.

Glenn E. Sieb
System Administrator
Lumeta Corporation
+1 732 357-3514 (V)
+1 732 564-0731 (Fax)

Message: 14
Date: Thu, 31 Oct 2002 14:10:09 -0500
From: Rich Lafferty rich+rt@lafferty.ca
To: RT Users mailing list rt-users@lists.fsck.com
Subject: Re: [rt-users] Making RT invisible - changing subject lines

  1. Now when I respond from the web interface if a user email subject
    line says: “help with netscape” and we respond from the web
    interface I

want the subject line to say “RE: help with netscape” instead of this
subject line “[EECS Helpdesk #40] help with netscape”

If you do that, RT is going to create a new ticket for every message
it gets, even when they’re a reply to one of your support techs’
replies. Are you sure that’s what you want?

Hmm… I dunno… might be nifty to have the ticket # in an X-Header…
like
X-RT-Ticket: or something along those lines… :slight_smile:

No, the ticket number has to come back from the user. RT can’t set
custom headers in some guy’s Outlook.

You could put it in the email address – and rt-mailgate already
accepts that with some MTAs with --ticket-id-from-extension – but I
still suspect that the original poster hadn’t thought through his
request.

-Rich

If the subject line is that offensive, I’d suggest changing the order of the subject line, so instead of

[RT tag] subject

you have

subject [RT tag]

and then that’s nicer to read.

-Sheeri Kritzer
Systems Administrator
University Systems Group
Tufts University
617-627-3925
sheeri.kritzer@tufts.edu

Quoting Rich Lafferty rich+rt@lafferty.ca:> On Thu, Oct 31, 2002 at 01:53:11PM -0500, Glenn Sieb ges@lumeta.com wrote:

On 01:17 PM 10/31/2002 -0500, Rich Lafferty wrote:

  1. Now when I respond from the web interface if a user email subject
    line says: “help with netscape” and we respond from the web interface
    I

want the subject line to say “RE: help with netscape” instead of this
subject line “[EECS Helpdesk #40] help with netscape”

Mike Patterson map@eecs.berkeley.edu writes:

But I’m unclear on how replies sent from the web interface get inserted
into the database. Does it simply do an insert or does it actually
email itself and make rt-mailgate insert it? As far as tech replies
sent from the web interface, I definately want them connected to the
original ticket. If it mails itself for an insert I can see that I need
the ticket number included in the email (at least for the
self-referential copy of the email).

My MTA is a fairly recent build of sendmail on FreeBSD and anyone can
suggest tricks to get it to insert itself (without modifying the
subject line to the user) would be greatly appreciated.

My guess is that rt-mailgate could be beefed up to look at
the ‘In-Reply-To’ (and maybe Message-ID) headers when it can’t
parse the ticket id off the subject line. Most decent
MUAs should preserve enough info to work

For example
In-Reply-To: rt-60@ICS
Message-ID: rt-60-233.8.7083512469593@ics.com

Either of these patterns pretty clearly matches ticket 60.

I tried out the basic concept and it seems to work.
Certainly, enhancing rt-mailgate should be mostly harmless.

[The info below is NOT valid patch format. Do the work by hand]

First, patch lib/RT/Interfaces/Email.pm

*** orig/Email.pm Fri May 3 01:30:23 2002
— ./Email.pm Thu Oct 31 15:25:05 2002
*** 28,33 ****
— 28,34 ----
&CheckForAutoGenerated
&ParseMIMEEntityFromSTDIN
&ParseTicketId

  •                 &ParseInReplyTo 
                    &MailError 
                    &ParseCcAddressesFromHead
                    &ParseSenderAddressFromHead 
    

*** 281,286 ****
— 283,305 ----
else {
return(undef);
}
}

}}}

  • {{{ sub ParseInReplyTo

  • sub ParseInReplyTo {
  • my $InReplyTo = shift;
    
  • my ($Id);
    
  • if ($InReplyTo =~ s/<support-(\d+)[-@]//i) {
    
  •   $Id = $1;
    
  •   $RT::Logger->debug("Found a ticket ID. It's $Id");
    
  •   return($Id);
    
  • }
    
  • else {
    
  •   return(undef);
    
  • }
    
  • }
  • }}}

Next patch rt-mailgate

*** rt-mailgate 2002/10/31 20:16:42 1.1
— rt-mailgate 2002/10/31 20:18:28
*** 24,27 ****
— 24,28 ----
ParseMIMEEntityFromSTDIN
ParseTicketId

  •                        ParseInReplyTo
                           MailError 
                           ParseCcAddressesFromHead
    

*** 116,119 ****
— 117,121 ----
my $MessageId = $head->get(‘Message-Id’) ||
"<no-message-id-".time.rand(2000)."@.$RT::Organization>";

  • my $InReplyTo = $head->get(‘In-Reply-To’);

    #Pull apart the subject line
    *** 123,126 ****
    — 125,129 ----

    Get the ticket ID unless it’s already set

    $TicketId = ParseTicketId($Subject) unless ($TicketId);

  • $TicketId = ParseInReplyTo($InReplyTo) unless ($TicketId);

    #Set up a queue object

Now, of course, you have to whack at SendEmail.pm so it leaves
off the [$RT::Organization #]. I don’t have the guts
to try this part out yet. I’m certainly not going to be the
one to try it on my production system. :slight_smile:

There could be many problems. For example, a customer
who never actually creates a new message when submitting a
ticket, but rather replies to an old, dead ticket and replaces
the subject. That works in RT as designed, but would break
with the In-Reply-To parsing.

What does Jesse think?

-Tony Aiuto

Thanks for the suggestion.

In my case I want replies and comments from the web interface to update
the ticket and I’m willing to live with additional user replies to the
tech opening a new ticket.

I think this might work, but I need a better understanding of how
replies and comments go in. Do replies and comments from the web
interface use the “comment” action as opposed to correspond action? If
so I can copy and modify rt-mailgate and rename it
"rt-mailgate-InReplyTo" which uses Tony’s “ParseInReplyTo” functions for
rt-comment.

rt-comment: "|/opt/rt2/bin/rt-mailgate-InReplyTo --queue general
–action comment"
rt: “|/opt/rt2/bin/rt-mailgate --queue general --action correspond”

With this kind of setup I don’t have to worry about some of the
potential bugs: e.g. users trying to create a new ticket by replying to
an old email with new subject line updating a dead ticket instead of
creating a new one.

Does it work that way? If not, how can I make replies and comments from
web interface use a different alias?

Thanks,
Mike

Tony Aiuto wrote:

Mike Patterson map@eecs.berkeley.edu writes:

But I’m unclear on how replies sent from the web interface get inserted
into the database. Does it simply do an insert or does it actually
email itself and make rt-mailgate insert it? As far as tech replies
sent from the web interface, I definately want them connected to the
original ticket. If it mails itself for an insert I can see that I need
the ticket number included in the email (at least for the
self-referential copy of the email).

My MTA is a fairly recent build of sendmail on FreeBSD and anyone can
suggest tricks to get it to insert itself (without modifying the
subject line to the user) would be greatly appreciated.

My guess is that rt-mailgate could be beefed up to look at
the ‘In-Reply-To’ (and maybe Message-ID) headers when it can’t
parse the ticket id off the subject line. Most decent
MUAs should preserve enough info to work

For example
In-Reply-To: rt-60@ICS
Message-ID: rt-60-233.8.7083512469593@ics.com

Either of these patterns pretty clearly matches ticket 60.

I tried out the basic concept and it seems to work.
Certainly, enhancing rt-mailgate should be mostly harmless.

[The info below is NOT valid patch format. Do the work by hand]

First, patch lib/RT/Interfaces/Email.pm

*** orig/Email.pm Fri May 3 01:30:23 2002
— ./Email.pm Thu Oct 31 15:25:05 2002


*** 28,33 ****
— 28,34 ----
&CheckForAutoGenerated
&ParseMIMEEntityFromSTDIN
&ParseTicketId

  •                 &ParseInReplyTo 
                    &MailError 
                    &ParseCcAddressesFromHead
                    &ParseSenderAddressFromHead 
    

*** 281,286 ****
— 283,305 ----
else {
return(undef);
}
}

}}}

  • {{{ sub ParseInReplyTo

  • sub ParseInReplyTo {
  • my $InReplyTo = shift;
    
  • my ($Id);
    
  • if ($InReplyTo =~ s/<support-(\d+)[-@]//i) {
    
  •   $Id = $1;
    
  •   $RT::Logger->debug("Found a ticket ID. It's $Id");
    
  •   return($Id);
    
  • }
    
  • else {
    
  •   return(undef);
    
  • }
    
  • }
  • }}}

Next patch rt-mailgate

*** rt-mailgate 2002/10/31 20:16:42 1.1
— rt-mailgate 2002/10/31 20:18:28


*** 24,27 ****
— 24,28 ----
ParseMIMEEntityFromSTDIN
ParseTicketId

  •                        ParseInReplyTo
                           MailError 
                           ParseCcAddressesFromHead
    

*** 116,119 ****
— 117,121 ----
my $MessageId = $head->get(‘Message-Id’) ||
"<no-message-id-".time.rand(2000)."@.$RT::Organization>";

  • my $InReplyTo = $head->get(‘In-Reply-To’);

    #Pull apart the subject line


*** 123,126 ****
— 125,129 ----

Get the ticket ID unless it’s already set

$TicketId = ParseTicketId($Subject) unless ($TicketId);

  • $TicketId = ParseInReplyTo($InReplyTo) unless ($TicketId);

    #Set up a queue object

Now, of course, you have to whack at SendEmail.pm so it leaves
off the [$RT::Organization #]. I don’t have the guts
to try this part out yet. I’m certainly not going to be the
one to try it on my production system. :slight_smile:

There could be many problems. For example, a customer
who never actually creates a new message when submitting a
ticket, but rather replies to an old, dead ticket and replaces
the subject. That works in RT as designed, but would break
with the In-Reply-To parsing.

What does Jesse think?

-Tony Aiuto

Mike Patterson - UC Berkeley
Computer User Support Group
EECS Computing Helpdesk Manager

At this point, as I’m easing our group into the system I willing to live
with a users reply to a techs comments create a new queue (yes I thought

A lot of the time the contributing inhabitants of the rt-users list are
able to work out what questions people are asking by utilising a mixture
method of personal experience, memory recall and in some cases,
non-intrusive telepathy.

However, all of this assumes that the question has been phrased in a
manner conductive to the above methods. So, usage of appropriate
terminology is very much appreciated, as people generally don’t like
having to ask what seems like basic questions in order to assist others.
Plus using intrusive telepathy on people I don’t know gives me a splitting
headache.

So far in your thread, you’ve asked the following paraphrased questions:

Where can I find out about the terminology of RT, so I don't
confuse 'ticket' with 'queue', or a 'User' with a 'Scrip', or
something else?

	http://www.fsck.com/rtfm/

Can emails from my tech guys to the ticket requestors be sent
without the [$rtname #$ticket_number] tags?

	Yes, they can.  The code which sends outgoing email and
	edits the subject can be found in
	[rtlibdir]/RT/Action/SendEmail.pm .  Changing this
	behaviour should be easy, although not recommended,
	assuming a basic knowledge of perl.

How does RT communicate updates from my tech guys using the web
interface?

	The Web interface communicates directly with the database
	(well, the RT server does, not the tech-guys web
	browsers).  Email is sent according to the Scrips defined,
	and is not an essential part of RT's operation.

What are updates from the web considered as?  Comments or
Correspondence?

	RT defines Comments as 'text entered by your tech guys
	which assists other techs in understanding the problem or
	the customer'.  Comments should never be sent to the
	customer.  Correspondence is defined as being 'text
	entered by either your tech guys or your customer which is
	sent to all parties involved'.  Correspondence gets sent
	to your customers.

	Your tech guys can enter either type of update from the
	Web interface.

Can I ask questions in a manner which doesn't make people wonder
what I'm on?

	Certainly.  Most of a usable Users Guide, and RT
	Administrators guide exist within RT/FM:

		http://www.fsck.com/rtfm/

	The rt-users community is more of for questions that are
	not immediately answered by RT/FM (above).  Asking
	questions which are interesting and are not in RT/FM
	serves to keep people's interest in rt-users alive, as we
	all like an intellectual challenge every now and then.

	Another thing that we deeply appreciate is appropriate
	quoting of your mails.  When replying to mails, try to
	avoid top-posting and insert your comments at the
	appropriate place in the mail.  Items which you are not
	directly addressing can be trimmed off to make for a
	shorter, more concise email.

Are some people making fun of me on the mailing list?  I can't
tell when some of them are being serious or not.

	Anyone with an address ending in .au is probably an
	Australian, although there are some others scattered
	around without .au addresses.  These people speak a
	different language and you can never tell if they're
	being serious or not.  We^WThey sometimes put in a ';)'
	symbol as a hint.

Kind regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B             Operations/Security

:wink:

My guess is that rt-mailgate could be beefed up to look at
the ‘In-Reply-To’ (and maybe Message-ID) headers when it can’t
parse the ticket id off the subject line. Most decent
MUAs should preserve enough info to work

“Most” “decent”

I’ve actually pondered this in the past. I even almost implemented it.
But I’ve become more and more convinced that it will result in the
wrong thing happening often enough to become a major pain in the ass.

There could be many problems. For example, a customer
who never actually creates a new message when submitting a
ticket, but rather replies to an old, dead ticket and replaces
the subject. That works in RT as designed, but would break
with the In-Reply-To parsing.

Also, don’t forget all those mail clients which don’t include
refers-to or in-reply-to headers, like /bin/mail and SMS gateways.

What does Jesse think?

Jesse thinks that transparent solutions are a good thing, but that
this particular idea is going to hurt a lot more than it’s going to
help.

One thing that can work is to make RT generate From: and Reply-To:
addresses of the form rt+ or rt- and use
the mail gateway’s --ticket-id-from-extension feature to figure things
out.

J

»|« http://www.bestpractical.com/rt – Trouble Ticketing. Free.

Jesse Vincent writes:

My guess is that rt-mailgate could be beefed up to look at
the ‘In-Reply-To’ (and maybe Message-ID) headers when it can’t
parse the ticket id off the subject line. Most decent
MUAs should preserve enough info to work

“Most” “decent”

Well, in truth, I can’t vouch for a lot of mailers. I still
use /bin/mail.

I’ve actually pondered this in the past. I even almost implemented it.
But I’ve become more and more convinced that it will result in the
wrong thing happening often enough to become a major pain in the ass.

There could be many problems. For example, a customer
who never actually creates a new message when submitting a
ticket, but rather replies to an old, dead ticket and replaces
the subject. That works in RT as designed, but would break
with the In-Reply-To parsing.

Also, don’t forget all those mail clients which don’t include
refers-to or in-reply-to headers, like /bin/mail and SMS gateways.

True as well. That’s why it has to be a fallback to parsing
the subject, not the preferred method.

What does Jesse think?

Jesse thinks that transparent solutions are a good thing, but that
this particular idea is going to hurt a lot more than it’s going to
help.

Quite Possibly. As I said in earlier mail, I’m not taking
the ticket id out of the subject line. I think, however, I’m
going to leave the fallback to In-Reply-To hack in my system
and see how it goes. Eventually I’ll find out if it works or
not (at least for my customer base - YMMV :slight_smile: ).

I’ve actually pondered this in the past. I even almost implemented it.
But I’ve become more and more convinced that it will result in the
wrong thing happening often enough to become a major pain in the ass.

There could be many problems. For example, a customer
who never actually creates a new message when submitting a
ticket, but rather replies to an old, dead ticket and replaces
the subject. That works in RT as designed, but would break
with the In-Reply-To parsing.

Also, don’t forget all those mail clients which don’t include
refers-to or in-reply-to headers, like /bin/mail and SMS gateways.

Yes, Exchange for instance does not use In-Reply-To and Reference headers.
And also don’t forget that some users are not aware of any threading
feature. They just reuse an answer from RT, reply-to it, and change the
subject to issue a new request.

In this case you have to unmerge a ticket in RT to identifie the new
request, which seems to be extremely complicated.

Regards,
Dirk.

Dr. Dirk Pape (Leiter des Rechnerbetriebs)
FB Mathematik und Informatik der FU-Berlin
Takustr. 9, 14195 Berlin
Tel. +49 (30) 838 75143, Fax. +49 (30) 838 75190

Yesterday Sheeri Kritzer wrote:

If the subject line is that offensive, I’d suggest changing the order
of the subject line, so instead of

[RT tag] subject

you have

subject [RT tag]

and then that’s nicer to read.

That’s one of the first changes I made here. I don’t think recipients
are too perplexed by having something extra at the end of the subject
line.

It seems to work quite well, but some mailers break long subject lines.
Sometimes this can be at the space character that immediately precedes
the # in the tag. (There’s a fix for this that involves tweaking a
regexp somewhere, but I can’t remember it right now.)

If you’re interested in how to do this, I posted details to this list in
approximately March this year.

Smylers
GBdirect

Hmm… I dunno… might be nifty to have the ticket # in an X-Header… like
X-RT-Ticket: or something along those lines… :slight_smile:

No, the ticket number has to come back from the user. RT can’t set
custom headers in some guy’s Outlook.

Probably be better off hacking Message-ID and then parsing

References. No sane MUA will be mucking with those (so I’m still not sure
it’d work with Outlook).

At 12:01 01.11.2002 -0800, you wrote:>On Thu, Oct 31, 2002 at 02:10:09PM -0500, Rich Lafferty wrote:

Hmm… I dunno… might be nifty to have the ticket # in an X-Header…
like

X-RT-Ticket: or something along those lines… :slight_smile:
No, the ticket number has to come back from the user. RT can’t set
custom headers in some guy’s Outlook.
Probably be better off hacking Message-ID and then parsing
References. No sane MUA will be mucking with those (so I’m still not sure
it’d work with Outlook).

Not the MTA, but the user: Many people mix up “reply” and "forward"
buttons. I see it all the time. People who are not IT (and many people
within IT) don’t give a thought about such things.

Nils

Tony Aiuto tony@ics.com writes:

My guess is that rt-mailgate could be beefed up to look at
the ‘In-Reply-To’ (and maybe Message-ID) headers when it can’t
parse the ticket id off the subject line.

Or use email addresses which contain the ticket number…

Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

Tony Aiuto tony@ics.com writes:
My guess is that rt-mailgate could be beefed up to look at
the ‘In-Reply-To’ (and maybe Message-ID) headers when it can’t
parse the ticket id off the subject line.

Weimer@CERT.Uni-Stuttgart.DE writes
Or use email addresses which contain the ticket number…

Interesting idea. Is what you are proposing to
have outgoing mail from RT have a sender address of
rt-###@mysite.org?

What happens when the inevitable strikes and the user
replies to that address, but changes the subject to a
different ticket #? I think the subject should have
precedence.

-tony

Tony Aiuto tony@ics.com writes:

Interesting idea. Is what you are proposing to
have outgoing mail from RT have a sender address of
rt-###@mysite.org?

We use nnn@RT.CERT.Uni-Stuttgart.DE. We’ve published the mail
gateway, but I haven’t change SendMail.om and friends yet.

What happens when the inevitable strikes and the user
replies to that address, but changes the subject to a
different ticket #? I think the subject should have
precedence.

The address has precende. Otherwise we wouldn’t be able to bounce
messages to another ticket.

Florian Weimer Weimer@CERT.Uni-Stuttgart.DE
University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT fax +49-711-685-5898

From: Tony Aiuto

Or use email addresses which contain the ticket number…

Interesting idea. Is what you are proposing to
have outgoing mail from RT have a sender address of
rt-###@mysite.org?

Wouldn’t this be mailer-specific? Qmail would want -something
and sendmail would accept +something and the two authors are
unlikely to ever agree.

What happens when the inevitable strikes and the user
replies to that address, but changes the subject to a
different ticket #? I think the subject should have
precedence.

If you are going to trust the end users to do the right thing
you can ask them to change the destination address also if they
want to refer to another ticket.

Les Mikesell
les@futuresource.com