At 10:08 AM +0200 6/26/2001, Norbert Schollum wrote:
in the manual it says, that replying to a
message with the ticket-ID in the subject
the mail will be handled as a comment.
but with me it always becomes a Reply.
in the history it says “mail sent by…”
It depends on the alias to which the message is sent. If the alias is
of type “comment” then the email reply will be an RT comment. If the
alias is of type “correspond” then the email reply will be an RT
RT is set up so that the “public” address of a queue should be a
"correspond" queue. Typically I think you maintain two separate
aliases for each queue. Something like:
trouble |"//mailgate correspond queue"
trouble-internal |"//mailgate comment queue"
Users would send trouble reports and followups to
"firstname.lastname@example.org". Replies from the support staff would by
default go to "email@example.com" as well, meaning it would be a
reply. If a support tech wanted to send comments, they would go to
There are several differences in RT 1.x between comment and
correspond queues other than who receives the mail that motivate
using “correspond” quesus as the official address of a queue:
correspond queues will create new tickets when receiving mail not
associated with an open ticket, comment queues will not (I believe
you just get an error).
correspond queues will “open” a ticket for which it receives mail
(e.g., if the ticket was marked “resolved” it will change the ticket
status). Comment queues will add the comments to the ticket, but a
resolved ticket stays closed.
Not having Jesse’s experience with automated systems, I hacked RT to
allow comment queues to create new tickets, and then published the
"comment" queue address as the public address. This made sense to me
because then most mail would remain “private” to the techs, and they
could use email to comment on all the issues that arose. However,
ticket opening is really important. Anytime you receive mail about a
ticket from a user, you always want the ticket to open back up
(even when it’s a false alarm!) or else you can miss important
messages like “I thought it was fixed but it really isn’t”.
It’s okay for the techs to have an option one way or the other, but
not for users.