It is necessary for sane threading.
There are two sensible approaches: chain replies or flat replies.
Chain reply requires remembering Message-ID of the last mail regarding given ticket, so if there is new comment, you put remembered Message-ID into In-Reply-To field. But if you have gaps (like your own comments, which currently won't send mail - see #94), it won't help you.
Flat reply requires remembering only Message-ID of the first message, which is the mail notifying about ticket creation. If you don't have it, there is a gap too, but e-mail client can spot that In-Reply-To repeats for all the comments for given ticket, so it can group them together, even if you don't have the first mail.
I think that flat replies are more practical, even if chain replies may supposedly better model reality (
supposedly, because it doesn't have to be the case, for instance latest comment doesn't really have to address what was in the previous one, etc.). But they better model ticket-comment relation.
(I am aware of References:, but I'm avoiding this subject for now, as it would require tracking Message-IDs of all comments to tickets, which doesn't seem truly necessary, even if it would be nice feature.)
We could do chained replies by adding a message ID to the event table, then finding the last event for that ticket when the new one is created for the In-Reply-To header.
Chained replies won't work well (gap case) without References:, where all generated so far Message-IDs regarding given ticket (creating ticket mail, comment mails) should be put there.
Because you don't support specifying whether comment is a reply to the ticket body itself or any particular comment, I think flat replies are actually saner here.
Sure, that's also fine by me.