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/jpeg
should 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
_______________________________________________
Mailman-users mailing list -- mailman-users@mailman3.org
To unsubscribe send an email to mailman-users-le...@mailman3.org
https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/
Archived at:
https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message/5EIGGBVL2OQ23LBBFHIMTDSGRERWUKRU/
This message sent to arch...@mail-archive.com
