Email based trouble ticketing system

[Benjamin Scott]

On Sep 13 at 5:51pm, Travis Roy wrote:
>> So, you want a ticketing system that knows that an e-mail that wasn't sent 
>> through it, where the essential identifying information has been changed, 
>> is part of a particular ticket? Maybe I missed something.
>
> That should be possible based on the subject and header information.

    Subject lines tend to dupe a lot the way most people use them (e.g., people 
who never, ever fill in the subject line).  You wouldn't want to do anything 
with that.

   *If* all the various MUAs involved properly set the "In-Reply-To" header, 
then you could build the thread chain.  But this will fail if (for whatever 
reason) a reply-to-a-reply gets to the mail processor out-of-order.  Since 
Internet email is very asynchronous, this is a realistic scenario.

   (Anne sends a message A to everyone.  Bert sends a message B to all in reply 
to A; B is marked as a reply to A.  Charlie sends a message C to all in reply 
to B; C is marked as a reply to B.  RT gets C, then A, then B.  Since C is the 
first one RT sees, it generates a new ticket.  RT knows B and C are related, 
but nothing about A.  RT now gets A, so it generates a new ticket.  RT then 
gets B.  Now RT can connect A to C transitively, but it's too late, you've got 
a dupe ticket already.)

   And if something someone uses likes to munge Message-IDs, you're totally 
hosed.

   Like you say, the Right Thing to do is route everything through RT first. 
If Management(TM) is really that worried about email availability, invest in 
an expensive high-availability cluster or something.  Give them an ROI 
breakdown and they should get the picture.

-- 
Ben <dragonhawk at iname.com>