<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Mon  5.Jan'09 at 15:10:25 +0200, Razvan Cosma wrote:<br>
>     Hello,<br>
>    I'm trying to figure out the best way to deal with a common issue we have<br>
>    when multiple recipients are specified for a message. If a customer sends<br>
>    a message to our ticket system with a dozen other persons in to: and/or<br>
>    cc:, it will be stored correctly, but<br>
>    1. If any of the other recipients replies to the initial message, keeping<br>
>    RT in Cc: a new ticket will be created, with him/her as requestor. Is it<br>
>    possible for RT to detect such replies and store them as part of the same<br>
>    issue?<br>
<br>
The problem is that it's relatively hard to do this _right_. Most of the<br>
ways one could do this would result in RT accidentally aggregating all<br>
sorts of unrelated messages.  In particular, there's a user behaviour<br>
that makes this work _really_ poorly:<br>
<br>
Users frequently craft new messages by clicking "reply" or "reply all"<br>
and blanking out the subject and body. In at least one of the most<br>
common mail clients (outlook), this means you end up with a message that<br>
has the In-Reply-To: header but isn't actually a reply.<br>
<br>
Coping with both sides of this would require some engineering work,<br>
though I do have a design for a system that would make you happy. It's a<br>
fair bit of work, though.<br>
<br>
</blockquote><div><br>How about if this other header (such as In-Reply-To:) matches *AND* the subject (minus prefixes) match, then route the reply into an existing ticket?  So:<br><br>If subject contains proper tags<br>  route it according to the tags<br>
else if In-Reply-To: matches an existing ticket AND the subjects match (minus prefixes like RE: or FWD:)<br>  route it according to what's found<br>else<br>  create new ticket<br><br>I'm guessing that metadata (in-reply-to) is not in its own field and indexed -- which is probably necessary.  Then the matching logic above needs to be written.  I also don't know what the best choice would be for header-based matching (is In-Reply-To: the best choice?) -- that might need some research, too.<br>
<br>   -=| Ben<br><br><br><br><br></div></div>