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

Neil Jenkins <neilj@fastmailteam.com> Wed, 09 August 2017 11:50 UTC

Return-Path: <neilj@fastmailteam.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5ACE13218C for <jmap@ietfa.amsl.com>; Wed, 9 Aug 2017 04:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.72
X-Spam-Level:
X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=pOG/zsj0; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QGcHlcv5
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8dJgLF7i_DV for <jmap@ietfa.amsl.com>; Wed, 9 Aug 2017 04:50:24 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2B9813217D for <jmap@ietf.org>; Wed, 9 Aug 2017 04:50:24 -0700 (PDT)
Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 39FED209E7 for <jmap@ietf.org>; Wed, 9 Aug 2017 07:50:24 -0400 (EDT)
Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 09 Aug 2017 07:50:24 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:in-reply-to:message-id:mime-version:references:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=0OP/KjB/wVjbMz9Gs jMFaQ8wa9BBprdve6t6NKnb6Pc=; b=pOG/zsj0qKicG8NSYT9xn88F4s8QU+Zrq PJvEEWL1l//SzUH+4O0IuDsO6/10mXZIGbBqJCOCYST/a4cjyfJ0YvvTTZMPd+Gn /zTw7QpuZ78sNuwNLXs7BzKDlXldnb0jFIe0sCYghAPQYrt5Y1BDxIsUcTDRtUmI FsqKrVSsrl7YqMw9Y6OjLnfdSM8NDwYMxfsZD/3PBSn/shlW11QmulDOxVVSgtsc hZnTYN/zirJHoynZYDhQ/tYA4isWdxtZHg3PgOOT22SHl5zouTDzgWq+BujpB5fL 2ynzqqPLryxrOnRi25hh8ZhKozVqWgOs4VRSL4wlzNfShEMc2nDVQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=0OP/Kj B/wVjbMz9GsjMFaQ8wa9BBprdve6t6NKnb6Pc=; b=QGcHlcv5ZWwqAWJyS/n3BO zDQIjLkHBUD2TKFXUliJfCoqV+AvQBvmKT2/rReNLTC5jqshZJf0G6wtmKr4s5F+ EBqcRCGWQwlUORb4rh+XdhZubOKEdMlk9MfVrG/yHUzOQa5/qTo2U+xaXWs6/5uV X3Jzh3N9YQ9uNVBopSWiosFS3fgVWMX41X2HYySu6sncaGnu6VEYs0Ngo4gsIR7o WfMwc7/dHAjTgzHtQjXMbWs+/2183cIhd3iIZeEbskxRgdDeELxE1ocgo3ENHYME ym+lSpEULpJt29CJFxxcFVMfAK4HTjTgBffKozInhLiHax7q2ZCdM8wNh4b3ZHxg ==
X-ME-Sender: <xms:APeKWVZFI3rkWUQNyu3GdPWo5pSAfy2_-5D-jCETmrdlHO4pTkAiSg>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id DCFFBE2273; Wed, 9 Aug 2017 07:50:23 -0400 (EDT)
Message-Id: <1502279423.1718935.1067929480.3EBFA014@webmail.messagingengine.com>
From: Neil Jenkins <neilj@fastmailteam.com>
To: IETF JMAP Mailing List <jmap@ietf.org>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_150227942317189350"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-f209590a
References: <20170808092341.GB1457@meili> <1502188117.322839.1066636392.362BFD31@webmail.messagingengine.com> <BF5DBECF-F4EC-4137-9B45-F6A777755459@neiljhaveri.com> <20170809104514.GA1412@meili>
In-Reply-To: <20170809104514.GA1412@meili>
Date: Wed, 09 Aug 2017 21:50:23 +1000
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/DIKhnXV8hGeGrgUZ0FlDU4ze6xE>
Subject: Re: [Jmap] Attachments and composing more complex MIME structures
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Aug 2017 11:50:27 -0000

On Wed, 9 Aug 2017, at 08:45 PM, Josef 'Jeff' Sipek wrote:
> 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.
Which is fine until you’re quoting something; the wrapping (normally)
doesn’t add an extra ”>“ at the beginning of each new line, so it
becomes much harder to differentiate quoted from non-quoted text. Fine
if you’re just top-posting of course…
(Of course, the FastMail client actually does convert this to a
<blockquote> for display, so the wrapping does work fine even in quotes
as long as you never add hard line breaks, but my point is that most
clients *don't* handle this well.)
Regardless though, JMAP should happily support clients that want to use
HTML and clients that want to just do plain text.
> 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.
Sorry, I perhaps should have made it clear: I don't expect this to be
ignored. I expect the server to do something sane to convert *all*
messages with the best fidelity possible to the JMAP Message format when
requested. The case of multipart mixed is actually fairly straight
forward. Suppose you have
[Text A]
[File.zip]
[Text B]

I think this should be converted to an htmlBody something like:

<div>Text A</div>
<div><br></div>
<div><a href="cid:...">File.zip</a>
<div><br></div>
<div>Text B</div>

And the textBody version very similar but without the tags.

> (Now I'm curious what the FastMail client & server code does when it
> gets one of these Apple client created emails...)
I just checked: it concatenates the text parts but doesn't insert the
mid-body links to ”attachments“ (the non-text parts are shown as
attachments to the email though of course). We handle the image case
fully though (the common case), converting this to HTML with <img> tags
in the appropriate place with a cid src so it all works.
> Actually, this makes me wonder... what should a jmap server do if the> stored message is somehow malformed?

It needs to make a best effort to represent it; I'm wary of trying to
give exact algorithms for this in the spec since there is an infinite
variety of brokenness out there and you tend to have to build up
heuristics based on the samples you see in the wild over time. Again
though, I agree the spec definitely needs to at least outline what is
expected here.
Neil.