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 <[EMAIL PROTECTED]>
_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss
