Incorrect processing of multipart/related

Yes, please. Please do upload a sample message that shows the problem. You
can mark the bug report as private so that it won't be visible to the
public.

Cheers,
Uday

Here is an example email which doesn't get decoded correctly. There are two png files which get lost. (The html part does get decoded.)

No need to mark this private.

I've seen this before, too. Editing the email and changing multipart/related to multipart/mixed (in the main Content-type header) lets me at least see the image buttons so I can use '$ e' to see the images with an external viewer.

Regarding John Hein's comment, I tried this modification as well and vm can decipher the
modified email.

This message came up Content-Type "multipart/related", whereas it should have come with "multipart/alternative". The overall structure is

|- multipart/related
   |- multipart/alternative
       |- text/plain
       |- text/html
   |- image/png
   |- image/png

whereas the correct structure would have been:

|- multipart/altenative
   |- text/plain
   |- multipart/related
       |- text/html
       |- image/png
       |- image/png

Assuming that you are using emacs-w3m to decode html, VM would pass the multipart/related content to emacs-w3m, which handles the images fine. However, since the message came with a multipart/alternative as the starting component of multipart/related, emacs-w3m gets only the text/html part and not the images.

I notice that an old RFC, 1872, asked for this kind of special treatment of multipart/alternative. See section 3.2. However, this has been removed in the standard (RFC 2387). That doesn't stop some software makers from continuing the practice, I suppose.

I will think about how best to work around the problem.

I seem to recall discussion in the past about making vm-decode-mime-message do a more complete job at displaying all the various mime parts as buttons. Maybe another state in addition to the current 3 states: decoded, buttons, raw. Perhaps change 'buttons' to two states: one that display buttons normally based on configured visibility and another that displays all buttons regardless of visibility rules (maybe "visible" and "invisible" mime parts?).

I should have mentioned that workaround (in my comment #6) doesn't address a solution for the "broken" mime, just a workaround to allow a user to get at the otherwise invisible mime without too much trouble (like having to edit the message or go to raw mode, save the message and decode a mime part manually).

On Sat, Nov 5, 2011 at 3:29 AM, John Hein <email address hidden> wrote:
> I seem to recall discussion in the past about making vm-decode-mime-
> message do a more complete job at displaying all the various mime parts
> as buttons.  Maybe another state in addition to the current 3 states:
> decoded, buttons, raw.  Perhaps change 'buttons' to two states: one that
> display buttons normally based on configured visibility and another that
> displays all buttons regardless of visibility rules (maybe "visible" and
> "invisible" mime parts?).
>
> --
> You received this bug notification because you are subscribed to VM.
> https://bugs.launchpad.net/bugs/881411
>
> Title:
>  Mime attachment not processed correctly.
>
> Status in VM (View Mail) for Emacs:
>  New
>
> Bug description:
>  Certain emails with [cid...] in the text part, which report the
>  existence of  inline images, do not get decoded with the current
>  stable version of vm (8.20a on emacs 23.3).  I can forward an example
>  of this type of email, which seems to have appeared recently (new
>  Microsoft trick?).  By the way, mutt seems to be able to handle
>  messages of this type.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/vm/+bug/881411/+subscriptions
>

IIRC that was something Robert did when I was receiving messages from
a client using Apple Mail where the attachments were embedded inside
poorly structured MIME. The workaround Robert provided was to enable
all MIME objects to be displayed so that you could select individual
'bits'. As you point out, this ws a workaround. I'm not sure what
happened to that functionality possibly the issue with Apple Mail
attachments was fixed and so the functionality was removed?

Tim

--
Tim Cross

Hi Tim, the Apple Mail problem is quite different. (It has to do with multipart/alternative, not multipart/related).

To be perfectly clear, the standard requires any multipart/related combinations that VM can't figure out to be treated as if they were multipart/mixed. VM isn't doing so at present, and it is "buggy" to that extent.

On Sun, Nov 6, 2011 at 11:39 AM, Uday Reddy <email address hidden> wrote:
> Hi Tim, the Apple Mail problem is quite different.  (It has to do with
> multipart/alternative, not multipart/related).
>
> --
> You received this bug notification because you are subscribed to VM.
> https://bugs.launchpad.net/bugs/881411
>
> Title:
>  Mime attachment not processed correctly.
>
> Status in VM (View Mail) for Emacs:
>  Triaged
>
> Bug description:
>  Certain emails with [cid...] in the text part, which report the
>  existence of  inline images, do not get decoded with the current
>  stable version of vm (8.20a on emacs 23.3).  I can forward an example
>  of this type of email, which seems to have appeared recently (new
>  Microsoft trick?).  By the way, mutt seems to be able to handle
>  messages of this type.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/vm/+bug/881411/+subscriptions
>

Sorry, I should have been clearer. I was only referring to the feature
which allowed all mime parts to be displayed as buttons that John
referred to. When the issue with Apple Mail attachments first came up,
that was the workaround which was provided so taht you could at least
get to the attachment. I wasn't meaning to imply that it was the same
problem, only background on what John was saying. From memory, I had
to apply a patch that (Rob?) provided in order to have this
functionality. Looking through my archives, I can find references to
this issue, but not he patch. I wouldn't expect it to be directly
applicable, but was hoping ti would provide a starting point for a
temporary workaround.

Tim

Tim

--
Tim Cross

But, surprisingly, some multipart/related messages seem to work. See Bryoney Johnson, 2011-01-31, in test-mime.

It would be very useful to have a hierarchal mime part listing, very similar to what Uday showed in #5.

Get just this kind of tree with buttons to display mime parts at any level. I am often mystified by the exact structure of the mail and have trouble finding exactly with part I need to see.

Mark Diekhans writes:

> It would be very useful to have a hierarchal mime part listing, very
> similar to what Uday showed in #5.

Try vm-mime-list-part-structure, which doesn't look as pretty as my hand
drawing :-) but it works. I notice that it is not described in the manual.
Another to-do item here.

