Comment 24 for bug 881411

John Hein writes:

> I have to edit the multipart/related to be multipart/mixed in order to
> see the image attachment (invoking vm-mime-decode-mime-message once
> displays the text and the image buttons).

What you have to do to deal with buggy messages is a separate issue. I have
now added a variable using which you can get multipart/related treated as if
it is multipart/mixed. So, you are taken care of.

The question I am concerned about here is what the "bug" is that this bug
report is reporting.

multipart/related is meant for images that need to be embedded in message
display. Obviously this is only possible if you use an internal viewer for
the message display. If you use an external viewer, then the images cannot
be embedded. I don't think any mail client is able to handle that.

multipart/related also says that the first component of the multipart must
specify the content-type of the message, so that the mail client can decide
how to deal with it. If it knows that it can embed the images then it will
do so. If it know that it can't, then it will treat it as if it is
multipart/mixed.

However, Microsoft or whoever are sending messages where the first part is
not a content-type, but a multipart/alternative. So, VM can't look at it
and make a decision. So, it does the next best thing, viz., to assume that
the first part can deal with the embedded images. If you use an internal
viewer (which is Emacs-W3M for html), then it can embed images and it is
doing so.

When I wrote response #5, I seem to have thought that Emacs-W3M wasn't doing
it. But, on double checking, I find that it is doing it.

So, what is the "bug"?

Cheers,
Uday