Re: Apple Mail multipart message not displayed correctly

At Mon, 05 Feb 2018 22:28:16 +0900, Kazuhiro Ito <[email protected]> wrote:
Subject: Re: Apple Mail multipart message not displayed correctly
> 
> I've committed the workaround into SEMI-EPG's repository.  To enable
> it, set mime-view-multipart/alternative-show-all-children to t.

I have meant for some time to try this (and its sibling), and I finally
encountered a message where it was quite relevant to me.

The following is an extract of the headers and relevant content from
this message, which I believe was formatted by Gmail.

From my understanding of MIME it makes perfect sense.  There's a
multipart/related body containing a multipart/alternative part and an
image/png part, and the image part has a valid Content-ID that's
referenced by one of the multipart/alternative sub-parts.  All other
HTML-capable mailers I know of will display the image properly when
formatting and displaying the HTML content.

However the image is not displayed with WL when the text/html part
content is shown (with w3m) [only the "alt" text is shown and nothing I
could find would toggle that text to show the actual image), and of
course without the new control variables set to 't', there's no MIME
button for the final part of the two multipart/related parts either, and
thus this image is literally and entirely invisible to anyone who does
not view the raw message text.

I am grateful for the new variables.  At least now I can expand the
content of all the multipart/related parts and see the included images,
even if not in context within the HTML they should be embedded in.

However I would argue most strongly that their default value should be
't'.  When I say "show me the MIME 'buttons'" (i.e. with
wl-summary-toggle-mime-buttons), then I always want to see _all_ of the
MIME buttons, _all_ of the time.  Give me simple tools, not parental
policy.

However I would also like to work out how to fix whatever is wrong with
displaying inline images in a multipart/related message like this.  As
much as I detest HTML in email, it should still be usable since it has
become a de-facto standard in the internet today.


	
	MIME-Version: 1.0
	Content-Type: multipart/related; boundary="000000000000c0db9b0584fed671"
	
	--000000000000c0db9b0584fed671
	Content-Type: multipart/alternative; boundary="000000000000c0db990584fed670"
	
	--000000000000c0db990584fed670
	Content-Type: text/plain; charset="UTF-8"
	
	[image: image.png]
	
	--000000000000c0db990584fed670
	Content-Type: text/html; charset="UTF-8"
	
	<div dir="ltr"><div><img src="cid:ii_jtps8ufg0" alt="image.png" width="472" height="173"><br></div></div>
	
	--000000000000c0db990584fed670--
	--000000000000c0db9b0584fed671
	Content-Type: image/png; name="image.png"
	Content-Disposition: inline; filename="image.png"
	Content-Transfer-Encoding: base64
	Content-ID: <ii_jtps8ufg0>
	X-Attachment-Id: ii_jtps8ufg0
	
	[[ BASE-64 content here ]]
	


BTW, I think this is actually the exact same problem I wrote about way
back in 2012 when the message creator was the much maligned Apple Mail,
though I am still not convinced Apple Mail is/was wrong about its use of
MIME then either.

-- 
						Greg A. Woods
						Planix, Inc.

<[email protected]>       +1 250 762-7675        http://www.planix.com/

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRuK6dmwVAucmRxuh9mfXG3eL/0fwUCXJpg3gAKCRBmfXG3eL/0
fzj4AJ9TZFTNsAwgewS9WDT0OV2u89vOBwCg5VPpHZqvsow3XsQ08MGYXuT8rSI=
=W9jP
-----END PGP SIGNATURE-----