Mark Sapiro writes:
That said, the effect on the OP's case, which may be more common, may be harmful depending on list and Mailman config.
The original message from the OP (edited) is
Content-Type: multipart/related; boundary="000000000000da2dcc062cb38aa1"
Ouch, that's a mess. First, unless you elided it, it's missing the required type parameter. Despite being required, it's basically an optimization and in most cases will not be much of one. So that's not really a big deal. Second, the Content-IDs are malformed. They are supposed to have the form of message IDs. Also not a big deal, they're close enough for government work.
The big problem is I have no idea what the semantics of
multipart/related
text/plain
image/jpegshould be. Throwing away the image data seems like it would be the right thing to do according to RFC 2387, which delegates rendering of the entire multipart/related entity to the root entity. But if that were the desired result of the author of the original message, it's straightforward to achieve by inverting the related and alternative parts. And (at least for image content) I would think that would be a rare intention.
I don't see an obvious way to resolve this without checking what popular MUAs do with the various possibilities. So as long as your patch does the expected thing, it's the minimal solution.
Steve