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

[Josef 'Jeff' Sipek <[e-mail]>]

On Tue, Aug 08, 2017 at 11:17:41 -0700, Neil Jhaveri wrote:
> Yeah, the Apple Mail clients have a preference to avoid sending text/html,
> unless strictly necessary by the content:
...
> 
> How do other people here feel about the preference for text/plain?

Personally, I really like this preference for text/plain.  (Note that my
setup is strange since I use iOS on my phone and mutt on my laptop &
desktop.)

One important thing to point out about text/plain is that there are two ways
to treat it when composing the email:

1. the "unix" way, with ~80 column wrap consisting of inserted newlines, or
2. the "iOS" way, with no wrapping.

For example, if I write a paragraph of text with the iOS client, I end up
with a quoted-printable text/plain email that relies on the client to do the
wrapping since the paragraph is just one really long line.

In other words, text/plain is not inherently bad even without format=flowed.
Yes, it is not perfect, but in my opinion it works quite well even in fancy
mobile environments.

> On Aug 8, 2017, at 3:28 AM, Neil Jenkins <[e-mail]> wrote:
...
> 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?

IIRC, Lotus Notes supports (supported?) this as well.  It's been almost a
decade since I last used it so things may have changed since.

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

I'm not sure we can totally ignore this.  Even if Apple clients stop
generating these messages today, there are years worth of existing emails
using this kind of MIME structure.  Emails that clients will attempt to
fetch via jmap.

If we totally punt on this in jmap as part of the Message object (i.e., the
jmap server sends back some form of a message-too-complex error), any client
that wants to parse one of these mails sent by Apple clients will have to go
via the blob API and do its own MIME parsing.

Alternatively, we could make the server generate some sort of
text/{plain,html} view of the email to stuff into {text,html}Body when a
client attempts to fetch the mail.  In this case, we should probably specify
what the server should do as a bare minimum.  (E.g., the server MUST
support generating a HTML and plain text versions of arbitrary MIME
structures.)  Needless to say, this can lead to all sort of fun i18n/l10n
server-side issues.

(Now I'm curious what the FastMail client & server code does when it gets
one of these Apple client created emails...)

Actually, this makes me wonder... what should a jmap server do if the stored
message is somehow malformed?  There is a lot of broken email out there, and
the draft seems silent about how to handle them.

Jeff.