OK, there is no way this is not a gross abuse of the SMTP spec. But it leverages an awesome quirk of +MantisBT
's email reporting plugin.
I craft a message with a particular MessageID, and in that message, I included a References header that references...that same message ID. So, the message can be said to reference itself, which, while not explicitly disallowed by the RFCs, is definitely not what you're supposed
to do with it.
This message I crafted? Pass it into Mantis. Mantis will create a ticket. Pass it into Mantis again, mantis will take the second copy and add it to that existing ticket as a bugnote. Keep passing it into Mantis, and you'll keep getting notes added to that ticket.Close
that ticket, and the next time a message with that same messageID and References header shows up, and Mantis will create a new ticket, mark it as related
to the old, and future messages with that same messageID and References header will get added as bugnotes to the new ticket.
So, what's the upshot? Let's say you have an NMS that emails your bugtracker whenever a particular trigger is hit. You configure things so that those messages have a messageID that's only as unique as the trigger is; future triggerings of the same condition would produce the same message ID. So, now, if you have a flapping trigger, or if your trigger goes off from time to time without a clear indication of root cause, any future messages sent by the same trigger will get filed under the same ticket, and you build a history of the events. If you think you've got it licked, you close the ticket. Next time the trigger fires, a new
ticket gets opened, marked as related to the old ticket, and you can walk back the ticket history for that trigger for a historical perspective, if you wish.
And your ticket bookkeeping and cleanup gets grossly reduced, too.