Cheers,
Uday

Uday,

So, any ideas on how to fix the problem? If the hierarchal listing
could be turned into a list in which one could select attachments to
display or save, that would work for me. This is sort of how mutt
does it.

Best regards,

Dave

Uday Reddy writes:
 > Mark Diekhans writes:
 >
 > > It would be very useful to have a hierarchal mime part listing, very
 > > similar to what Uday showed in #5.
 >
 > Try vm-mime-list-part-structure, which doesn't look as pretty as my hand
 > drawing :-) but it works. I notice that it is not described in the manual.
 > Another to-do item here.
 >
 > Cheers,
 > Uday
 >
 > --
 > You received this bug notification because you are subscribed to the bug
 > report.
 > https://bugs.launchpad.net/bugs/881411
 >
 > Title:
 > Incorrect processing of multipart/related
 >
 > Status in VM (View Mail) for Emacs:
 > Triaged
 >
 > Bug description:
 > Certain emails with [cid...] in the text part, which report the
 > existence of inline images, do not get decoded with the current
 > stable version of vm (8.20a on emacs 23.3). I can forward an example
 > of this type of email, which seems to have appeared recently (new
 > Microsoft trick?). By the way, mutt seems to be able to handle
 > messages of this type.
 >
 > To manage notifications about this bug go to:
 > https://bugs.launchpad.net/vm/+bug/881411/+subscriptions

--
David J. Raymond
Prof. of Physics
New Mexico Tech
http://www.physics.nmt.edu/~raymond/index.html

I can give you a flag that treats `multipart/related' as if it were `multipart/mixed'. Until then, you have to edit the messages manually to do that conversion (as John Hein recommended).

Cheers,
Uday

That would work. -- Dave

Uday Reddy writes:
 > I can give you a flag that treats `multipart/related' as if it were
 > `multipart/mixed'. Until then, you have to edit the messages manually
 > to do that conversion (as John Hein recommended).
 >
 > Cheers,
 > Uday
--
David J. Raymond
Prof. of Physics
New Mexico Tech
http://www.physics.nmt.edu/~raymond/index.html

Initial fix committed in rev. 1361.

Dear David and John, Rechecking this bug report, I find that VM 8.2.0a has been working fine for multipart/related content as long as you use emacs-w3m as your html viewer.

Can you clarify what settings you used for html viewing, when you reported the original problem?

Cheers,
Uday

Dear Uday,

I am using chromium for html stuff. The pertinent part of my .emacs
file is listed below.

When I try to load emacs-w3m, emacs23 says that w3m isn't supported.

Best,

Dave

------------------------

