Q: How does Request Tracker relay email messages?

• Why did RT take a message I sent to the queue and re-send it to the Requestor?
• Why did Request Tracker forward a message from third party on to the Requestor as if it came from us?

Context

• Request Tracker (RT) on help.mit.edu
• Ticket tracking at MIT

Answer

This article describes the default email behavior of a Request Tracker queue, which includes email relaying. Email relaying is useful because it allows Staff (consultants, analysts, technicians, etc.) who work on tickets to interact with the Requestor entirely via email, without having to go into the RT web interface every time they want to send a message to the Requestor.

In short such an email-only workflow can look like this:

• The Requestor sends a message to the RT queue's email address
• RT creates a new ticket and
  • sends an auto-reply to the Requestor to let her know a ticket has been created
  • sends a copy of the original message to the AdminCc watchers on the queue to let them know a new ticket needs to be worked on
• The AdminCc watcher replies to the notification message from RT as if they were replying to the Requestor
• RT receives this reply on the queue's Correspondence address (sometimes referred to as the Reply address) and then relays it to the Requestor as if it had been sent from RT
• Repeat until ticket is resolved

In the above workflow, both requestor and IT staff member can use their personal email clients, with RT relaying messages back and forth and recording the conversation in the ticket.

Correspondence vs. Comment addresses

Each RT queue has two email addresses, the Correspondence address (sometimes referred to as the Reply address) and the Comment address. By default RT behaves differently for messages received at each of these addresses.

Correspondence

Messages received on a queue's Correspondence address are interpreted as intended for the ticket's Requestor.

If the message is from the Requestor, RT will append it to the ticket as a new Correspondence history entry. RT will also forward a copy to any AdminCc watchers on the queue to let them know about the new entry.

If the message is not from the Requestor, RT will append it to the ticket as a new Correspondence history entry. RT will also relay a copy of the message to the Requestor, assuming it is intended for them. It will copy any Cc or AdminCc watchers on this relayed message.

Requesters can also connect to the RT Self-Service web interface and review any correspondence in their tickets' histories.

The above description is slightly simplified. In cases where a ticket has multiple Requestors and Cc watchers, RT will also relay the message to any Requestors or Cc watchers who are not the sender of the message.

Comments

Messages received on a queue's Comment address are interpreted as intended for staff working on tickets, and not shared with the Requestor.

If a message is received on a queue's Comment address, RT will append it to the ticket history as a new Comment. RT will also forward a copy of the message to any AdminCc watchers on the queue or the ticket.

Where this can cause unexpected problems

In cases where a ticket involves communications with customers who are not Requestors on the ticket, or a ticket receives mail from third parties on the Correspondence address, this can sometimes lead to unexpected or confusing behavior.

For example, if a requestor replies to correspondence they've received from RT and copies a colleague or other third party to ask them to provide more information, and that third party then replies to everyone, including the RT queue, RT will take that message and relay it to the requestor (the original customer) as if it had been generated by RT (the From address will be the RT queue, not the colleague who sent it originally). The requestor will get a second copy of the message, and may be confused.

In another example, let's assume a ticket starts with Fred as the requestor. Fred is assistant to Jane, a faculty member. At some point Fred has done all he can, and effectively hands the conversation over to Jane for final steps. Jane is now effectively the real customer on this ticket. However, the staff working on the ticket leave Fred as the requestor and do not add Jane. Instead they just manually copy her on mail. Jane replies to the staff member's RT message, and RT will turn around the message and relay it to the requestor, Fred, as if it had been sent to and intended for him. This can be confusing to Fred, who doesn't know why he is getting this note.

In both of the above cases, the best solution is for staff to update the requestor list for the ticket. This ca include adding any new customers as requestors, removing any requestor who is no longer an active customer on the ticket, or disabling email to "inactive" customers who should remain on the list of requestors for tracking purposes. This last action is infrequently taken but see How do I disable email to some requestors on an RT ticket? for instructions on how to do this.

Diagram

The diagram below illustrates basic email behavior as described above for default RT queue configurations.

Default and custom configurations

Request Tracker queues are highly customizable and queue administrators have a lot of control over the way their queues behave, including changing the behavior described above to something completely different. The above description applies to the default queue configurations that new queues are set up with.

Queue behavior, including how they behave for email received and how and if they relay messages, is controlled by the Scrips applied to a queue. For those of you who are queue administrators, new queues are configured with the following four Scrips in place:

• On Create Autoreply to Requestors with Template Autoreply
  This scrip will send a standard autoreply message as specified in the global autoreply template to the requestor when a new ticket is created.
• On Create Notify AdminCcs with Template Create Notification
  This scrip will send a notification email message to a queue's AdminCc watchers when a new ticket is created.
• On Correspond Notify Requestors, Ccs, AdminCcs, and Other Recipients with Template Correspondence
  This scrip relays a copy of any message received for a ticket the queue's correspondence address to the ticket's Requestors, any Cc watchers, any AdminCc watchers, and any manually specified additional recipients.
• On Comment Notify AdminCcs and Other Recipients as a Comment with Template Comment
  This scrip relays a copy of any message received for a ticket on the queue's comment address to the ticket's AdminCc watchers and any manually specified additional recipients. It will do so as a comment, coming from the queue's comment address. (Replies will therefore also be treated as comments.)

See also

• How do I disable email to some requestors on an RT ticket?