I ran into the same issue a few months ago when I first deployed RT.
After thinking through it and experimented with several workarounds (both technical and process-based), I have reached the following conclusions.
Well, before I get into my conclusions, let me make sure I understand what you are trying to do:
Why did Jeff CC Barrett, Tony, and John in the original email sent to RT-helpdesk in the first place? Is it because you simply want those CC’ed people to be aware of the request, or do you anticipate those CC’ed people to add correspondences to the request because they may have additional info or comments to add during the request’s life cycle?
If it’s the latter, then we are dealing with the same issue. This is what I called a type of ‘collaborative’ workflow: in the colloaborative workflow, the requestor initiates a request where he wants other parties (in addition to himself and the request taker) to participate in the life-cycle of the request. In fact, this is the main reason I installed RT in order to improve and track some of the collaborative processes in the company I work at.
As you noted in your problem discription, the ‘intuitive’ behavior from the users using RT via email will lead to to creation of duplicated RT ticket.
Contrast collaborative workflows to 1-on-1 simple workflows: requestor generates a request, queue admin takes the request and resolves it (possibly after some back-and-forth correspondences), everyone lives happily ever after.
I have concluded that use of RT via email and collaborative workflow are incompatible at this point. The fundamental problem is that, if you want to use RT to support collaborative workflows, the CC list (or Watcher list, in RT’s nomenclature) needs to be stored in RT repository, rather than being managed by ther users in their email client’s cc field. You have that kind of control only through the RT Web interface.
In fact, I have established a RT usage policy in my company which states that, when you submit a new ticket to RT, do NOT specify any CC list. If you do want to include other people in the life cycle of a request, in the BODY of the email, add the line “Notify: Bob, Joe, Susan” at the first line in the body. The request taker, upon seeing that Notify list, will set up RT watchers via the RT web interface.
I’m also trying to train the users to use RT web interface to create the ticket; in the web interface, you can set up the Watcher list yourself. This approach offloads the Watcher list management from my queue admins, but so far I haven’t been able to convince all users to do that yet (submitting a new RT request via email is a lot easier).
In RT 3.2.2, the CC list field in Create Request web page is a free text field where you are supposed to entered the list of comma-delimited email addresses of the Watchers you want to set for the ticket. If you type the wrong email addresses, RT will create RT accounts for them if they are not existing RT users. I hacked the Ticket.pm module (I think) so it does some extra check and would not allow any unknown RT user email addresses in the Watcher field.
But then there is the issue with email aliases. In our MS Exchange server, we have convenient ‘pseudo’ email accounts like email@example.com, firstname.lastname@example.org, etc. I need to create RT users with these email addresses. But then I can’t really control certain group-based access control anymore, since the RT user ‘email@example.com’ is not the same as the group of RT users who are in the QA group. I could (and did) create a RT group that contains the QA users, but then the user needs to think about whether they should use ‘firstname.lastname@example.org’ or use the QA group in RT when setting up the Watchers – not all my users have CS degree
Anyway, it’s an interesting problem for which I don’t see a clean solution at this point.