Re: [Jmap] Attachments and composing more complex MIME structures

[Neil Jhaveri <[e-mail]>]

Yeah, the Apple Mail clients have a preference to avoid sending text/html, unless strictly necessary by the content:
(A) A philosophical preference that text/plain be used whenever possible, since it results in a neater and more overall compact message, without the redundancy of including both a text/html part with a text/plain fallback alternative part.
(B) Broken implementations in the wild that caused various small support issues. The Apple clients did change once to always sending text/html if there are images, but reverted it in a software update. For instance, some Japanese cell phone carriers couldn’t properly handle messages sent to an MMS bridge e-mail address if an image wasn’t a top-level MIME part.

How do other people here feel about the preference for text/plain?


On Aug 8, 2017, at 3:28 AM, Neil Jenkins <[e-mail]> wrote:

> Although not clear yet (this bit of the spec needs a lot more details), the intention is that a JMAP server would convert this to an htmlBody in the Message object that combined the text and images (with cids).

I agree, I’d like to see if the API can remain as-is, and we detail in the spec how servers should construct MIME. I’d be happy to help with this part.

> No, but you could produce an HTML part that's going to render the same
> (and be more compatible).

Can you clarify this?



There is also the uglier case of "inlined attachments" that cannot be properly referenced by HTML tags, e.g.:
	[plain text]
	[zip attachment]
	[more plain text]

I think the Apple clients are the only ones that even support this in the UI and make a multipart/mixed message out of it, but I’m not sure. Does anybody know if any other major clients offer this kind of UX?  I’ve personally never been a fan of it at all, and I think the resultant message looks confusing in some other MUAs, but it does have some occasional use. My hunch is that it only affects the Apple clients, so it doesn’t seem worth complicating matters here.

Neil