If you were to do it, you would attach another milter/filter that tries its best to parse the message and output the modified message, with original text part inserted as preformatted text into a suitable html template.
But you cannot generally change your users messages from their plaintext format. Not just because it is rude to sneakily change instead of police someones messages. But also because doing so would break legitimate use cases. It works for some simple cases (single plain-text part), it can be made to work for some special cases (plain-text part inlining attachments), but other messages just cannot be transformed without information or interoperability losses.
- What do you do with a message not containing any plain text (but still one or more attachments, plus meaningless preambles/epilogues)?
- Submitting patches to mailing lists generally does not tolerate html, because any superfluous markup would bar patches from being pulled directly into version control.
- If a message already had alternate parts, even after transformation of each alternate you cannot match its original (e.g. multi-language) presentation, because zero MUAs get multiple levels of multipart choice right.
- A message you transform might end up not being forwarded to the correct person, as the association with a service ticket is lost during transformation. One way I saw this manifest was that depending on whether I sent them plain text or html, the response of 3rd parties (with MUAs out of my control) would differ in whether it quoted back the ticket reference.
Instead, you probably want to roll out configuration management for your users mail clients, to have their outgoing messages match your expectations where possible, while still permitting use cases where html just won't do.
