Comment 27 for bug 881411

Re: comment #25... the case is that there is (currently, in 8.2.0b-ish vm versions) no vm-ish way to get to the image without having to jump through some hoop of some sort. Namely...

_If_ you're running emacs/X, and if you have emacs-w3m, and if you have inline images enabled, you can _see_ the image. Also vm-mime-save-all-attachments will allow you to save it. But you can't get to just one individual mime attachment (like if you just want to launch an external image viewer without having to save all the attachments, go to the shell or a file manager and manually start the image viewer in whatever your favorite way is).

If you manually edit the message to change related to mixed, you can get to the mime button and do the normal various vm mime operations on it.

You could also vm-mime-decode-message until you get raw base64, save the base64 encoded pieces to a file and manually decode.

As you say, the ability to "treat multipart/related as multipart/mixed" will help here.

Uday Reddy wrote in comment #24:
 > 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.

Well, in theory, a mail reader could replace the CID tag with an image
ref, generate new html and save it to a temp location along with the
image, then spawn the external viewer pointing to the slightly
modified html.

But, I don't think anyone is asking for that here.

 > 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.

Yes, emacs-w3m + image inlining works for me on these kinds of messages, too (as you can see from the stupendous table I attached in comment #26).

 > So, what is the "bug"?

Good question. I don't know if the OP, Dave, wanted the images
decoded and displayed inline or just a way to get at the image.
I just wanted the latter, and in that sense I perhaps hijacked
this bug, however at the time, the edit-to-mixed hack workaround
(comment #3) seemed to appease Dave (comment #4), so I suspect
the latter is all he needs, too - but I could be wrong.