;;; Load VM
(require 'vm-autoloads)
;;; the vm-reply library doesn't get autoloaded (bug in 8.2.0b)
(load "/usr/share/emacs/site-lisp/vm/vm-reply")
;;; VM configuration
(setq vm-mail-header-from "David Raymond <email address hidden>")
(setq vm-use-toolbar nil)
(setq vm-fill-paragraphs-containing-long-lines 75)
(setq vm-move-after-deleting t)
(setq vm-mutable-frames nil)
(setq vm-preview-lines nil)
(setq vm-auto-next-message nil)
(setq vm-folder-directory "~/Mail/")
(setq vm-confirm-new-folders t)
(setq vm-delete-after-saving t)
(setq vm-mime-attachment-save-directory "~/Desktop/")
(setq vm-mime-delete-after-saving t)
(setq vm-reply-ignored-addresses '("<email address hidden>"))
(add-to-list 'vm-mime-default-face-charsets "Windows-1251")
(add-to-list 'vm-mime-default-face-charsets "Windows-1252")
(add-to-list 'vm-mime-default-face-charsets "Windows-1257")
(setq vm-mime-internal-content-types '("text"))
(setq vm-imagemagick-convert-program nil)
(setq vm-mime-internal-content-type-exceptions '("text/html"))
(setq vm-mime-text/html-handler 'chromium)
(setq vm-auto-decode-mime-messages nil)
(setq vm-auto-displayed-mime-content-types '("text"))
(setq vm-mime-external-content-types-alist
        '(
   ;("text/html" "chromium")
   ("image/eps" "gv")
   ("image" "ristretto")
   ("application/postscript" "gv")
   ("application/pdf" "xpdf")
   ("application/lyx" "lyx")
   ("application/excel" "gnumeric")
   ))
(define-key menu-bar-tools-menu [rmail] '("Read Mail" . vm))
(define-key-after menu-bar-tools-menu [smail] '("Send Mail" . vm-mail) 'rmail)

;;; Sendmail configuration
(setq mail-user-agent 'sendmail-user-agent)
(setq mail-from-style 'angles)
(setq user-full-name "David Raymond")
(setq user-mail-address "<email address hidden>")
(setq mail-default-reply-to "David Raymond <email address hidden>")

;;; Mail archiving
(setq mail-archive-file-name "~/Mail/sent")

;;; BBDB setup
(require 'bbdb)
(bbdb-initialize 'sendmail 'vm)
(bbdb-insinuate-vm)
(add-hook 'mail-setup-hook 'bbdb-insinuate-sendmail)
(setq bbdb-quiet-about-name-mismatches t)
(setq bbdb-use-pop-up nil)
(setq bbdb/mail-auto-create-p nil)

;;; Set external browser
(setq browse-url-generic-program "chromium"
      browse-url-browser-function 'browse-url-generic)

-------------------------------------------------------

Uday Reddy writes:
 > Dear David and John, Rechecking this bug report, I find that VM 8.2.0a
 > has been working fine for multipart/related content as long as you use
 > emacs-w3m as your html viewer.
 >
 > Can you clarify what settings you used for html viewing, when you
 > reported the original problem?
 >
 > Cheers,
 > Uday
 >
 > --
 > You received this bug notification because you are subscribed to the bug
 > report.
 > https://bugs.launchpad.net/bugs/881411
 >
 > Title:
 > Incorrect processing of multipart/related
 >
 > Status in VM (View Mail) for Emacs:
 > In Progress
 >
 > Bug description:
 > Certain emails with [cid...] in the text part,...

Ok, that confirms that 8.2.0a was working ok.

If you can get emacs-w3m to work, you will see much better performance for
html. multipart/related content is not expected to work with external
viewers.

Cheers,
Uday

I have a message (from outlook/exchange) that has a structure like so (reported by vm-mime-list-part-structure):

=================
Some subject
("multipart/related" "boundary=_004_A9200AF02797C34B99E9E6666786F8003F8263A6SJCMBX01abcd_" "type=multipart/alternative")
 ("multipart/alternative" "boundary=_000_A9200AF02797C34B99E9E6666786F8003F8263A6SJCMBX01abcd_")
  ("text/plain" "charset=us-ascii")
  ("text/html" "charset=us-ascii")
 ("image/png" "name=image001.png") id="<image001.png@01CCDC22.1EAEE940>" desc="image001.png" ("inline" "filename=image001.png" "size=68890" "creation-date=Thu, 26 Jan 2012 17:00:40 GMT" "modification-date=Thu, 26 Jan 2012 17:00:40 GMT")
=================

With either...

vm-mime-type-converter-alist set to (("text/html" "text/plain" "w3m -O ascii -T text/html -dump"))
 or
vm-mime-type-converter-alist set to nil _and_ emacs-w3m set up and working with a vm version that knows to use it.

and...

(a) vm-mime-internal-content-type-exceptions set to ("text/html") (which I have had set off and on over the years as the quality of vm + w3m + emacs-w3m have varied).

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

In both emacs with X and emacs -nw, if I leave the multipart/related (instead of multipart/mixed) no image attachment button is visible. It is this case, where it would be nice to have the extra state in vm-decode-mime-message that allows displaying the "other" related part (at least the mime buttons for it).

(b) vm-mime-internal-content-type-exceptions set to nil

This is the same as (a) except that in the emacs/X case, the image is displayed inline (if you have inline images enabled). This is not the same as having the image mime button available.

Here's a table that explains it better perhaps (probably best viewed on the web rendering of this bug, but we'll see what it looks like after I post it):

vm-mime-internal-content-type-exceptions multipart/related emacs/X or inline image image button
                                                                      or multipart/mixed emacs -nw displayed available
----------------------------------------------------------------- ----------------------------- ------------------------ ------------------- ---------------------
   ("text/html") related X no no
   nil related X yes no
   ("text/html") mixed X no yes
   nil mixed X yes yes

   ("text/html") related nw no no
   nil ...

In the previous post, "inline images enabled" means 'vm-w3m-display-inline-images' set to t. I have not tried launching an external html viewer (firefox, chromium, whatever).

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

John Hein writes:

> So as you can see, there still exists a case where you cannot get to the
> image without editing the 'related' to be 'mixed'.

Sorry, I couldn't figure out the case from the table. Can you be explicit?

Cheers,
Uday

Blech... that table in comment 22 rendered horribly. Attached is an html version...

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.

John Hein writes:

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

I think what is happening is that people are doing drag-and-drop into the
html editor instead of "attaching" graphics images. The html editors assume
that they want to place the images in the middle of the text rather than
attaching them. That is why we are seeing increasing use of
multipart/related.

Treating multipart/related as multipart/mixed will solve these problems for
you.

But, that is not what multipart/related was designed for. Quoting RFC 2387:

   The Multipart/Related media type is intended for compound objects
   consisting of several inter-related body parts. For a
   Multipart/Related object, proper display cannot be achieved by
   individually displaying the constituent body parts.

For genuine multipart/related content, I have now found a nice generic
solution. Commiting it soon.

Cheers,
Uday

Dear Uday and John,

Wow, this is getting complicated! I can see Uday's point that
this may not be a bug as long as use of vm requires an internal
browser such as emacs-w3m. I tried installing and using emacs-w3m
(the cvc version for emacs23!) and it caused me nothing but trouble.
I had to reinstall emacs before I could use chromium as the
external browser again!

I would be happy with an option to convert "related" to "mixed";
something like

(setq vm-convert-mime-related-to-mixed t/nil) with the default being
nil.

If it is any consolation, mutt presents "related" images separate
from the html as well.

Best regards,

Dave

Uday Reddy writes:
 > John Hein writes:
 > ...
 > So, what is the "bug"?
 >
 > Cheers,
 > Uday

Fix committed in rev. 1375 and 1377.

We keep track of whether the multipart/related processing was successful and, if not, fall back to multipart/mixed method.

Hello Uday,

I guess this fix has not made it into a released version yet. Is there
a way to download a current snapshot? Or, do you not recommend this?

Thanks,

Dave

Uday Reddy writes:
 > Fix committed in rev. 1375 and 1377.
 >
 > We keep track of whether the multipart/related processing was successful
 > and, if not, fall back to multipart/mixed method.
 >
 > --
 > You received this bug notification because you are subscribed to the bug
 > report.
 > https://bugs.launchpad.net/bugs/881411
 >
 > Title:
 > Incorrect processing of multipart/related
 >
 > Status in VM (View Mail) for Emacs:
 > Fix Committed
 >
 > Bug description:
 > Certain emails with [cid...] in the text part, which report the
 > existence of inline images, do not get decoded with the current
 > stable version of vm (8.20a on emacs 23.3). I can forward an example
 > of this type of email, which seems to have appeared recently (new
 > Microsoft trick?). By the way, mutt seems to be able to handle
 > messages of this type.
 >
 > To manage notifications about this bug go to:
 > https://bugs.launchpad.net/vm/+bug/881411/+subscriptions

--
David J. Raymond
Prof. of Physics
New Mexico Tech
http://www.physics.nmt.edu/~raymond/index.html

Hi David, the README file in the vm directory explains how to download the development version of VM via Bazaar.

Thanks Uday, I got the latest tarball and installed it. -- Dave

Uday Reddy writes:
 > Hi David, the README file in the vm directory explains how to download
 > the development version of VM via Bazaar.
 >
 > --
 > You received this bug notification because you are subscribed to the bug
 > report.
 > https://bugs.launchpad.net/bugs/881411
 >
 > Title:
 > Incorrect processing of multipart/related
 >
 > Status in VM (View Mail) for Emacs:
 > Fix Committed
 >
 > Bug description:
 > Certain emails with [cid...] in the text part, which report the
 > existence of inline images, do not get decoded with the current
 > stable version of vm (8.20a on emacs 23.3). I can forward an example
 > of this type of email, which seems to have appeared recently (new
 > Microsoft trick?). By the way, mutt seems to be able to handle
 > messages of this type.
 >
 > To manage notifications about this bug go to:
 > https://bugs.launchpad.net/vm/+bug/881411/+subscriptions

--
David J. Raymond
Prof. of Physics
New Mexico Tech
http://www.physics.nmt.edu/~raymond/index.html