From nobody Tue Aug 1 07:39:11 2017 Return-Path: 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 36D7D13218E for ; Tue, 1 Aug 2017 07:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 sHl1wU9agQUJ for ; Tue, 1 Aug 2017 07:39:03 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id E3FFC13218D for ; Tue, 1 Aug 2017 07:39:02 -0700 (PDT) Received: from meili (officewifi.dovecot.fi [193.209.119.110]) by mail.dovecot.fi (Postfix) with ESMTPSA id 91D342B3CC7; Tue, 1 Aug 2017 17:39:36 +0300 (EEST) Date: Tue, 1 Aug 2017 17:38:51 +0300 From: Josef 'Jeff' Sipek To: Neil Jenkins Cc: IETF JMAP Mailing List Message-ID: <20170801143851.GA1363@meili> References: <20170731134452.GB1402@meili> <1501558715.3114940.1059090760.3D266D17@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1501558715.3114940.1059090760.3D266D17@webmail.messagingengine.com> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: Re: [Jmap] message copying and moving X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 14:39:09 -0000 On Tue, Aug 01, 2017 at 13:38:35 +1000, Neil Jenkins wrote: > On Mon, 31 Jul 2017, at 11:44 PM, Josef 'Jeff' Sipek wrote: > > There appear to be three different ways in jmap mail to "copy" an email> > > from one mailbox to another. That is, duplicating a message but leaving > > the> original in place (like COPY in IMAP). They are: > > > > 1. setMessages on an existing message's messageId with destination > > mailbox's mailboxId added to mailboxIds > > Not exactly. JMAP is currently designed so it's optional for servers to > support the concept of a single message appearing in multiple mailboxes > ("labels" rather than "folders"). This is designated by the > mustBeOnlyMailbox property on the mailbox objects, but I think we should > re-evaluate this. It seems likely to be the same for every mailbox in the > account. A simpler (and better IMO) method would be to add a > maxMailboxesPerMessage property to the capabilities given for an account, > which would be 1 for simple IMAP proxies and >1 for more sophisticated > servers. I like the idea of the server presenting a property of some sort to indicate how many mailboxIds can be in the list for a message. Even servers that support label-like mailboxes likely have some upper bound. (Should null or absence mean 1? unlimited?) As far as making it a per-account capability is concerned, that seems incompatible with common Dovecot configurations where multiple storages are "grafted" into a single namespace. For example, on my server running dovecot I have two storages for my email. One to store everything but spam and one to store only spam. This is what it looks like from client's perspective: A0001 LIST "" "*" * LIST (\HasNoChildren) "/" INBOX * LIST (\HasNoChildren \UnMarked \Drafts) "/" drafts ... * LIST (\HasNoChildren \UnMarked) "/" xfs * LIST (\HasNoChildren \UnMarked) "/" zfs * LIST (\Noselect \HasChildren) "/" spam * LIST (\HasNoChildren \Marked) "/" spam/misc ... But on the server, the emails I care about use one type of storage (sdbox at "" on one filesystem) with certain performance characteristics, while the spam mails can use a different type (mdbox at "spam" on a different filesystem) with different performance characteristics. This is just one example of how dovecot admins use multiple storages within a namespace. Another common configurations include: using the "imapc" storage to graft a remote IMAP server's namespace, using mbox for INBOX while keeping the rest of the mailboxes in maildirs, etc. Because any combination of storages is allowed, there is no guarantee that all mailboxes returned by LIST/getMailboxes support the same features. I'm not really sure what this means for jmap. I suppose the easy way out would be to make the maxMailboxesPerMessage a per mailbox "capability", but that doesn't really help either - just because two mailboxes support messages with multiple locations doesn't mean that a message can be in both. To use the above two-storage setup as an example, suppose I want to copy a mail from INBOX to spam/misc. With IMAP, it'd be: A SELECT INBOX B COPY 123 spam/misc The server notices that the source of the message (INBOX) and the destination (spam/misc) are in different storages, and does a dumb copy instead of trying hardlink tricks. The client doesn't care, because it knows that the new copy of the mail will have a new UID (one that's scoped to spam/misc). With JMAP, it'd be (assuming that the mail being copied is initially only in INBOX): setMessages: { "id": "mail-to-copy-id", "update": { "x": { "mailboxIds": [ "INBOX-mbox-id", "spam/misc-mbox-id" ] } } } ... What should the server do? The options I see: 1. reject the update 2. do not copy, but somehow hide that from the client 3. make a physical copy, but somehow hide that from the client 4. make a physical copy, provide it a new messageId In a way the first option is the most tempting - we can't link the message, so let's error out and have the client try to make a real copy. But that seems silly - if these are the semantics that the client has to deal with, why not just have the server do it and save a network round-trip? The second option just doesn't work if the destination storage is something like dovecot's "imapc" (or eventually "jmapc"), since clients connecting directly to the remote wouldn't see the copied messages. I'll have to mull this over some more. I'm just thinking out loud :) ... > > 2. importMessages with blobId referencing an existing message's blobId > > 3. copyMessages with fromAccountId == toAccountId > > While not intended for this purpose, yes these could be used to copy messages. However, > > The first method creates a "hardlink" copy - any keyword changes will be > > shared by all the copies of the message. > > The second method creates a total duplicate of the message and its > > metadata. > > Looking at the spec, this needs to be clarified. However I believe we > definitely need to make it so that (2)/(3) MAY return an existing message > id if the content is the same as an existing message (or alternatively an > error; either works for me). I'm ok with MAY return existing messageId. Is there ever a time when someone may want to actually create a duplicate (IMAP COPY-style) without this sharing? This automatic collapsing of messages could lead to some annoyed users that want two copies but with different keywords. > For example, the Cyrus implementation of JMAP > uses a secure hash of the message content to generate the message id, so > you cannot have two identical messages within the same user with different > message ids. Out of curiosity, when you get a COPY or setMessages with a new mailboxId added, do you duplicate the mail itself (via a copy or a hardlink)? Or do you just update some indexes? Do you store mails all in different mailboxes? Or did you get rid of the notion and just emulate them via some index? > > When it comes to moving mails from one mailbox to another (like MOVE or > > COPY+EXPUNGE in IMAP) the situation is equally complex. The options are: > > > > 1. setMessages on an existing message's messageId with destination > > mailbox's mailboxId replacing the source mailbox's mailboxId in > > mailboxIds > > Yes, this is the expected way clients would do it. Ok. > > 2. importMessages with blobId referencing an existing message's blobId, > > followed by a setMessages on the original message but removing the > > source mailbox's mailboxId from mailboxIds > > 3. copyMessages with fromAccountId == toAccountId, followed by > > setMessages on the original message but removing the source mailbox's mailboxId from mailboxIds > > Again, what this does depends on whether the server supports multiple > copies of the same message content with different ids. > > So I think the following would help: > * Remove mustBeOnlyMailbox property from individual mailbox objects and > add a capability for maxMailboxesPerMessage instead. Add an appropriate > error for setMailboxes if you try to go over this limit. As I stated above, I'm ok with mustBeOnlyMailbox being replaced by some flavor of maxMailboxesPerMessage. > * Allow servers to return an error instead of copy/import if the message > already exists, rather than creating a duplicate with separate metadata. > (But if it does succeed, then it MUST have separate metadata, be a new > message id). Sounds good. > A lot of this depends on how much flexibility we want to give servers for > making it easier to proxy/build-on IMAP. Every extra option does make it > harder for clients. I agree 100% about extra options increasing complexity and pain. However, I don't think this is only about proxying/building-on IMAP. IMAP makes very few demands on what features the storage must provide. This no doubt helped its adoption since system administrators did not have to migrate all the users' mailboxes before exposing them via IMAP. They just needed to install an imap server daemon, and point it at the maildirs. I think this is a very valuable property. Do we want jmap to also have this property? Or do we want to relax it to some degree? The risk of not having it is making server implementers not bother to implement jmap support anytime soon and deployments not enabling it in a timely manner because of required storage migrations. (Deployments with 10's of millions of user accounts take a lot of time and effort to migrate.) > I'd be happy to forbid having two copies of the same message in the same > user if people think this is reasonable. So something like: > > * maxMailboxesPerMessage MUST be at least 10 (or greater) > * copyMessages fromAccount MUST be different to toAccount > * (import|copy)Messages MUST reject attempts to import/copy a message > whose content already exists. That sounds a bit extreme. I like that the current draft does not require any content checking. The messageId can be whatever makes sense for the server. Content hash is one reasonable value. But adding a restriction like this forces the server to maintain a hash of some sort of every mail - even if it has no intention of using it for the messageIds. > Or similar. > > On Tue, 1 Aug 2017, at 12:54 AM, Ted Lemon wrote: > > it's unlikely that the user ever wants a copy when a link is possible. > > Agreed. The current spec was designed for allowing the possibility that a > link is not possible. But maybe we can be more prescriptive about what > servers must support. See above about grafting of storages and making migration from existing storage systems painless. Thanks for all the hard work! Jeff. From nobody Tue Aug 1 13:23:26 2017 Return-Path: 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 075BD13170E for ; Tue, 1 Aug 2017 13:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SnptZ0SCP1Ui for ; Tue, 1 Aug 2017 13:23:23 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F4312778D for ; Tue, 1 Aug 2017 13:23:23 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id g35so12711609ioi.3 for ; Tue, 01 Aug 2017 13:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=OxCWBS+Gkazj56GTaj591D4YTv+ywMhYheTND9zq1V0=; b=VFcSFubdFucdO59SFZKq5dOb95mRbo0dP8/xBVqn3NFoVzTNRJOwef9v3hpOJaLPTk Rd7++TRH52gxYRS1VJIOib1UkmasQSYCEoY+KDHAUD3BcBddgNkdK/+51r5qU8xnXgT7 omoyGCiRPIOtvOHf5zX3y9OxGRXXtUaZ3bEOfspo5O63ToBK8lwUNCBBGXFSSFFE9pWa VLsWZzpX0hewrYyt3ysO4uHQMLlayIErsT40xgqUDYq35YxnCKcTUiU7d7w6O+AYbt53 AJaE7YdXg1Sc30AZXFkK1vG0kQ8mEaN+deY6EXSuZ+TShOu3SY3BM+YuXIXjhldDcN0D XpcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=OxCWBS+Gkazj56GTaj591D4YTv+ywMhYheTND9zq1V0=; b=UtS0fXW7903hnH8zcmuln2BcwSENs/uYlS5vRdaYnVQhlRmtG2/7/WXjZ1k4qWBQEt t76zXfbsLw+zU8t72fFk6F+OHPigQ+Dd0FgwyBU2E4DsZC2ek4SEuALfVO+1QE6154W1 Pwi3NiTzFACed0FanR7Mq0O/dBiPdPsFps565XIWe2Y/+POfdlUvkdhETv4Ym+AvmP+x x5n/nlJhaPi5k78pd+i2QwsNJT/S7ovmkIdGMfdmxSsykoMl/IGszILGB4PVt8F/3aua sza7wxlGA+OCO2oBI0OGXYwCSMLA3Q1sbdBP0iff2n8aDW4sFLWUjNAZvt8WaKHzzTF+ SMpw== X-Gm-Message-State: AIVw110vsuHmbz4cjJnhP9PnP4VUE7my0dLgg4/FZzrfT533ljD7p3j3 /ICrAoelLLj9T/V+CXMQpr0MkCfV6pTz X-Received: by 10.107.19.225 with SMTP id 94mr24075405iot.316.1501619002483; Tue, 01 Aug 2017 13:23:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.0.208 with HTTP; Tue, 1 Aug 2017 13:23:22 -0700 (PDT) From: vaibhav singh Date: Wed, 2 Aug 2017 01:53:22 +0530 Message-ID: To: jmap@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Jmap] S/MIME for JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Aug 2017 20:23:25 -0000 Hi, I was catching up on the recording of JMAP's meeting for IETF99, and this seems really fascinating to me. I have one straight question though; how is S/MIME going to be supported for JMAP? The JMAP mail spec seems to be silent on this, and maybe the spec needn't concern itself with S/MIME, but I would still like to get your views on S/MIME over JMAP, and the potential issues which could come up with trying to integrate S/MIME with JMAP. Thanking you, Vaibhav Singh From nobody Mon Aug 7 01:05:17 2017 Return-Path: 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 4C2FF132055 for ; Mon, 7 Aug 2017 01:05:15 -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=O/Xruz1v; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=e1sugRsU 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 G_CdxnNDXFmX for ; Mon, 7 Aug 2017 01:05:14 -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 CF08C13218D for ; Mon, 7 Aug 2017 01:05:13 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 2E04220DC7 for ; Mon, 7 Aug 2017 04:05:13 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Mon, 07 Aug 2017 04:05:13 -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=RnGS9ECr0dvPTvvnS gAG6cJtffBWFTX5vgweWFTt1D8=; b=O/Xruz1vrliO8WQngEQbHT+4EmeddBr8M KziGLNwkZTx+xqmwcnKiPOu6j0ctcZPKuHvdb8ZoSWphm/LGijMfAqaGzoape9Lz 6zn0u/+uFmI4TzPLcP2Htk5lqmnhjZuQeG3VWwh7kx5gh5INpjPrZGg+Ut+DffQZ 9b9zhcnKCZXYd1L5HFOpQCcMp9ZUvvux+yEKdWHGs546yIvPnVJZDSv/7lqmLr84 DRMVFB3uYEyuDqcJYIX5RolkgQWgFOFR4v6jn7sYwyK9BImbOTxii24ff4wZFOMU v+7hsTEMXdFOV28bYbgM7V6plhPQVvqZ2qhIkmZBwo21uHNPfKdeg== 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=RnGS9E Cr0dvPTvvnSgAG6cJtffBWFTX5vgweWFTt1D8=; b=e1sugRsUUiFsESli6S/spv 0tqHkHW7uMu+XYi8hRfLvgYG4vgXipv6e3BaeFRcmeHtGc8F+IN+fgXAQtorps9B zLCYtsnv3Y1PUUuk7RDGoyFBbRkpe7NicuqGHtaD77H6VSH3ZDQIZoYURCRXJ5/A Qh6MXtsTVXyo2Mnr9kAwax+HjE+uJ25nRwjnUcRMGiUMXyT+ElYMxpvcIrwFTGre dMRdvRFSW/Rf7mWMuOHKmlr0o1Mt1r/oLPe/0Z8v0kESF9WM+3T+N/LO+aNPOpSw k4SP9hwQFj0FJYvscz1yG7E5xC8DGk2M7TDnZnbyzz/PdRhhcf/wAjt/rcrRQ76w == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id E15B5E22C2; Mon, 7 Aug 2017 04:05:12 -0400 (EDT) Message-Id: <1502093112.3151700.1065298592.2621D0B7@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150209311231517002" X-Mailer: MessagingEngine.com Webmail Interface - ajax-91c15c11 In-Reply-To: Date: Mon, 07 Aug 2017 18:05:12 +1000 References: Archived-At: Subject: Re: [Jmap] S/MIME for JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Aug 2017 08:05:15 -0000 This is a multi-part message in MIME format. --_----------=_150209311231517002 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 2 Aug 2017, at 06:23 AM, vaibhav singh wrote: > I have one straight question though; how is S/MIME going to be > supported for JMAP? A client can fetch the raw RFC5322 message to decrypt and/or verify S/MIME; this is really the only option if the client has the private keys. If the private keys are on the server (some corporate systems sign/verify at the gateway) the server can transparently decrypt and could add a keyword to say this message has been verified. This is outside the scope of the JMAP spec itself though (any keyword(s) you added to the IANA registry can be used in either IMAP or JMAP of course). Neil. --_----------=_150209311231517002 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 2 Aug 2017, at 06:23 AM, vaibhav singh wrote:
I have one straight question though; how is S/MIME going to be supported for JMAP?

A client can fetch the raw RFC5322 message to decrypt and/or verify S/MIME; this is really the only option if the client has the private keys.

If the private keys are on the server (some corporate systems sign/verify at the gateway) the server can transparently decrypt and could add a keyword to say this message has been verified. This is outside the scope of the JMAP spec itself though (any keyword(s) you added to the IANA registry can be used in either IMAP or JMAP of course).

Neil.
--_----------=_150209311231517002-- From nobody Tue Aug 8 02:23:53 2017 Return-Path: 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 AD0B61204DA for ; Tue, 8 Aug 2017 02:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 i_odp0skW1Pq for ; Tue, 8 Aug 2017 02:23:50 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id DC8F91288B8 for ; Tue, 8 Aug 2017 02:23:49 -0700 (PDT) Received: from meili (officewifi.dovecot.fi [193.209.119.110]) by mail.dovecot.fi (Postfix) with ESMTPSA id 0CC3E2AF037 for ; Tue, 8 Aug 2017 12:24:22 +0300 (EEST) Date: Tue, 8 Aug 2017 12:23:41 +0300 From: Josef 'Jeff' Sipek To: jmap@ietf.org Message-ID: <20170808092341.GB1457@meili> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 09:23:52 -0000 Some clients (most notably iOS Mail app) often produce multipart/mixed emails with inline text and images. For example, if I compose a simple email with no formatting and insert two images in the middle: This is a [inserted image] test of [another inserted image] iOS mail. the email that gets produced has content-type multipart/mixed and there are five parts (all at the top level with no nesting): 1. text/plain with "This is a" 2. image/png with the first inserted image 3. text/plain with "test of" 4. image/png with the second inserted image 5. text/plain with "iOS mail." The image parts have inline content-disposition. The attachment API (I'm not really sure what else to call it) as it is currently described would work well for drafting what I think of as "email with a bunch of attachments at the end" (that is parts with "attachment" content disposition appended at the top-level of the MIME structure). However, I don't think the attachment API can be used to draft one of these inline-mime-image mails since setMessages: 1. assumes that the email text itself is one part (text/plain or text/html) 2. the attachment isInline property is meant only for HTML cid references Did I miss something, or does this really mean that a client like this must save drafts that are pre-composed RFC 5322 messages with all the inserted images already embedded? This breaks one of the exciting features of jmap - not having to reupload all the attachments during auto-saving of drafts. At some point on the list, Chris suggested providing a set of properties to allow the clients to easily extract important content from the email. Would it make sense to extend the setMessages call to do the reverse? That is, assemble a RFC 5322 message from a body structure specified by the client? I imagine each supplied body structure part to either specify text/plain or text/html as a property, or specify the content type and disposition along with a blob id. The current draft has something like it, but it doesn't specify the actual structure - just a list of attachment blobIds with some hints about their use (i.e., the isInline property which seems to control the content disposition, but not the placement of the part within the MIME structure). Thanks, Jeff. P.S. For what it is worth, the iOS mail app produces a totally different structure if any of the text has formatting. (OSX Mail.app seems to always produce it as well.) For example, with the same content as above, but with formatting applied to any of the text produces a multipart/alternative email with: 1. text/plain with the whole text without any images 2. multipart/related 2.1. text/html with the whole text with tags using cids to refer to the images 2.2. image/png with the first inserted image 2.3. image/png with the second inserted image From nobody Tue Aug 8 03:28:42 2017 Return-Path: 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 95BDF1321A4 for ; Tue, 8 Aug 2017 03:28:40 -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=l7RoY/rf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nSaTfv3V 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 buta0oTUtj7H for ; Tue, 8 Aug 2017 03:28:38 -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 8F2F713218C for ; Tue, 8 Aug 2017 03:28:38 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 0825720B17 for ; Tue, 8 Aug 2017 06:28:38 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Tue, 08 Aug 2017 06:28:38 -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=ZrCHDFFi974Hq6N9O atdHxckfWZw3z3Ye4qgY/BH/pE=; b=l7RoY/rfPr8cVHQBPZLiPK6OqKzhs/U/1 4K3vmgi6QLZ0UoLGWPB43ISxRAk4OsyZ6jgoHe4e/5//Y4DNfy+DcCWwWxOcYsSz jyqPj/C1yeiF7/D+W4JZQq9cGQOYfCq0322EsVnu8vBQ3Hq92SPwo141u39glRMe 9T0f0vg/RH+PhCNnG7GiQlYkZJSWCkL/nrLE08WxrBHsYPBxB6gRQyBflHdI+sb6 4vZGY0yJiONktIJU9dgJS0bSPcaNSkewhrtppnSFrOED5ZP7VAHacQ5kZ2ld/w1T VuGyzoslSZ66CkY7cCJp0Wd6Wv4AaMitaqn2j3atQPK+K4sN7dHaw== 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=ZrCHDF Fi974Hq6N9OatdHxckfWZw3z3Ye4qgY/BH/pE=; b=nSaTfv3VqXlkyBgOzpgqYn jW0S5QgqOfMG23sy4FmLAOSayoR9tajvxLAWCe9/FjfpViZu6BmGb85JS7DKfpYs unhQLAu99h+ODYBypsLFKZqvNh7AaaSNjrqCVzkahALTuzikI4CZcauZ0/06WJ+M Et9XLKaxjrD2JiKJ7RerwmgZIFLwR3ER27L2m8ouSBpdv7KEg+c5a/dEhJ7mUWyA ERuXMpuR2iCqgL6D1pT9a9dlFvyJs4T/H1J1V9LvrDephbinVuzyFdJ5jq7689cD 02DKNdJQ1Ir4r1BAFSWDFRLCYLA8orvsfOORwbwuQVy6PBV4S2Q8rzZyqodvRBgQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B941BE2383; Tue, 8 Aug 2017 06:28:37 -0400 (EDT) Message-Id: <1502188117.322839.1066636392.362BFD31@webmail.messagingengine.com> From: Neil Jenkins To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15021881173228390" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f209590a References: <20170808092341.GB1457@meili> Date: Tue, 08 Aug 2017 20:28:37 +1000 In-Reply-To: <20170808092341.GB1457@meili> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 10:28:41 -0000 This is a multi-part message in MIME format. --_----------=_15021881173228390 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Tue, 8 Aug 2017, at 07:23 PM, Josef 'Jeff' Sipek wrote: > Some clients (most notably iOS Mail app) often produce multipart/mixed> e= mails with inline text and images. 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). > However, I don't think the attachment API can be used to draft one of> th= ese inline-mime-image mails since setMessages: No, but you could produce an HTML part that's going to render the same (and be more compatible). > Did I miss something, or does this really mean that a client like this> m= ust save drafts that are pre-composed RFC 5322 messages with all the > inserted> images already embedded? If the client absolutely MUST create a multipart/mixed email like this, then yes. The intention with the Message object format is to hide the complexities of MIME, and try to remove alternative ways of representing the same things. This makes it easier for client authors, at the expense of some more complexity for server developers. > P.S. For what it is worth, the iOS mail app produces a totally > different> structure if any of the text has formatting.: > 1. text/plain with the whole text without any images > 2. multipart/related > 2.1. text/html with the whole text with tags using cids to > refer to> the images > 2.2. image/png with the first inserted image > 2.3. image/png with the second inserted image Doesn't sound like it would be difficult for it just to always generate this even when no text formatting is applied then=E2=80=A6 Neil. --_----------=_15021881173228390 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Tue, 8 Aug 2017, at 07:23 PM, Josef 'Jeff' Sipek wrote:
Some clients (most notably iOS Mail app) oft= en produce multipart/mixed
emails with inline text and images.

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

However, I don't think the attachment API can be used to d= raft one of
these inline-mime-image mails since setMessages:

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

Did I miss something, or does this really mean that a clie= nt like this
must save drafts that are pre-composed RFC 5322 messages with all the = inserted
images already embedded?

If the client absolutely MUST create a multipart/mixed email like= this, then yes. The intention with the Message object format is to hide th= e complexities of MIME, and try to remove alternative ways of representing = the same things. This makes it easier for client authors, at the expense of= some more complexity for server developers.

P.S. For what it is worth, the iOS mail app produces a tot= ally different
structure if any of the text has formatting.:
1.   text/plain with the whole text without any images
2.   multipart/related
2.1. text/html with the whole text with <img> tags using cids to= refer to
    the images
2.2. image/png with the first inserted image
2.3. image/png with the second inserted image

Doesn't sound like it would be difficult for it just to always generat= e this even when no text formatting is applied then=E2=80=A6

Neil.
--_----------=_15021881173228390-- From nobody Tue Aug 8 05:31:53 2017 Return-Path: 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 00F8413238B for ; Tue, 8 Aug 2017 05:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 fD5iWp2-8puJ for ; Tue, 8 Aug 2017 05:31:50 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id E15DA132354 for ; Tue, 8 Aug 2017 05:31:49 -0700 (PDT) Received: from meili (officewifi.dovecot.fi [193.209.119.110]) by mail.dovecot.fi (Postfix) with ESMTPSA id 44BD12AEF40 for ; Tue, 8 Aug 2017 15:32:26 +0300 (EEST) Date: Tue, 8 Aug 2017 15:31:46 +0300 From: Josef 'Jeff' Sipek To: jmap@ietf.org Message-ID: <20170808123146.GD1457@meili> References: <20170808092341.GB1457@meili> <1502188117.322839.1066636392.362BFD31@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1502188117.322839.1066636392.362BFD31@webmail.messagingengine.com> User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 12:31:52 -0000 On Tue, Aug 08, 2017 at 20:28:37 +1000, Neil Jenkins wrote: > On Tue, 8 Aug 2017, at 07:23 PM, Josef 'Jeff' Sipek wrote: > > Some clients (most notably iOS Mail app) often produce multipart/mixed> emails with inline text and images. > > 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 guessed that was the idea there. > > However, I don't think the attachment API can be used to draft one of > > these inline-mime-image mails since setMessages: > > No, but you could produce an HTML part that's going to render the same > (and be more compatible). Is there a MIME-aware client that breaks with what the iOS client generates? In theory the multipart/mixed approach should be *more* compatible than HTML, since the client doesn't have to deal with HTML on top of dealing with MIME anyway. As a mutt user that likes text/plain emails... it'd be great if these generated emails displayed nicely with non-HTML based MUAs. :) At the very least, the multipart/mixed emails render rather sanely in mutt. > > Did I miss something, or does this really mean that a client like this > > must save drafts that are pre-composed RFC 5322 messages with all the > > inserted images already embedded? > > If the client absolutely MUST create a multipart/mixed email like this, > then yes. The intention with the Message object format is to hide the > complexities of MIME, and try to remove alternative ways of representing > the same things. This makes it easier for client authors, at the expense > of some more complexity for server developers. I suppose the textBody/htmlBody approach should easily cover 80% of the use cases. The remaining 20% are possible via the importMessages call and raw email upload for now, or an extension in the future. Is the goal to make only the simplest of clients easy to implement? Where does one draw the line between simple enough to use the nice jmap interface and too complex (IOW: just implement the whole RFC 5322/MIME/etc. stack and use the blob API)? > > P.S. For what it is worth, the iOS mail app produces a totally > > different> structure if any of the text has formatting.: > > 1. text/plain with the whole text without any images > > 2. multipart/related > > 2.1. text/html with the whole text with tags using cids to > > refer to> the images > > 2.2. image/png with the first inserted image > > 2.3. image/png with the second inserted image > > Doesn't sound like it would be difficult for it just to always generate > this even when no text formatting is applied then… Agreed. Thanks, Jeff. From nobody Tue Aug 8 11:17:47 2017 Return-Path: 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 3E90D132513 for ; Tue, 8 Aug 2017 11:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=neiljhaveri-com.20150623.gappssmtp.com 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 dirUOY5r4vuZ for ; Tue, 8 Aug 2017 11:17:45 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB2DA132A92 for ; Tue, 8 Aug 2017 11:17:44 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id h68so17689543pfk.0 for ; Tue, 08 Aug 2017 11:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neiljhaveri-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+ykKPY1tCqZzaCNnVr/Ho4kTsHtehZBk6BachPImXY0=; b=UXHENGy+LrXADcRvqqMx8JJ9OKhrbrqFl2DLa/FrloCN9ZkzsGUkrgqmNvCRsk8yWu xU1pxsafLCsM7pwbX9gkt2zdxJ0SVe765gw/vj1XiwAD1PDVk8js9N+L9kG3No0S6Zlb uIiP7sSymGWJNaovAveCXStc7bqu9B3zXVrCZmpg92IpQ4wwp1R81g76jHBJcPhrszbx VfV2hj66srzjnotQlU69vvxcz16ghuldr8Y2YTDLhJi6ItcyH1js4XmeF8oPA3rlbBz0 JSCFawIbQ4GyMCM8BG+0HrliNXuRCVvz6bu1YHWi0a4I5zx3Dl+pOA7rc6X7ljzG8ulz H4SA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+ykKPY1tCqZzaCNnVr/Ho4kTsHtehZBk6BachPImXY0=; b=FDGBxWGMHxal+kUtvsuhbUneBZwoJQsT806GzS/xzjxwGo5QdodSuxbk2btlVvVn+s NOxEXmNcHBXSgc52Nti0uvBdH9guow/IfORi4bjOEeDrRbgwNYtd+vCtfvI0usDg4t3l vLwjGrdH1cW+7DT94szwhdTJ5tPBzA3SfApYAorq/k6HrTv/PezpGH3+lf6rGIJ5NgcH pqK8SNQlzjjfn+CRiVfxwwdOofDXLKfSyQWS9ibIqQk0Ww27InqTHdwnV96H06GNJQXY z1DLGuJbtzR48eQvDnWarilNtfZ8Mt9PcnMrqmxLb/nJCVw57GaLzPGXOilsZIafCbMO FcLA== X-Gm-Message-State: AHYfb5jabSWzw8L50hI56ApM+Pz+G4rzBfD8QHs9y6+I9Rh254ewD07d llnTzVMDwuuqLu2DY8hkyA== X-Received: by 10.99.51.142 with SMTP id z136mr4907018pgz.275.1502216264349; Tue, 08 Aug 2017 11:17:44 -0700 (PDT) Received: from [192.168.1.3] (ip70-190-168-77.ph.ph.cox.net. [70.190.168.77]) by smtp.gmail.com with ESMTPSA id c7sm3865729pfg.29.2017.08.08.11.17.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 08 Aug 2017 11:17:43 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Neil Jhaveri In-Reply-To: <1502188117.322839.1066636392.362BFD31@webmail.messagingengine.com> Date: Tue, 8 Aug 2017 11:17:41 -0700 Cc: jmap@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170808092341.GB1457@meili> <1502188117.322839.1066636392.362BFD31@webmail.messagingengine.com> To: Neil Jenkins X-Mailer: Apple Mail (2.3273) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Aug 2017 18:17:46 -0000 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=E2=80=99t properly handle = messages sent to an MMS bridge e-mail address if an image wasn=E2=80=99t = 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 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=E2=80=99d like to see if the API can remain as-is, and we = detail in the spec how servers should construct MIME. I=E2=80=99d 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=E2=80=99m not = sure. Does anybody know if any other major clients offer this kind of = UX? I=E2=80=99ve 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=E2=80=99t seem worth complicating matters here. Neil= From nobody Wed Aug 9 01:03:38 2017 Return-Path: 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 5847D131E08 for ; Wed, 9 Aug 2017 01:03:36 -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=jWrQAkmr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HdvM2Ys3 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 ZDFWboGBddor for ; Wed, 9 Aug 2017 01:03:33 -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 C36BB127868 for ; Wed, 9 Aug 2017 01:03:32 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 316AD21EBA for ; Wed, 9 Aug 2017 04:03:32 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 09 Aug 2017 04:03:32 -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=Z7jIqWtQ0Dp4S1D5i +9I8aDUSte6c8wMriWBfpyDUHc=; b=jWrQAkmr8oh9dsfoKrduW/IE9bkg2s1p0 o7F2VJQr9i0FFwOd8U54FHjRgF4/8YK1hv9h1Fn9+MxVJk3TT3zMcfBbZNCGtOcS mTCh66MyLK0Pbw3bPWlAyFPctZz7iekTM8/CWmwYD3ip0lhlUH75/eHlVaomXgey xLtgVJUR3efu44mmztjzX0P+ARj2MOEIum6fzgmqDTKtekQggZK0I/TyNkKidL46 fdbz5xkirqiO1dH2WAYieUHbFzdo7eF7ArBjvh+Zfxidix/ovamC8jhTjA7Cqt9S S+G5+de6/gBG7UGvWJ0eT5mnG3RynJqzpmtJTSRg5aNc2/huhEGpQ== 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=Z7jIqW tQ0Dp4S1D5i+9I8aDUSte6c8wMriWBfpyDUHc=; b=HdvM2Ys3mS9SxXcUfkSXX/ TiVqg524hE8gqmOu1JE47GiVQtx0WziR7k/jXgkj/0pXm5GaPef+vECGDE9vBJ7e E1HSGrm6X4SCMMToGp7A+q6CStzwdQIT4PrB3eLmNn/dGwEWXc2eh7FOxADGwN/i r3Pu674z2UVzmVewSinVMROhll3L+o8AyxmhOr03BagNX982eiGF+xHlFw2IUsfq LKCME6iMtBSOlB0O+a8k2mr+4FmDU8s4r98nVz7k/Ng2ZlBFc/44wazJIYuL6Xob BLv2ZgOX/hZZII3t13oitvwrtMWRZRZde8BACxUtN3MsLWwATO5MbqeJSj9c3A2g == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id D5739E223E; Wed, 9 Aug 2017 04:03:31 -0400 (EDT) Message-Id: <1502265811.1510508.1067740024.5044583F@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150226581115105082" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f209590a Date: Wed, 09 Aug 2017 18:03:31 +1000 In-Reply-To: <20170808123146.GD1457@meili> References: <20170808092341.GB1457@meili> <1502188117.322839.1066636392.362BFD31@webmail.messagingengine.com> <20170808123146.GD1457@meili> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 08:03:36 -0000 This is a multi-part message in MIME format. --_----------=_150226581115105082 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 8 Aug 2017, at 10:31 PM, Josef 'Jeff' Sipek wrote: > Is there a MIME-aware client that breaks with what the iOS client > generates? I don't know; I haven't tested this exhaustively. I know we had bugs with this multipart/mixed style at one point, since it was pretty uncommon so I wouldn't be surprised if there were bugs or lack of support elsewhere too. More importantly, plain text is deeply problematic on mobile because of hard wrapping. Format=flowed has zero traction[1], so you mostly end up with hard wrapping that breaks in *really* awkward positions on many mobile screens, as it normally presumes you can fit 80 chars in a single line. > In theory the multipart/mixed approach should be **more** compatible > than HTML, since the client doesn't have to deal with HTML on top of > dealing with MIME anyway. Maybe, but I wouldn't be surprised if the MIME handling in some clients extended only to "find the right part to show". > As a mutt user that likes text/plain emails... it'd be great if these > generated emails displayed nicely with non-HTML based MUAs. :) There's no reason why the server can't generate a reasonable textBody component as well (it will have to do this as well as htmlBody in this case anyway). I believe you could build an excellent plain-text only client on JMAP if you wanted, although realistically all modern email clients have to deal with HTML. > Is the goal to make only the simplest of clients easy to implement? > Where does one draw the line between simple enough to use the nice > jmap interface and too complex (IOW: just implement the whole RFC > 5322/MIME/etc. stack and use the blob API)? I believe you could implement the functionality of most modern GUI email clients without resorting to MIME parsing. This is basically the goal: most clients never need to deal with the raw message, but some with support for less common features can do so if they want (like for S/MIME). For example, I believe you could implement all the functionality in the iOS/macOS Mail apps using the JMAP Message object, although the implementation underneath might vary in some aspects like the one we're discussing. (Neil, do you agree?). Neil. Links: 1. https://blog.fastmail.com/2016/12/17/format-flowed/ --_----------=_150226581115105082 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 8 Aug 2017, at 10:31 PM, Josef 'Jeff' Sipek wrote:
Is there a MIME-aware client that breaks with what the iOS client generates?

I don't know; I haven't tested this exhaustively. I know we had bugs with this multipart/mixed style at one point, since it was pretty uncommon so I wouldn't be surprised if there were bugs or lack of support elsewhere too.

More importantly, plain text is deeply problematic on mobile because of hard wrapping. Format=flowed has zero traction, so you mostly end up with hard wrapping that breaks in really awkward positions on many mobile screens, as it normally presumes you can fit 80 chars in a single line.

In theory the multipart/mixed approach should be *more* compatible than HTML, since the client doesn't have to deal with HTML on top of dealing with MIME anyway.

Maybe, but I wouldn't be surprised if the MIME handling in some clients extended only to "find the right part to show".

As a mutt user that likes text/plain emails... it'd be great if these generated emails displayed nicely with non-HTML based MUAs. :)

There's no reason why the server can't generate a reasonable textBody component as well (it will have to do this as well as htmlBody in this case anyway). I believe you could build an excellent plain-text only client on JMAP if you wanted, although realistically all modern email clients have to deal with HTML.

Is the goal to make only the simplest of clients easy to implement? Where does one draw the line between simple enough to use the nice jmap interface and too complex (IOW: just implement the whole RFC 5322/MIME/etc. stack and use the blob API)?

I believe you could implement the functionality of most modern GUI email clients without resorting to MIME parsing. This is basically the goal: most clients never need to deal with the raw message, but some with support for less common features can do so if they want (like for S/MIME). For example, I believe you could implement all the functionality in the iOS/macOS Mail apps using the JMAP Message object, although the implementation underneath might vary in some aspects like the one we're discussing.  (Neil, do you agree?).

Neil.
--_----------=_150226581115105082-- From nobody Wed Aug 9 01:12:54 2017 Return-Path: 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 9F797131E08 for ; Wed, 9 Aug 2017 01:12:53 -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=WxahQYYX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PpNv//4U 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 HMCL9VkmheBG for ; Wed, 9 Aug 2017 01:12:52 -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 E3FB4127869 for ; Wed, 9 Aug 2017 01:12:51 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id DAEEB20B1F for ; Wed, 9 Aug 2017 04:12:50 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 09 Aug 2017 04:12:50 -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=BXoCO4vVlasemnenv SOGKq/XgRcEWsY6c29BHm2Mml4=; b=WxahQYYXzxOVF1J5B2VXipaWfN8C2AVrU AkmqgygxfZGUpm5NzZ3B5ejlugIwZzeMXOddGnwD8X7bLjl8cWVVjuz6jGUrThI0 lutKs4KEu4x7GRrCbSbjIGnXQJNT4R86X7VG92MBv3omGgj2EesEoqyebsAZyyx9 mEKJz7YhsmZ3N3KO0NZVAnpc2G+CH3wKW8S2YHFs1Ee0nBiVQ6RQ5qeFZPN1LV0r GUQEXKPXvxBPNVnnIBGL1D2EV/YmWMrAkR+HHj9PGVUbC1z3pxho3AtgMGAkysEJ XatPZk1gwQPB+7Qi5FLK1XfTYxjdY6BRHRtMvqJ6cqUj4Fh9JLRqg== 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=BXoCO4 vVlasemnenvSOGKq/XgRcEWsY6c29BHm2Mml4=; b=PpNv//4UsgoWadtZ9KQ1VV K+QlRWHEtINQYUS+yQc8FpVS/CAr4AgHhVTqDhpf1PVTnvdwkYZpAUqDrdtjfcJx wOEkdOKsDRG0Q0FeoAFTD5Y0BkW9v+lXkoOFHGP5dc3a3CWqOf2X6m+KZ+teGRSX 9gCelETq4/6sDy3GNoHjyke4XO+M5PPcMAfYfoiWyM3vSVTTp85yMnzrP/UijVlL ftXR482JTkkKSaefeWwuYe/99GlAMOiuwGTUqh+TCN92Xyhrt+h2jCpC45mouMa4 6rUkPg7nhurfuvymQU7EdFjToAPKB8vaZlB1FnC+pUE3peMD455xBJ03ayzLCEOw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 98E21E223E; Wed, 9 Aug 2017 04:12:50 -0400 (EDT) Message-Id: <1502266370.1509134.1067758664.41CAABFA@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150226637015091344" X-Mailer: MessagingEngine.com Webmail Interface - ajax-f209590a Date: Wed, 09 Aug 2017 18:12:50 +1000 In-Reply-To: References: <20170808092341.GB1457@meili> <1502188117.322839.1066636392.362BFD31@webmail.messagingengine.com> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 08:12:53 -0000 This is a multi-part message in MIME format. --_----------=_150226637015091344 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wed, 9 Aug 2017, at 04:17 AM, Neil Jhaveri wrote: > 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 mess= age, without> the redundancy of including both a text/html part with a text= /plain > fallback alternative part. Compactness is good, but with JMAP you can just upload the HTML part and have the server generate a plain part so you're not saving over-the-wire data on your bandwidth-constrained mobile anymore. It would really only be for the server-to-server transmission, and I doubt that it would make a significant difference. > (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=E2=80=99t properly han= dle > messages sent> to an MMS bridge e-mail address if an image wasn=E2=80=99t= a top-level > MIME part. Interesting. I wonder whether that system is still relevant today? Given other clients *don't* (usually) generate the multipart/mixed format, this would presumably be seeing a lot of issues with emails sent from e.g. Gmail. > How do other people here feel about the preference for text/plain? I believe that battle has been fought and lost. You can generate clean, minimal HTML and it's the one way to get reasonable font wrapping everywhere on mobile, including when quoting replies. > I agree, I=E2=80=99d like to see if the API can remain as-is, and we deta= il in> the spec how servers should construct MIME. I=E2=80=99d be happy to = help with> this part. That would be great. :) > There is also the uglier case of "inlined attachments" that cannot be> pr= operly referenced by HTML tags, e.g.: > [plain text] > [zip attachment] > [more plain text] >=20 > 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=E2=80= =99m not sure. I don't believe I've seen one of them in the wild. I am now curious to know what our client would make of it! > Does anybody know if any other major clients offer this kind of UX? I'm not aware of any. Neil. --_----------=_150226637015091344 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Wed, 9 Aug 2017, at 04:17 AM, Neil Jhaveri wrote:
Yeah, the Apple Mail clients have a preferen= ce to avoid sending
text/html, unless strictly necessary by the content:
(A) A philosophical preference that text/plain be used whenever possib= le,
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.

Compactness is good, but with JMAP you can just upload the HTML part a= nd have the server generate a plain part so you're not saving over-the-wire= data on your bandwidth-constrained mobile anymore. It would really only be= for the server-to-server transmission, and I doubt that it would make a si= gnificant difference.

(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,<= br>
some Japanese cell phone carriers couldn=E2=80=99t properly handle mes= sages sent
to an MMS bridge e-mail address if an image wasn=E2=80=99t a top-level= MIME part.

Interesting. I wonder whether that system is still relevant today? Giv= en other clients don't (usually) generate the multipart/mi= xed format, this would presumably be seeing a lot of issues with emails sen= t from e.g. Gmail.

How do other people here feel about the pref= erence for text/plain?

I believe that battle has been fought and lost. You can generate clean= , minimal HTML and it's the one way to get reasonable font wrapping everywh= ere on mobile, including when quoting replies.

I agree, I=E2=80=99d like to see if the API = can remain as-is, and we detail in
the spec how servers should construct MIME. I=E2=80=99d be happy to he= lp with
this part.

That would be great. :)

There is also the uglier case of "inlined at= tachments" 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=E2=80=99m not s= ure.

I don't believe I've seen one of them in the wild. I am now curious to= know what our client would make of it!

Does anybody know if any other major client= s offer this kind of UX?

I'm not aware of any.

Neil.
--_----------=_150226637015091344-- From nobody Wed Aug 9 03:27:21 2017 Return-Path: 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 7CA331320BB for ; Wed, 9 Aug 2017 03:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 Kjc6I0zdNDPV for ; Wed, 9 Aug 2017 03:27:19 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id DD1571243F3 for ; Wed, 9 Aug 2017 03:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1502274438; d=isode.com; s=june2016; i=@isode.com; bh=c6t7JaqjzzgMMxwFg+A8ola16HhC+rKD2lw8+IhHN2g=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=IuNwGp1KSDCooELnhuqk7K7VrucYhuPFGPerqWh/w8EHm+4FRzTeBPuCSF/2vTPZpZZpat eKZnVFKeyhPM8ZZF0usn5eWMBmS6CtP2JvKtXOuIuCtjK0CKbLECLnOXfpdByEglmBlXWu 42eiYdJBAwY2DxMOe0XbWShzeMac8hA=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 9 Aug 2017 11:27:17 +0100 To: Neil Jenkins , IETF JMAP Mailing List References: <20170808092341.GB1457@meili> <1502188117.322839.1066636392.362BFD31@webmail.messagingengine.com> <20170808123146.GD1457@meili> <1502265811.1510508.1067740024.5044583F@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: <9e98bcd0-d862-6566-c553-6fed80fb744c@isode.com> Date: Wed, 9 Aug 2017 11:26:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 In-Reply-To: <1502265811.1510508.1067740024.5044583F@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------E260B73E2C97A3FC24A94347" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 10:27:20 -0000 --------------E260B73E2C97A3FC24A94347 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 09/08/2017 09:03, Neil Jenkins wrote: > On Tue, 8 Aug 2017, at 10:31 PM, Josef 'Jeff' Sipek wrote: >> Is there a MIME-aware client that breaks with what the iOS client >> generates? > > I don't know; I haven't tested this exhaustively. I know we had bugs > with this multipart/mixed style at one point, since it was pretty > uncommon so I wouldn't be surprised if there were bugs or lack of > support elsewhere too. I've spent some times implementing this in our client. We had some bugs, but it works nicely now. You had to implement this if you are a MIME capable email client. > More importantly, plain text is deeply problematic on mobile because > of hard wrapping. Format=flowed has zero traction > , Let's not exaggerate. It is being used. > so you mostly end up with hard wrapping that breaks in /really/ > awkward positions on many mobile screens, as it normally presumes you > can fit 80 chars in a single line. > >> In theory the multipart/mixed approach should be **more** compatible >> than HTML, since the client doesn't have to deal with HTML on top of >> dealing with MIME anyway. > > Maybe, but I wouldn't be surprised if the MIME handling in some > clients extended only to "find the right part to show". > >> As a mutt user that likes text/plain emails... it'd be great if these >> generated emails displayed nicely with non-HTML based MUAs. :) > > There's no reason why the server can't generate a reasonable textBody > component as well (it will have to do this as well as htmlBody in this > case anyway). I believe you could build an excellent plain-text only > client on JMAP if you wanted, although realistically all modern email > clients have to deal with HTML. True. >> Is the goal to make only the simplest of clients easy to implement? >> Where does one draw the line between simple enough to use the nice >> jmap interface and too complex (IOW: just implement the whole RFC >> 5322/MIME/etc. stack and use the blob API)? > > I believe you could implement the functionality of most modern GUI > email clients without resorting to MIME parsing. This is basically the > goal: most clients never need to deal with the raw message, but some > with support for less common features can do so if they want (like for > S/MIME). For example, I believe you could implement all the > functionality in the iOS/macOS Mail apps using the JMAP Message > object, although the implementation underneath might vary in some > aspects like the one we're discussing. (Neil, do you agree?). > --------------E260B73E2C97A3FC24A94347 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 09/08/2017 09:03, Neil Jenkins wrote:

On Tue, 8 Aug 2017, at 10:31 PM, Josef 'Jeff' Sipek wrote:
Is there a MIME-aware client that breaks with what the iOS client generates?

I don't know; I haven't tested this exhaustively. I know we had bugs with this multipart/mixed style at one point, since it was pretty uncommon so I wouldn't be surprised if there were bugs or lack of support elsewhere too.
I've spent some times implementing this in our client. We had some bugs, but it works nicely now. You had to implement this if you are a MIME capable email client.

More importantly, plain text is deeply problematic on mobile because of hard wrapping. Format=3Dflowed has zero traction,
Let's not exaggerate. It is being used.

so you mostly end up with hard wrapping that breaks in really<= /i> awkward positions on many mobile screens, as it normally presumes you can fit 80 chars in a single line.

In theory the multipart/mixed approach should be *more* compatible than HTML, since the client doesn't have to deal with HTML on top of dealing with MIME anyway.

Maybe, but I wouldn't be surprised if the MIME handling in some clients extended only to "find the right part to show".

As a mutt user that likes text/plain emails... it'd be great if these generated emails displayed nicely with non-HTML based MUAs. :)

There's no reason why the server can't generate a reasonable textBody component as well (it will have to do this as well as htmlBody in this case anyway). I believe you could build an excellent plain-text only client on JMAP if you wanted, although realistically all modern email clients have to deal with HTML.

True.
Is the goal to make only the simplest of clients easy to implement? Where does one draw the line between simple enough to use the nice jmap interface and too complex (IOW: just implement the whole RFC 5322/MIME/etc. stack and use the blob API)?

I believe you could implement the functionality of most modern GUI email clients without resorting to MIME parsing. This is basically the goal: most clients never need to deal with the raw message, but some with support for less common features can do so if they want (like for S/MIME). For example, I believe you could implement all the functionality in the iOS/macOS Mail apps using the JMAP Message object, although the implementation underneath might vary in some aspects like the one we're discussing. =C2=A0(Neil, do you agree?).


--------------E260B73E2C97A3FC24A94347-- From nobody Wed Aug 9 03:45:31 2017 Return-Path: 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 7A0B3126B6D for ; Wed, 9 Aug 2017 03:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Ws9le_l_Ir2f for ; Wed, 9 Aug 2017 03:45:27 -0700 (PDT) Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 40EB112009C for ; Wed, 9 Aug 2017 03:45:27 -0700 (PDT) Received: from meili (officewifi.dovecot.fi [193.209.119.110]) by mail.dovecot.fi (Postfix) with ESMTPSA id 6BF2F284421; Wed, 9 Aug 2017 13:46:04 +0300 (EEST) Date: Wed, 9 Aug 2017 13:45:14 +0300 From: Josef 'Jeff' Sipek To: Neil Jhaveri Cc: Neil Jenkins , jmap@ietf.org Message-ID: <20170809104514.GA1412@meili> References: <20170808092341.GB1457@meili> <1502188117.322839.1066636392.362BFD31@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.8.3 (2017-05-23) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 10:45:29 -0000 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 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. From nobody Wed Aug 9 03:54:24 2017 Return-Path: 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 7E22E132125 for ; Wed, 9 Aug 2017 03:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com 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 8RAZ-OQNZU-q for ; Wed, 9 Aug 2017 03:53:58 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id DC9D2126B6D for ; Wed, 9 Aug 2017 03:53:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1502276037; d=isode.com; s=june2016; i=@isode.com; bh=xfa+7dlU5r9V4mdLfHqWO97iWBNznsOlRqYIctYdkdQ=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=SwOvhVWAJ1dXZhaKeUIlAUTd2RRGjyZtXr4nsnjx94XmhfSrCQVUVAmfTgN1qB/B/PMQFO yrp8L4yZZxUWOPlrEToxj1N4WxhlAJosY4VOKlMMcBQ4BuU0HFMo0i7AjJSnTcw4yN4t+2 U3hM+VaSTRVzHVC5Dn1R9X0qsAu53gg=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 9 Aug 2017 11:53:56 +0100 To: Neil Jenkins , jmap@ietf.org References: <1502093112.3151700.1065298592.2621D0B7@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: <28290c5e-1f4b-e877-978f-5836b3994598@isode.com> Date: Wed, 9 Aug 2017 11:53:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 In-Reply-To: <1502093112.3151700.1065298592.2621D0B7@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Jmap] S/MIME for JMAP X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 10:54:08 -0000 On 07/08/2017 09:05, Neil Jenkins wrote: > On Wed, 2 Aug 2017, at 06:23 AM, vaibhav singh wrote: >> I have one straight question though; how is S/MIME going to be >> supported for JMAP? > > A client can fetch the raw RFC5322 message to decrypt and/or verify > S/MIME; this is really the only option if the client has the private keys. Right. > If the private keys are on the server (some corporate systems > sign/verify at the gateway) the server can transparently decrypt and > could add a keyword to say this message has been verified. This is > outside the scope of the JMAP spec itself though (any keyword(s) you > added to the IANA registry can be used in either IMAP or JMAP of course). There is a similar case of webmail which can access use keys on behalf of a user. If people are interested in thinking about/experimenting with possible JMAP extensions for S/MIME for the latter case, please let me know. Best Regards, Alexey From nobody Wed Aug 9 04:50:28 2017 Return-Path: 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 ; 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 ; 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 ; 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 ; 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: 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 To: IETF JMAP Mailing List 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> <20170809104514.GA1412@meili> In-Reply-To: <20170809104514.GA1412@meili> Date: Wed, 09 Aug 2017 21:50:23 +1000 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Aug 2017 11:50:27 -0000 This is a multi-part message in MIME format. --_----------=_150227942317189350 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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=E2=80=99re quoting something; the wrapping (normall= y) doesn=E2=80=99t add an extra =E2=80=9D>=E2=80=9C at the beginning of each n= ew line, so it becomes much harder to differentiate quoted from non-quoted text. Fine if you=E2=80=99re just top-posting of course=E2=80=A6 (Of course, the FastMail client actually does convert this to a
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:
Text A

File.zip

Text B
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 =E2=80=9Dattachments=E2=80=9C (the non-text parts are sho= wn as attachments to the email though of course). We handle the image case fully though (the common case), converting this to HTML with 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> st= ored 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. --_----------=_150227942317189350 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
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 re= ally long line.

Which is fine until you=E2=80=99re quoting something; the wrapping (no= rmally) doesn=E2=80=99t add an extra =E2=80=9D>=E2=80=9C at the beginnin= g of each new line, so it becomes much harder to differentiate quoted from = non-quoted text. Fine if you=E2=80=99re just top-posting of course=E2=80=A6=

(Of course, the FastMail client actually does convert this to a <bl= ockquote> 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&n= bsp;don't handle this well.)

Regardless though, JMAP should happily support clients that want to us= e HTML and clients that want to just do plain text.

I'm not sure we can totally ignore this.&nbs= p; Even if Apple clients stop generating these messages today, there are ye= ars 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=3D"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 &a= mp; 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 =E2=80=9Dattachments=E2=80=9C (the non-text parts are sho= wn as attachments to the email though of course). We handle the image case = fully though (the common case), converting this to HTML with <img> ta= gs in the appropriate place with a cid src so it all works.

Actually, this makes me wonder... what shoul= d 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 varie= ty of brokenness out there and you tend to have to build up heuristics base= d on the samples you see in the wild over time. Again though, I agree the s= pec definitely needs to at least outline what is expected here.

Neil.
--_----------=_150227942317189350-- From nobody Thu Aug 10 18:28:06 2017 Return-Path: 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 95753131C9E for ; Thu, 10 Aug 2017 18:28:05 -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=LNtnqy/Z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fCzoDw74 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 27vB9AJCjsoG for ; Thu, 10 Aug 2017 18:28:02 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 094AE129AD3 for ; Thu, 10 Aug 2017 18:28:01 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 6FAC02078B for ; Thu, 10 Aug 2017 21:28:01 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 10 Aug 2017 21:28:01 -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=8VMh93oKfAzljTGJE RpW2Ujn8eliDY3x5poRaTkzvFQ=; b=LNtnqy/ZEhjQccj+dxp9G0paMA3/QwBv3 +XJCp/0nOSb3S1LgzvLEwA9v5G3XLKkSEgWsynzLBNEFegaR5oP6P989cBHfaZ+o b6rkeZZtG9KKyhT5/5W2HzhbGhq6XAnahtnTzUJhBd53yflW/Lltx1giGaHvlDmt poRmGNgWUEphGs/VRNtdCk2MYmImQeGBpWg33QbWehTW8fmkks/FfYST5ULO62Sj 4wepJoXxLvNTH1CobRqJ+BcwJd8P6TfGsW3ZkIkDsTK0nh+LbsxhfYvQpBLIgRwL 5GWqw9+Lpe4xJgfr6oUu3WWyIg13MFceXMu+b94CS5haVsXOl0tAg== 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=8VMh93 oKfAzljTGJERpW2Ujn8eliDY3x5poRaTkzvFQ=; b=fCzoDw74x14eLqAZ7pmeWh wJJtvW0lC82xbsTIBS0n9SYYf4c5Dn7dR9uRbAPP+ekOf7igEescYTGTcdG8c3U5 7wgSP3BUOKh0B4Mu2+xzBeKqEtj2retBEqrkJy1o/b2w1kuPEg/AIwTwiOe+qxR8 5c3EfDujfKP5rq4Tl5dbeoNL9m+HLmdpFueTLazvo8ExCm9X8PcJDVo2BcaShSmP Puv5ugM2/f/LoFyZxi6obIRXVYuiwjr/g0py0Ye47hn12tEUIkTbMufNnhjniX6F DDmnvEwXOW0mTsS9jLZko9CR1GlXk6S2//vOAeoenrSKOyjAp9Ld/+3znGtalHNw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 1AF4FE22BE; Thu, 10 Aug 2017 21:28:01 -0400 (EDT) Message-Id: <1502414880.3740198.1069884864.56CC4ABF@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150241488137401981" X-Mailer: MessagingEngine.com Webmail Interface - ajax-96f0d108 References: <20170731134452.GB1402@meili> <1501558715.3114940.1059090760.3D266D17@webmail.messagingengine.com> <20170801143851.GA1363@meili> Date: Fri, 11 Aug 2017 11:28:00 +1000 In-Reply-To: <20170801143851.GA1363@meili> Archived-At: Subject: Re: [Jmap] message copying and moving X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 01:28:06 -0000 This is a multi-part message in MIME format. --_----------=_150241488137401981 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" On Wed, 2 Aug 2017, at 12:38 AM, Josef 'Jeff' Sipek wrote: > I like the idea of the server presenting a property of some sort to > indicate how many mailboxIds can be in the list for a message. Even > servers that support label-like mailboxes likely have some upper > bound. (Should null or absence mean 1? unlimited?) I would say null =3D=3D "unlimited" (which of course is limited by the number of mailboxes you have in the account). I've created https://github.com/jmapio/jmap/issues/135 regarding this issue. > As far as making it a per-account capability is concerned, that > seemsincompatible with common Dovecot configurations where multiple > storages are "grafted" into a single namespace. You can split the storage of data within a JMAP account, but you'll probably need a single index to fulfil the requirements for an account, such as moving a message atomically between mailboxes, having threads span messages across all mailboxes within the account, a unique id space etc. Looking at the Dovecot docs, it seems your dbox format already supports something like this (Alternate storage[1]) for storing the actual data referenced by an index at different mount points. (We do something very similar with Cyrus at FastMail to keep newer email on SSD and older archives on spinning rust.) This is invisible to clients. If you can't guarantee the properties required for an account for your different mailboxes, then they have to be exposed as different accounts. Methods that operate between accounts (e.g. copyMessages) don't have the same constraints. A client can still choose to show them together of course. > To use the above two-storage setup as an example, suppose I want to > copy a mail from INBOX to spam/misc.>=20 > With IMAP, it'd be: >=20 > A SELECT INBOX > B COPY 123 spam/misc >=20 > The server notices that the source of the message (INBOX) and the > destination (spam/misc) are in different storages, and does a dumb > copy instead of trying hardlink tricks. The client doesn't care, > because it knows that the new copy of the mail will have a new UID > (one that's scoped to spam/misc). So this is a clear case where they need to be different accounts, and so the client can only use copyMessages to move from one to the other, not setMessages. The semantics are then very similar to IMAP. > Is there ever a time when someone may want to actually create a > duplicate (IMAP COPY-style) without this sharing? This automatic > collapsing of messages could lead to some annoyed users that want two > copies but with different keywords. While I don't doubt there are some people that might want this, based on the feedback we see, the vast majority of users would be happy to only ever have a single shared copy that can exist in multiple locations. With JMAP as currently defined, the server is free to support either (as mentioned, we've decided with Cyrus to not allow this). >> For example, the Cyrus implementation of JMAP >> uses a secure hash of the message content to generate the >> message id, so>> you cannot have two identical messages within the same = user with >> different>> message ids. >=20 > Out of curiosity, when you get a COPY or setMessages with a new > mailboxId added, do you duplicate the mail itself (via a copy or a > hardlink)? Yes, because this was the easiest coming from the IMAP world where each mailbox was completely separate, and there was no concept of a "user". If I were to build a new server from scratch (and we have thought about this a lot=E2=80=A6) I wouldn't do this though; I'd just have= a blob store of immutable objects and a per-account index, and would just update the index. So to get from IMAP to JMAP with Cyrus we basically did: * Use secure hash of message content as message id. * JMAP mailboxes =3D set of mailboxes in which that message id exists. * When applying keywords with JMAP, we apply to every copy. * When reading keywords with JMAP, you get the union of keywords on all copies. >> Looking at the spec, this needs to be clarified. However I believe we>> = definitely need to make it so that (2)/(3) MAY return an existing >> message>> id if the content is the same as an existing message (or >> alternatively an>> error; either works for me). >=20 > I'm ok with MAY return existing messageId. > =E2=80=A6 >> * Allow servers to return an error instead of copy/import if the >> message already exists, rather than creating a duplicate with >> separate metadata. (But if it does succeed, then it MUST have >> separate metadata, be a newmessage id).> Sounds good. OK, so as you noted we shouldn't *require* the server to anything special because that would force it to compare content hash and there's no real need for this. So I think the options are: * *May* reject (error includes existing id) if content already exists. But if succeeds guaranteed to be separate copy with separate id/keywords/mailboxes. * *May* return existing id if content already exists (and applies keywords/mailboxes like setMailboxes to the existing copy). We need to pick one! I've created https://github.com/jmapio/jmap/issues/134. I think probably the first option, but don't feel too strongly either way. > IMAP makes very few demands on what features the storage must provide. > This no doubt helped its adoption since system administrators did not > have to migrate all the users' mailboxes before exposing them via > IMAP. They just needed to install an imap server daemon, and point it > at the maildirs. I think this is a very valuable property.>=20 > Do we want jmap to also have this property? Or do we want to relax it > to some degree? I think this has to be relaxed somewhat. I presume you could reasonably easily migrate servers from mbox to mdbox right? I would have thought sysops wouldn't care too much if you required them to migrate, as long as the migration was easy and handled (mostly) automatically on upgrade. Cheers, Neil. Links: 1. https://wiki2.dovecot.org/MailboxFormat/dbox#Alternate_storage --_----------=_150241488137401981 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
On Wed, 2 Aug 2017, at 12:38 AM, Josef 'Jeff' Sipek wrote:
I like the idea of the server presenting a p= roperty of some sort to indicate how many mailboxIds can be in the list for= a message.  Even servers that support label-like mailboxes likely hav= e some upper bound.  (Should null or absence mean 1?  unlimited?)=

I would say null =3D=3D "unlimited" (which of course is limited by the= number of mailboxes you have in the account). I've created https://github.com/jmapio/jmap/= issues/135 regarding this issue.

As far as making it a per-account capability= is concerned, that seemsincompatible with common Dovecot configurations wh= ere multiple storages are "grafted" into a single namespace.

You can split the storage of data within a JMAP account, but you'll pr= obably need a single index to fulfil the requirements for an account, such = as moving a message atomically between mailboxes, having threads span messa= ges across all mailboxes within the account, a unique id space etc. Looking= at the Dovecot docs, it seems your dbox format already supports something = like this (Alternate storage) for storing the actual data referenced by= an index at different mount points. (We do something very similar with Cyr= us at FastMail to keep newer email on SSD and older archives on spinning ru= st.) This is invisible to clients.

If you can't guarantee the properties required for an account for your= different mailboxes, then they have to be exposed as different accounts. M= ethods that operate between accounts (e.g. copyMessages) don't have the sam= e constraints. A client can still choose to show them together of cour= se.

To use the above two-storage setup as an exa= mple, suppose I want to copy a mail from INBOX to spam/misc.

With IMAP, it'd be:

A SELECT INBOX
B COPY 123 spam/misc

The server notices that the source of the message (INBOX) and the dest= ination (spam/misc) are in different storages, and does a dumb copy instead= of trying hardlink tricks.  The client doesn't care, because it knows= that the new copy of the mail will have a new UID (one that's scoped to sp= am/misc).

So this is a clear case where they need to be different accounts, and = so the client can only use copyMessages to move from one to the other, not = setMessages. The semantics are then very similar to IMAP.

Is there ever a time when someone may want t= o actually create a duplicate (IMAP COPY-style) without this sharing? = This automatic collapsing of messages could lead to some annoyed users tha= t want two copies but with different keywords.

While I don't doubt there are some people that might want this, based = on the feedback we see, the vast majority of users would be happy to only e= ver have a single shared copy that can exist in multiple locations. With JM= AP as currently defined, the server is free to support either (as mentioned= , we've decided with Cyrus to not allow this).

For example, the Cyrus implement= ation of JMAP
uses a secure hash of the message content to generate the message id, = so
you cannot have two identical messages within the same user with diffe= rent
message ids.

Out of curiosity, when you get a COPY or setMessages with a new mailbo= xId added, do you duplicate the mail itself (via a copy or a hardlink)?
=

Yes, because this was the easiest coming from the IMAP world where eac= h mailbox was completely separate, and there was no concept of a "user". If= I were to build a new server from scratch (and we have thought about this = a lot=E2=80=A6) I wouldn't do this though; I'd just have a blob store of im= mutable objects and a per-account index, and would just update the index.

So to get from IMAP to JMAP with Cyrus we basically did:
  • Use secure hash of message content as message id.
  • JMAP = mailboxes =3D set of mailboxes in which that message id exists.
    • When applying keywords with JMAP, we apply to every copy.
  • When= reading keywords with JMAP, you get the union of keywords on all copies.

Looking at the spec, this needs to be clarifie= d. However I believe we
definitely need to make it so that (2)/(3) MAY return an existing mess= age
id if the content is the same as an existing message (or alternatively= an
error; either works for me).

I'm ok with MAY return existing messageId.
=E2=80=A6
* Allow servers to return an error instead of copy/import = if the message already exists, rather than creating a duplicate with separa= te metadata. (But if it does succeed, then it MUST have separate metadata, = be a newmessage id).
Sounds good.

OK, so as you noted we shouldn't require the server to anything= special because that would force it to compare content hash and there's n= o real need for this. So I think the options are:
  • May reject (error includes existing id) if content already e= xists. But if succeeds guaranteed to be separate copy with separate id/keyw= ords/mailboxes.
  • May return existing id if content alrea= dy exists (and applies keywords/mailboxes like setMailboxes to the existing= copy).

We need to pick one! I've created https://github.com/jmapio/jmap/issues/134. = I think probably the first option, but don't feel too strongly either way.<= br>

IMAP makes very few demands on what features= the storage must provide. This no doubt helped its adoption since system a= dministrators did not have to migrate all the users' mailboxes before expos= ing them via IMAP.  They just needed to install an imap server daemon,= and point it at the maildirs. I think this is a very valuable property.

Do we want jmap to also have this property?  Or do we want to rel= ax it to some degree?

I think this has to be relaxed somewhat. I presume you could reasonabl= y easily migrate servers from mbox to mdbox right? I would have thought sys= ops wouldn't care too much if you required them to migrate, as long as the = migration was easy and handled (mostly) automatically on upgrade.

Cheers,
Neil.
--_----------=_150241488137401981-- From nobody Thu Aug 10 21:54:20 2017 Return-Path: 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 72626131D9F for ; Thu, 10 Aug 2017 21:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 WP094iqBIBvj for ; Thu, 10 Aug 2017 21:54:16 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F53132478 for ; Thu, 10 Aug 2017 21:54:16 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id m34so22365884iti.1 for ; Thu, 10 Aug 2017 21:54:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=4WRhLPI3GTGgKl5wsipSqTNc3aV1cz9FhA0U/3h1Ogw=; b=VPYvsQKt6/kSrO5Pp4c4WHGZ1ut1hrFWTfkujjlYzYzR+X7pH3BISNoIGOCp9q8TIL vVv9Nv82K7f642KOnekYJHWk0eWxGnY5S1geHty0QbiFhf35Kc8+QBgA6PyNR3trPwpG aWkP2CZZDI5YhrNqOKeUhl7c550YpbcqvI/R3v/EEuOny1AzirvXAqIfbvjdH259LDvo 8+1cAyt9nOC1jcXk2wknXt27fD9+R5pywPl+xnwJDuIAYku6LJHYsXnuXNica04CEmze ODeFMtXNwY+ARBBwiZ4LdUmiVJj55KmnnvnBJ7OPq+Gsuzxm+8sO8TsnyMSLqK9m6mNR mgMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=4WRhLPI3GTGgKl5wsipSqTNc3aV1cz9FhA0U/3h1Ogw=; b=YLSPZxhZhW8LOUcDlH5sy/e92CZ9j14Zd/QSAsyMY+98LZt2cjrGFyKCW5I6x+eNhp KAVSiW3zlRlhm9zqKAyH8838ZNXMG12PNpLWsdlxKN8819RMgJJ08/ISKewNhSkLBp2J atedTZNEq3oXzbRqMOlrWkFVRExYw5Z4ZGOW/IqWtdgGD8I21u0/bNIfPABKnmt39MAu E4ylov3ok8DnPoTing2yjKPvCe7HJC/Tdd6K+iBjRZrazuLuKGcoCq7sBVyjGH8kZADG xa1f9b4KJNdzZ8F3O1m6ym4nviovoBAQawipqRmzi627BIBMS1GENSbfKj5i6Dz/hV2M d0IA== X-Gm-Message-State: AHYfb5hJ+Crsktx5algpUzJLHjZ1Zg11ZkF6zZII9G31PBI+94/basiN OjdupIHHQjQMhXhKq2ycAWKfJUbJUw== X-Received: by 10.36.54.77 with SMTP id l74mr11989915itl.148.1502427255556; Thu, 10 Aug 2017 21:54:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.0.208 with HTTP; Thu, 10 Aug 2017 21:54:14 -0700 (PDT) In-Reply-To: References: From: vaibhav singh Date: Fri, 11 Aug 2017 10:24:14 +0530 Message-ID: To: jmap@ietf.org Content-Type: multipart/alternative; boundary="001a1144d62cde51b80556731a4a" Archived-At: Subject: Re: [Jmap] Jmap Digest, Vol 9, Issue 6 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 04:54:18 -0000 --001a1144d62cde51b80556731a4a Content-Type: text/plain; charset="UTF-8" On Thu, Aug 10, 2017 at 12:30 AM, wrote: > > > > ---------- Forwarded message ---------- > From: Alexey Melnikov > To: Neil Jenkins , jmap@ietf.org > Cc: > Bcc: > Date: Wed, 9 Aug 2017 11:53:38 +0100 > Subject: Re: [Jmap] S/MIME for JMAP > On 07/08/2017 09:05, Neil Jenkins wrote: > > On Wed, 2 Aug 2017, at 06:23 AM, vaibhav singh wrote: >> >>> I have one straight question though; how is S/MIME going to be supported >>> for JMAP? >>> >> >> A client can fetch the raw RFC5322 message to decrypt and/or verify >> S/MIME; this is really the only option if the client has the private keys. >> > > Right. > > If the private keys are on the server (some corporate systems sign/verify >> at the gateway) the server can transparently decrypt and could add a >> keyword to say this message has been verified. This is outside the scope of >> the JMAP spec itself though (any keyword(s) you added to the IANA registry >> can be used in either IMAP or JMAP of course). >> > > There is a similar case of webmail which can access use keys on behalf of > a user. > > If people are interested in thinking about/experimenting with possible > JMAP extensions for S/MIME for the latter case, please let me know. > +1 -Vaibhav > > Best Regards, > Alexey > > > > --001a1144d62cde51b80556731a4a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Aug 10, 2017 at 12:30 AM, <jmap-request@ietf.org><= /span> wrote:



---------- Forwarded message ----------
From:=C2=A0Alexey Melnik= ov <alexey.melnikov@isode.c= om>
To:=C2=A0Neil Jenkins <neilj@fastmailteam.com>, jma= p@ietf.org
Cc:=C2=A0
Bcc:=C2=A0
Date:=C2=A0Wed, 9 Aug 2017 11:= 53:38 +0100
Subject:=C2=A0Re: [Jmap] S/MIME for JMAP
On 07/08/2017 09= :05, Neil Jenkins wrote:

On Wed, 2 Aug 2017, at 06:23 AM, vaibhav singh wrote:
I have one straight question though; how is S/MIME going to be supported fo= r JMAP?

A client can fetch the raw RFC5322 message to decrypt and/or verify S/MIME;= this is really the only option if the client has the private keys.

Right.

If the private keys are on the server (some corporate systems sign/verify a= t the gateway) the server can transparently decrypt and could add a keyword= to say this message has been verified. This is outside the scope of the JM= AP spec itself though (any keyword(s) you added to the IANA registry can be= used in either IMAP or JMAP of course).

There is a similar case of webmail which can access use keys on behalf of a= user.

If people are interested in thinking about/experimenting with possible JMAP= extensions for S/MIME for the latter case, please let me know.

+1

-Vaibhav

Best Regards,
Alexey




--001a1144d62cde51b80556731a4a-- From nobody Thu Aug 10 22:27:07 2017 Return-Path: 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 BBFFA1323BE for ; Thu, 10 Aug 2017 22:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forestfield.org 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 aH3-YHLITnwl for ; Thu, 10 Aug 2017 22:27:05 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCA1131CF2 for ; Thu, 10 Aug 2017 22:27:05 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 81DBEA004B16 for ; Thu, 10 Aug 2017 22:27:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=forestfield.org; h=subject :to:references:from:reply-to:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= forestfield.org; bh=IiZSVOxCoOfKNut1TTnGQUZI/CE=; b=H6hEO1sj5J6A rEYBOmWexVwfZVQVVqZVQcP7P3e7Cbj3VzXNOy3AOW92g/0Dwu/LtQxNLrHakbFX XPZRl4GgCWy4mmX15EifXoCeT7q8/Ja15f3QTALcWqc8QOQ+JVYBCkQq6D0MMhaG FTH13Pl+RtCOSGfL3I5HUtdP4iKK7sA= Received: from [10.15.0.8] (unknown [173.44.37.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jbn@forestfield.org) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 3C676A004B13 for ; Thu, 10 Aug 2017 22:27:04 -0700 (PDT) To: jmap@ietf.org References: <20170731134452.GB1402@meili> <27EB9EDE-A81C-4640-9F02-F76850002221@fugue.com> From: "J.B. Nicholson" Reply-To: jmap@ietf.org Message-ID: Date: Fri, 11 Aug 2017 00:27:03 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <27EB9EDE-A81C-4640-9F02-F76850002221@fugue.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] message copying and moving X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 05:27:07 -0000 Ted Lemon wrote: > I think this is right, and is the right way to document it. Default > behavior on the client should be link=E2=80=94it's unlikely that the us= er ever > wants a copy when a link is possible. The only use case for copy is > when the mail client is showing two mail stores on separate servers, or > in the rare case where the user _wants_ two copies that are treated > differently. (I'm curious if there is general agreement on this or if > folks think I'm crazy, though!) I could be misreading or misunderstanding what you've written but I think= I=20 don't agree because I can't remember the last time I used an MUA that let= =20 me choose to link an email via the MUA's UI. I also cannot recall when I would have wanted a link as a default choice=20 while, say, dragging and dropping an email from one folder to another. I=20 would think the default behavior on GUI MUAs would be moving or copying=20 with the other option available via holding down a dead key. I also think moving and copying are far more straightforward and familiar= =20 actions to non-technical users. Hence, I think linking functionality is interesting but unlikely to be us= ed=20 much in practice. Therefore I believe copying and moving should be clear = in=20 the protocol. I do understand the attraction for mail server implementers and sysadmins= =20 to want to use linking as much as possible to save storage space. From nobody Thu Aug 10 22:31:44 2017 Return-Path: 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 0239B1324EC for ; Thu, 10 Aug 2017 22:31:43 -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=sRPQuyYA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Vz+K9E46 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 uKtgfCk4o_R3 for ; Thu, 10 Aug 2017 22:31:41 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49ABF1324E6 for ; Thu, 10 Aug 2017 22:31:41 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id BC0B3209ED for ; Fri, 11 Aug 2017 01:31:40 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Fri, 11 Aug 2017 01:31:40 -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=fsXZY55mMTmsZMROc PuT60uE2W4CE5UUvfsHpGEgWhc=; b=sRPQuyYAHRimHXTfhT2bcVuRwddi7e1IJ dEQn6gXRXurSrUYiSHFFveM6NcMj3YLkjDOOPPsEnDXRn3yix/09nmQ08c0CV6m6 mjeMdyljSpxgNAw5nXavSjhX7M66N13SL1/GZOClU5G7yw4jNnIa62ybu2wAuHWo oA48G0H+ZdFqByH4HgGuCAC5WdW93g3v2fAaeJan0ioGl9e/C9ob+ykOiu8QnYg6 PLThW0vCmbhnSoNQWcp5fTJ2Isb03K5TELByG+piFsslKC5a7EdMJBEoWgiuqmyX ccIS4pfECU9sTlQvwnTigbddeo7NGl3A+IilrJL4unRgGBoelVksQ== 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=fsXZY5 5mMTmsZMROcPuT60uE2W4CE5UUvfsHpGEgWhc=; b=Vz+K9E46MpHnGAduLA+vGk SsAw6JEvcg1SOoSfvXILuPh50zkRRhw+BQlw3VLaeQbdayXHdzBCdb94JlTIMnAb BOcZLT2T1BNEwPtVkcmbUsLEA5LPRwp2c/U+qihDdRvauIigdfxhg5rbxRF3lgfl gPO0vp2ktk+Cf7sN9uMm8s//sREdt7XfbKLksMHXGTKk5MKy1M4bmQOhNK2bqFrT OuZuCCBHEht4rw6/jyw1YeeJ8SeirGxcou93c3DbGjuhVRRe01ftj/3rHhq14OCS 9yhAAqEp74uLMJdeLzwt64RK2a07971C6tQ7VsezTBU/QS6KcYLqUPxN+1FxaUpA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 73B41E22BE; Fri, 11 Aug 2017 01:31:40 -0400 (EDT) Message-Id: <1502429500.3977925.1070026832.7BEADB2E@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150242950039779250" X-Mailer: MessagingEngine.com Webmail Interface - ajax-96f0d108 In-Reply-To: References: <20170731134452.GB1402@meili> <27EB9EDE-A81C-4640-9F02-F76850002221@fugue.com> Date: Fri, 11 Aug 2017 15:31:40 +1000 Archived-At: Subject: Re: [Jmap] message copying and moving X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 05:31:43 -0000 This is a multi-part message in MIME format. --_----------=_150242950039779250 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Fri, 11 Aug 2017, at 03:27 PM, J.B. Nicholson wrote: > I also think moving and copying are far more straightforward and > familiar actions to non-technical users. I think you're misunderstanding; the MUA can still present move/copy options. Moving is removing one mailbox while adding another to the mailboxIds property of the message. Copying is adding without removing (so you have multiple mailboxes in the mailboxIds list). Because the copies are presented with a single id in the API, the MUA can also expose this as "labels", but it doesn't have to. Regards, Neil. --_----------=_150242950039779250 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Fri, 11 Aug 2017, at 03:27 PM, J.B. Nicholson wrote:
I also think moving and copying are far more straightforward and familiar actions to non-technical users.

I think you're misunderstanding; the MUA can still present move/copy options. Moving is removing one mailbox while adding another to the mailboxIds property of the message. Copying is adding without removing (so you have multiple mailboxes in the mailboxIds list). Because the copies are presented with a single id in the API, the MUA can also expose this as "labels", but it doesn't have to.

Regards,
Neil.
--_----------=_150242950039779250-- From nobody Fri Aug 11 05:37:48 2017 Return-Path: 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 72415131D24 for ; Fri, 11 Aug 2017 05:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 WfVWQOT_C3Jd for ; Fri, 11 Aug 2017 05:37:44 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33F1813213F for ; Fri, 11 Aug 2017 05:37:44 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id l64so15019997pge.5 for ; Fri, 11 Aug 2017 05:37:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=y/SxJ6aYtgfJ02nfS0BDO/OegDp5XY5xcZgZZWnWUNE=; b=TOhLD4adhj+ifGRzdf5fA4deGeb3TThCWoelZh1pXD6Qos5l/wpD/LCVcGm999hMlj ej/AUsKXCBp5o66GK4BmYn/yk44t8XyuprVZuYapjaRiOlOmBKgQbea7rA2iIwnnLRvQ R9sJGJTE3kCjhq0C0AdcSz4o6JbnYAOfy3qV5TL47kAzArv/F07e5z90EPneC8VEHJw4 /5FN51SkFRgRiZCpFbXNQR9PNyTTeOVbN58xoKALkQQ+PYEcevBcdk5qGn9M8H0g3U1g VoWm2UKPpFF+eHPiv0uSS7+6EbOQ68OLHmAhsxlL0W2J9qZDeEDWYxDPAYClMRGLpNV8 8SCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=y/SxJ6aYtgfJ02nfS0BDO/OegDp5XY5xcZgZZWnWUNE=; b=W1rOr3hB6L4drIHo7Q9JtFT1XjOSbqS4rMnGnKMqay0qOiJ59CZiDOjnFLEWY9vyEF DvK7EF/fEDxMU2JdT14cguoEuIDP/tlAFqgE79hwb7vQkr803sGnjliMQYZKP4MLacmm p3CIAy+W24b3Zq0lMUmEfy4/uMJFIIZnM8hwYoXGD8DX506voBBhypx86RFpRtiiY3e/ kkWGK/beHgWHRgwixk/wxHSwf6ESFtiIhmJMo5pjoFuQaGTdLjpBp38PbQykqG38XA6s 1pO47oJrdKueFMiLo9kOj6IOMoD+aURby8WXjyDHnuSGZsQl/hbTKdvpE1OwpuVvpOBf 0oOQ== X-Gm-Message-State: AHYfb5jYRQE3iJyb4QtcvNxs/L03mOg4waC5n530p9liog1aip/9uBWJ u7rZM0Fy+9ENlymUozHDwVHodDMYPdxP X-Received: by 10.84.215.210 with SMTP id g18mr17808863plj.210.1502455063699; Fri, 11 Aug 2017 05:37:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.180.131 with HTTP; Fri, 11 Aug 2017 05:37:43 -0700 (PDT) Received: by 10.100.180.131 with HTTP; Fri, 11 Aug 2017 05:37:43 -0700 (PDT) In-Reply-To: <1502429500.3977925.1070026832.7BEADB2E@webmail.messagingengine.com> References: <20170731134452.GB1402@meili> <27EB9EDE-A81C-4640-9F02-F76850002221@fugue.com> <1502429500.3977925.1070026832.7BEADB2E@webmail.messagingengine.com> From: Ted Lemon Date: Fri, 11 Aug 2017 08:37:43 -0400 Message-ID: To: Neil Jenkins Cc: IETF JMAP Mailing List Content-Type: multipart/alternative; boundary="94eb2c19f1425cf159055679949a" Archived-At: Subject: Re: [Jmap] message copying and moving X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Aug 2017 12:37:46 -0000 --94eb2c19f1425cf159055679949a Content-Type: text/plain; charset="UTF-8" Right. My point was simply that the case where the end user wants two distinct copies of a message which can have independent state is more unusual than the case where the end user wants a single message to appear in two places, which at present is also somewhat unusual. There are a lot of potential applications for the latter. I can't think of any important applications for the former. On Aug 11, 2017 1:31 AM, "Neil Jenkins" wrote: > On Fri, 11 Aug 2017, at 03:27 PM, J.B. Nicholson wrote: > > I also think moving and copying are far more straightforward and familiar > actions to non-technical users. > > > I think you're misunderstanding; the MUA can still present move/copy > options. Moving is removing one mailbox while adding another to the > mailboxIds property of the message. Copying is adding without removing (so > you have multiple mailboxes in the mailboxIds list). Because the copies are > presented with a single id in the API, the MUA can also expose this as > "labels", but it doesn't have to. > > Regards, > Neil. > > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap > > --94eb2c19f1425cf159055679949a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Right. My point was simply that the case where the end us= er wants two distinct copies of a message which can have independent state = is more unusual than the case where the end user wants a single message to = appear in two places, which at present is also somewhat unusual. There are = a lot of potential applications for the latter. I can't think of any im= portant applications for the former.=C2=A0
=
On Aug 11, 2017 1:31 AM, "Neil Jenkins&= quot; <neilj@fastmailteam.com<= /a>> wrote:
On Fri, 11 Aug 2017, at 03:27 PM, J.B. Nicholson wrote:
I also think moving and copying are far more= straightforward and familiar actions to non-technical users.

I think you're misunderstanding; the MUA can still present move/co= py options. Moving is removing one mailbox while adding another to the mail= boxIds property of the message. Copying is adding without removing (so you = have multiple mailboxes in the mailboxIds list). Because the copies are pre= sented with a single id in the API, the MUA can also expose this as "l= abels", but it doesn't have to.

Regards,
Neil.

_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap

--94eb2c19f1425cf159055679949a-- From nobody Mon Aug 14 18:36:40 2017 Return-Path: X-Original-To: jmap@ietf.org Delivered-To: jmap@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FF71126B7E; Mon, 14 Aug 2017 18:36:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: jmap@ietf.org, brong@fastmailteam.com, jmap-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150276099923.21061.13043232639826420017.idtracker@ietfa.amsl.com> Date: Mon, 14 Aug 2017 18:36:39 -0700 Archived-At: Subject: [Jmap] jmap - New Meeting Session Request for IETF 100 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 01:36:39 -0000 A new meeting session request has just been submitted by Bron Gondwana, a Chair of the jmap working group. --------------------------------------------------------- Working Group Name: JSON Mail Access Protocol Area Name: Applications and Real-Time Area Session Requester: Bron Gondwana Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: dispatch Second Priority: httpbis Third Priority: dmarc People who must be present: Barry Leiba Alexey Melnikov Bron Gondwana Resources Requested: Flipcharts: please specify number in Special Requests field Special Requests: 1 flipchart is handy for demonstrating dataflows --------------------------------------------------------- From nobody Mon Aug 14 18:42:40 2017 Return-Path: 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 E3BBD1321B6 for ; Mon, 14 Aug 2017 18:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=xgenplus.com 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 gtD6rqiaHr4n for ; Mon, 14 Aug 2017 18:42:34 -0700 (PDT) Received: from a.tbms.in (a.tbms.in [202.157.72.21]) by ietfa.amsl.com (Postfix) with ESMTP id 8B63C126B7E for ; Mon, 14 Aug 2017 18:42:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; q=dns/txt; c=simple/relaxed; t=1502761350; s=xgen; d=xgenplus.com; h=In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:From:Date:Message-ID; z=In-Reply-To:<150276099923.21061.13043232639826420017.idtracker@ietfa.amsl.com>|References:<150276099923.21061.13043232639826420017.idtracker@ietfa.amsl.com>|MIME-Version:1.0|Content-Transfer-Encoding:7bit|From:=3D?UTF-8?B?4KSF4KSc4KSvIOCkoeCkvuCkn+Ckvg=3D=3D?=3D=20|Date:Tue,=2015=20Aug=202017=2007:11:05=20+0530|Message-ID:<1905734111.6191521502761350877.JavaMail.root@mx2.datainfosys.com>; l=3057; bh=D7wHAEBlF5fHD3Nc1yEoErLABNI=; b=Yeek3uYmyszbUZoSPtg+xc7z0Onm5jj3P4gp8ZLo20AroTRWChMeyxnx38cuewwn RrywbBKbsw304CRDix+QjDwUvYiJLWXgkgXffUba+Pm6X8F7Q1nTze57TgZ/mQPVs1w D3BvQGjEKQwVf18a1gLGkfn1Nd+2BMXN/ItDM+Xw= Received: From 202.157.83.50[202.157.83.50] by [202.157.83.51] [mx2.datainfosys.com] [mta] with SMTP id ../InBoxS/20170815/07/9533.440422417805(1502761350331); Tue, 15 Aug 2017 01:42:30 +0000 Received: From power0.dil.in[202.157.83.50] by [202.157.83.50] [power0.dil.in] [mta] with SMTP id 88257.56289862221(1502761347523); Tue, 15 Aug 2017 01:42:27 +0000 Received: From[2d38264d106c21f3674cd7e5be5fc143] [171.79.141.240] with SMTP id 95285.94757059775(1502761320840); Tue, 15 Aug 2017 01:42:00 +0000 User-Agent: BharatSync Communicator for Android X_Xgen_Delivery_Report: yes X_Xgen_Device_Id: 355909070379808 In-Reply-To: <150276099923.21061.13043232639826420017.idtracker@ietfa.amsl.com> References: <150276099923.21061.13043232639826420017.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----U78O8WAT622RL0XE34KV7B6KAA6OAQ" Content-Transfer-Encoding: 7bit From: =?UTF-8?B?4KSF4KSc4KSvIOCkoeCkvuCkn+Ckvg==?= Date: Tue, 15 Aug 2017 07:11:05 +0530 To: session-request@ietf.org CC: jmap@ietf.org, aamelnikov@fastmail.fm, jmap-chairs@ietf.org, brong@fastmailteam.com Message-ID: <1905734111.6191521502761350877.JavaMail.root@mx2.datainfosys.com> Archived-At: Subject: Re: [Jmap] jmap - New Meeting Session Request for IETF 100 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 01:42:39 -0000 ------U78O8WAT622RL0XE34KV7B6KAA6OAQ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Bron, can I also join this session remotely and how to join ?=20 On August 15, 2017 7:06:39 AM GMT+05:30, IETF Meeting Session Request Tool= wrote: > > >A new meeting session request has just been submitted by Bron Gondwana, >a Chair of the jmap working group=2E > > >--------------------------------------------------------- >Working Group Name: JSON Mail Access Protocol >Area Name: Applications and Real-Time Area >Session Requester: Bron Gondwana > >Number of Sessions: 1 >Length of Session(s): 2 Hours >Number of Attendees: 50 >Conflicts to Avoid:=20 > First Priority: dispatch > Second Priority: httpbis > Third Priority: dmarc > > >People who must be present: > Barry Leiba > Alexey Melnikov > Bron Gondwana > >Resources Requested: > Flipcharts: please specify number in Special Requests field > >Special Requests: > 1 flipchart is handy for demonstrating dataflows >--------------------------------------------------------- > >_______________________________________________ >Jmap mailing list >Jmap@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/jmap --=20 Sent from my Android device with BharatSync Communicator=2E ------U78O8WAT622RL0XE34KV7B6KAA6OAQ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Bron, can I also join this session remotely = and how to join ?

On August 15, 2017 7:0= 6:39 AM GMT+05:30, IETF Meeting Session Request Tool <session-request@ie= tf=2Eorg> wrote:


A new meeting session request has just b=
een submitted by Bron Gondwana, a Chair of the jmap working group=2E
<=
br />

Working Group Name: JSON Mail Access Protocol
A=
rea Name: Applications and Real-Time Area
Session Requester: Bron Gond=
wana

Number of Sessions: 1
Length of Session(s):  2 HoursNumber of Attendees: 50
Conflicts to Avoid: 
 First Priority:=
 dispatch
 Second Priority: httpbis
 Third Priority: dmarc
<=
br />
People who must be present:
  Barry Leiba
  Alexey Mel=
nikov
  Bron Gondwana

Resources Requested:
  Flipchart=
s: please specify number in Special Requests field

Special Reque=
sts:
  1 flipchart is handy for demonstrating dataflows


Jmap mailing list
Jmap@ietf=2Eorg
https://www=2Eietf=2Eorg/m=
ailman/listinfo/jmap

--
Sent from my Android device with BharatSync Communicator=2E ------U78O8WAT622RL0XE34KV7B6KAA6OAQ-- From nobody Mon Aug 14 18:46:48 2017 Return-Path: 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 2EB14132490; Mon, 14 Aug 2017 18:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, URIBL_BLOCKED=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=PtDDR89D; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DdwjaoOK 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 tS8q4hrS1PmZ; Mon, 14 Aug 2017 18:46:44 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34F7F132489; Mon, 14 Aug 2017 18:46:44 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9C17C2095A; Mon, 14 Aug 2017 21:46:43 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 14 Aug 2017 21:46:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc: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=lzsAlp gsbcsIrbAN1+y3CgDK0l5kJz/fIXGXOLOP4x4=; b=PtDDR89DnBgtWAl8JpNVkm RZZSSc3xpVG3zg96m3rpbYNcEgbL8My6tiFPv8J9/wkU4I86JDCcXN+6GlAleH/Z RlX93R5NQjFCNKtH+R0ZjqNkvwOAbMZqx2eOMiVQzAs3gl2bnIe2qLTlKT3nfb3I vHu59LiFUetIq/Rqc+nSYgjwFCruGVTmZTGXXb0ZBfKCJsfvwHbAqRZUUwcPW17P 45+j2FY6YIIDeH/wjKcqwKZSHnHDYE+bSRAYE7JbLienisKSzb9KEcUinWeyu0DD iqyuPbHSIvsoLy1iAv0Jq/o0ahuEuMouE1JXwuEHiwpU6o2k+ixoA0rBs1Epb2BA == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=lzsAlp gsbcsIrbAN1+y3CgDK0l5kJz/fIXGXOLOP4x4=; b=DdwjaoOKA4I4A+hG4EIqFv sSPqZgO6r32+teeXBu3/fRuRBFH+h5jBp+RZVZQzi3vGj+ZwzAt5XoaLxx+ldvGo LLy1+DMZ54wyYNIvssEe4GlX73BF4XB6JJ7flQO3K/qMRAv1y5g56bY9rLUPFQfZ 7q0jd6AGRfbBaD0BmCTfP9o327HWnSRKe0MXKKsuAb+8UGZ5iRIkoLKgBIiaEAeZ ObdqMlOgHuZbwUnTN8v2z/HZvCEM1cxGi7YpN3wMvkrs253rYbo86m980OHAUps9 bKL81HobdFI8G6FbYGcgtcFbhDwIxTtJ0c49usjM4OFAPrfNxLg/rTqwrwzwxgTQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 682549E264; Mon, 14 Aug 2017 21:46:43 -0400 (EDT) Message-Id: <1502761603.1082546.1073548496.7336462E@webmail.messagingengine.com> From: Bron Gondwana To: =?utf-8?Q?=E0=A4=85=E0=A4=9C=E0=A4=AF=20=E0=A4=A1=E0=A4=BE=E0=A4=9F=E0=A4=BE?= , session-request@ietf.org Cc: jmap@ietf.org, aamelnikov@fastmail.fm, jmap-chairs@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150276160310825460" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ff6d44b3 References: <150276099923.21061.13043232639826420017.idtracker@ietfa.amsl.com> <177234649.6191541502761350884.JavaMail.root@mx2.datainfosys.com> In-Reply-To: <177234649.6191541502761350884.JavaMail.root@mx2.datainfosys.com> Date: Tue, 15 Aug 2017 11:46:43 +1000 Archived-At: Subject: Re: [Jmap] jmap - New Meeting Session Request for IETF 100 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 01:46:46 -0000 This is a multi-part message in MIME format. --_----------=_150276160310825460 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi, The normal method of remote attending is meetecho and jabber. We have successfully had remote participants at previous sessions with these technologies, and I expect it will work the same in SIngapore. IETF is committed to making it possible to participate remotely. Regards, Bron. On Tue, 15 Aug 2017, at 11:41, =E0=A4=85=E0=A4=9C=E0=A4=AF =E0=A4=A1=E0=A4= =BE=E0=A4=9F=E0=A4=BE wrote: > Hello Bron, can I also join this session remotely and how to join ?=20 >=20 > On August 15, 2017 7:06:39 AM GMT+05:30, IETF Meeting Session Request > Tool wrote:>>=20 >>=20 >>=20 >>=20 >> A new meeting session request has just been submitted by Bron >> Gondwana, a Chair of the jmap working group. >>>>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Working Group Name: JSON Mail Access Protocol >>=20 >> Area Name: Applications and Real-Time Area >>=20 >> Session Requester: Bron Gondwana >>=20 >>=20 >>=20 >> Number of Sessions: 1 >>=20 >> Length of Session(s): 2 Hours >>=20 >> Number of Attendees: 50 >>=20 >> Conflicts to Avoid:=20 >>=20 >> First Priority: dispatch >>=20 >> Second Priority: httpbis >>=20 >> Third Priority: dmarc >>=20 >>=20 >>=20 >>=20 >>=20 >> People who must be present: >>=20 >> Barry Leiba >>=20 >> Alexey Melnikov >>=20 >> Bron Gondwana >>=20 >>=20 >>=20 >> Resources Requested: >>=20 >> Flipcharts: please specify number in Special Requests field >>=20 >>=20 >>=20 >> Special Requests: >>=20 >> 1 flipchart is handy for demonstrating dataflows >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> Jmap mailing list >>=20 >> Jmap@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/jmap >>=20 >=20 > -- > Sent from my Android device with BharatSync Communicator.=20 -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150276160310825460 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
Hi,

The normal method of remote attending is = meetecho and jabber.  We have successfully had remote participants at = previous sessions with these technologies, and I expect it will work the s= ame in SIngapore.  IETF is committed to making it possible to particip= ate remotely.

Regards,

Bron.


On Tue, 15 Aug 2017, at 11:41, =E0=A4=85=E0=A4=9C=E0=A4=AF =E0=A4=A1= =E0=A4=BE=E0=A4=9F=E0=A4=BE wrote:
Hello Bron, can= I also join this session remotely and how to join ?

On Au= gust 15, 2017 7:06:39 AM GMT+05:30, IETF Meeting Session Request Tool <s= ession-request@ietf.org> wrote:


A new meeting session request has just be= en submitted by Bron Gondwana, a Chair of the jmap working group.



Working Group Name: JSON Mail Access Prot= ocol
Area Name: Applications and Real-Time Are= a
Session Requester: Bron Gondwana

Number of Sessions: 1
Length of Session(s): 2 Hours
Number of Attendees: 50
Conflicts to Avoid:
First Priority: dispatch
Second Priority: httpbis
Third Priority: dmarc


People who must be present:
Barry Leiba
Alexey Melnikov
Bron Gondwana

Resources Requested:
Flipcharts: please specify number in Sp= ecial Requests field

Special Requests:
1 flipchart is handy for demonstrating = dataflows



Jmap mailing list
Jmap@ietf.org

--
Sent from my Android device with BharatS= ync Communicator.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_150276160310825460-- From nobody Mon Aug 14 18:57:57 2017 Return-Path: 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 3192013248B for ; Mon, 14 Aug 2017 18:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=xgenplus.com 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 Om7O4s6Vw6fi for ; Mon, 14 Aug 2017 18:57:54 -0700 (PDT) Received: from a.tbms.in (a.tbms.in [202.157.72.21]) by ietfa.amsl.com (Postfix) with ESMTP id D0B2313247C for ; Mon, 14 Aug 2017 18:57:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; q=dns/txt; c=simple/relaxed; t=1502762272; s=xgen; d=xgenplus.com; h=In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:From:Date:Message-ID; z=In-Reply-To:<1502761603.1082546.1073548496.7336462E@webmail.messagingengine.com>|References:<150276099923.21061.13043232639826420017.idtracker@ietfa.amsl.com>=20<1772346= 49.6191541502761350884.JavaMail.root@mx2.datainfosys.com>=20<1502761603.10825= 46.1073548496.7336462E@webmail.messagingengine.com>|MIME-Version:1.0|Content-Transfer-Encoding:7bit|From:=3D?UTF-8?B?4KSF4KSc4KSvIOCkoeCkvuCkn+Ckvg=3D=3D?=3D=20|Date:Tue,=2015=20Aug=202017=2007:27:19=20+0530|Message-ID:<1079285688.6199591502762272552.JavaMail.root@mx2.datainfosys.com>; l=8170; bh=vcneL75mTXyy/uavbzxmgVTenYc=; b=bZJyR5zz0y6bWukJONVdhoOwaSRCBHylE1kxAkncqR4Nr44ho7wteiydUK18QMWF nkammDdmmEm1aIMJCC3BsImn12vid9tkmRzIJPY2NK32PGv+wqG9ajO0CO1sCXNp2SB b+ZgK3b90PVC608mmDCw4C55T4XFJg0EJOeguEjY= Received: From 202.157.83.50[202.157.83.50] by [202.157.83.51] [mx2.datainfosys.com] [mta] with SMTP id ../InBoxS/20170815/07/2229.868909230415(1502762270658); Tue, 15 Aug 2017 01:57:50 +0000 Received: From power0.dil.in[202.157.83.50] by [202.157.83.50] [power0.dil.in] [mta] with SMTP id 15542.10293789583(1502762267843); Tue, 15 Aug 2017 01:57:47 +0000 Received: From[2d38264d106c21f3674cd7e5be5fc143] [171.79.141.240] with SMTP id 96626.55341697321(1502762241485); Tue, 15 Aug 2017 01:57:21 +0000 User-Agent: BharatSync Communicator for Android X_Xgen_Delivery_Report: yes X_Xgen_Device_Id: 355909070379808 In-Reply-To: <1502761603.1082546.1073548496.7336462E@webmail.messagingengine.com> References: <150276099923.21061.13043232639826420017.idtracker@ietfa.amsl.com> <177234649.6191541502761350884.JavaMail.root@mx2.datainfosys.com> <1502761603.1082546.1073548496.7336462E@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----HCVEFHZDKZEJ23K0G77GUSBHIBUO17" Content-Transfer-Encoding: 7bit From: =?UTF-8?B?4KSF4KSc4KSvIOCkoeCkvuCkn+Ckvg==?= Date: Tue, 15 Aug 2017 07:27:19 +0530 To: brong@fastmailteam.com,ajay@xgenplus.com,session-request@ietf.org CC: jmap@ietf.org,jmap-chairs@ietf.org,aamelnikov@fastmail.fm Message-ID: <1079285688.6199591502762272552.JavaMail.root@mx2.datainfosys.com> Archived-At: Subject: Re: [Jmap] jmap - New Meeting Session Request for IETF 100 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 01:57:56 -0000 ------HCVEFHZDKZEJ23K0G77GUSBHIBUO17 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sure=2E=2E I shall attend=2E Please send me connection details=2E=2EAnd IST= time=2E=20 Thanks=2E=20 On August 15, 2017 7:16:43 AM GMT+05:30, Bron Gondwana wrote: >Hi, > >The normal method of remote attending is meetecho and jabber=2E We have >successfully had remote participants at previous sessions with these >technologies, and I expect it will work the same in SIngapore=2E IETF >is >committed to making it possible to participate remotely=2E >Regards, > >Bron=2E > > >On Tue, 15 Aug 2017, at 11:41, =E0=A4=85=E0=A4=9C=E0=A4=AF =E0=A4=A1=E0= =A4=BE=E0=A4=9F=E0=A4=BE wrote: >> Hello Bron, can I also join this session remotely and how to join ?=20 >>=20 >> On August 15, 2017 7:06:39 AM GMT+05:30, IETF Meeting Session Request >> Tool wrote:>>=20 >>>=20 >>>=20 >>>=20 >>> A new meeting session request has just been submitted by Bron >>> Gondwana, a Chair of the jmap working group=2E >>>>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Working Group Name: JSON Mail Access Protocol >>>=20 >>> Area Name: Applications and Real-Time Area >>>=20 >>> Session Requester: Bron Gondwana >>>=20 >>>=20 >>>=20 >>> Number of Sessions: 1 >>>=20 >>> Length of Session(s): 2 Hours >>>=20 >>> Number of Attendees: 50 >>>=20 >>> Conflicts to Avoid:=20 >>>=20 >>> First Priority: dispatch >>>=20 >>> Second Priority: httpbis >>>=20 >>> Third Priority: dmarc >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> People who must be present: >>>=20 >>> Barry Leiba >>>=20 >>> Alexey Melnikov >>>=20 >>> Bron Gondwana >>>=20 >>>=20 >>>=20 >>> Resources Requested: >>>=20 >>> Flipcharts: please specify number in Special Requests field >>>=20 >>>=20 >>>=20 >>> Special Requests: >>>=20 >>> 1 flipchart is handy for demonstrating dataflows >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Jmap mailing list >>>=20 >>> Jmap@ietf=2Eorg >>>=20 >>> https://www=2Eietf=2Eorg/mailman/listinfo/jmap >>>=20 >>=20 >> -- >> Sent from my Android device with BharatSync Communicator=2E=20 > >-- > Bron Gondwana, CEO, FastMail Pty Ltd > brong@fastmailteam=2Ecom > > > > >------------------------------------------------------------------------ > >_______________________________________________ >Jmap mailing list >Jmap@ietf=2Eorg >https://www=2Eietf=2Eorg/mailman/listinfo/jmap --=20 Sent from my Android device with BharatSync Communicator=2E ------HCVEFHZDKZEJ23K0G77GUSBHIBUO17 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sure=2E=2E = I shall attend=2E Please send me connection details=2E=2EAnd IST time=2E
Thanks=2E

On August 15, 2017 7:16:43 AM= GMT+05:30, Bron Gondwana <brong@fastmailteam=2Ecom> wrote:
Hi,

The normal method of remote attending is= meetecho and jabber=2E  We have successfully had remote participants = at previous sessions with these technologies, and I expect it will work th= e same in SIngapore=2E  IETF is committed to making it possible to par= ticipate remotely=2E

Regards,

Bron=2E


On Tue, 15 Aug 2017, at 11:41, =E0=A4=85=E0=A4=9C=E0=A4=AF =E0=A4=A1= =E0=A4=BE=E0=A4=9F=E0=A4=BE wrote:
Hello Bron, ca= n I also join this session remotely and how to join ?

On A= ugust 15, 2017 7:06:39 AM GMT+05:30, IETF Meeting Session Request Tool <= session-request@ietf=2Eorg> wrote:
= 






A new meeting session request has just b=
een submitted by Bron Gondwana, a Chair of the jmap working group=2E
<=
/div>










Working Group Name: JSON Mail Access Pro=
tocol


Area Name: Applications and Real-Time Ar=
ea


Session Requester: Bron Gondwana





Number of Sessions: 1


Length of Session(s):  2 Hours


Number of Attendees: 50


Conflicts to Avoid: 


 First Priority: dispatch


 Second Priority: httpbis


 Third Priority: dmarc








People who must be present:


  Barry Leiba


  Alexey Melnikov


  Bron Gondwana





Resources Requested:


  Flipcharts: please specify number in S=
pecial Requests field





Special Requests:


  1 flipchart is handy for demonstrating=
 dataflows











Jmap mailing list


Jmap@ietf=2Eorg

--
Sent from my Android device with Bharat= Sync Communicator=2E

--
  Bron Gondwana, CEO, FastMail Pty Ltd
=
  brong@fastmailteam=2Ecom



Jmap mailing list
Jmap=
@ietf=2Eorg
https://www=2Eietf=2Eorg/mailman/listinfo/jmap

--
Sent from my Android device with BharatSync Communicator=2E ------HCVEFHZDKZEJ23K0G77GUSBHIBUO17-- From nobody Mon Aug 14 19:07:41 2017 Return-Path: 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 1412913249C for ; Mon, 14 Aug 2017 19:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, URIBL_BLOCKED=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=ZF4qa0fU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WFvTg3xI 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 vw9lk3RQPQLe for ; Mon, 14 Aug 2017 19:07:37 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8E57132499 for ; Mon, 14 Aug 2017 19:07:36 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id BF733209F6 for ; Mon, 14 Aug 2017 22:07:35 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute6.internal (MEProxy); Mon, 14 Aug 2017 22:07:35 -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=NjDjWQPI1gdwtVYxr GTuY4SKQwpm5UBqba1R4A2Z3Fk=; b=ZF4qa0fUaqyq+A7dK7KHrF3bQyPAKOT5D 4Oe8Y98KOm1+rlOfZvOZG0j+JlfC/guK97y53u7Q6x+Ew2Oig+8KZyx1zbd2uyiS SUVsyOXkf2vN8eXHoLAZKG6U4FaGEgtYWi67a026oEukVSuk6c5RNu2rLL4OuGgy 2QYo2OkGnCY34Y61GtN5TWcb419cOvVIGIit0xx+73WBbqlQV1OhjVLtlWb4quqD xh6QGP8khkiKDtv162ZzTh/DB3//lNyyDkfvdzBCXdqQRAPuvRlKBvFCmbkvBF1Z y0q2K9ERoVJaeK3AoC6fOi7d1pFsrzIt3l/1TNYnePAqE4GxtfDvA== 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=NjDjWQ PI1gdwtVYxrGTuY4SKQwpm5UBqba1R4A2Z3Fk=; b=WFvTg3xIZfpVa44Pf7cc/P 0efO6ahnQPq3ZNI1SUgh52m2wu3CE7/ixoOHrRr5Rfrm3GcqMXjiOmhQAmTUGsdg 4jIbH87sbxjCdGV5Lh38nyHDE9Kt8W9u+3Ksb7y8CnUWRtAlkGWmCZV3TggtqDnl VhA+F2NZ6wHdPyeh0kuoWgY26y1y3LzDRIpbeKvJrMTMZ8nt0bCUiuOPRpRQjjzX 4oerM7vXqsZlP7r7ZpwGYDD6szU4iZJb02jcT8wWnsYCDYXjpV5zWkuk3//9dzh6 eQGMzfravBTXtnNGz/APHk7pNqY6ldODOBEz2DDytIaJ/HTTfITGwcIx7dofq0LA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 882EA9E264; Mon, 14 Aug 2017 22:07:35 -0400 (EDT) Message-Id: <1502762855.1086708.1073561632.20E25ACE@webmail.messagingengine.com> From: Bron Gondwana To: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150276285510867080" X-Mailer: MessagingEngine.com Webmail Interface - ajax-ff6d44b3 In-Reply-To: <1079285688.6199591502762272552.JavaMail.root@mx2.datainfosys.com> Date: Tue, 15 Aug 2017 12:07:35 +1000 References: <150276099923.21061.13043232639826420017.idtracker@ietfa.amsl.com> <177234649.6191541502761350884.JavaMail.root@mx2.datainfosys.com> <1502761603.1082546.1073548496.7336462E@webmail.messagingengine.com> <1079285688.6199591502762272552.JavaMail.root@mx2.datainfosys.com> Archived-At: Subject: Re: [Jmap] jmap - New Meeting Session Request for IETF 100 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 02:07:39 -0000 This is a multi-part message in MIME format. --_----------=_150276285510867080 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" They will be available once the session has been scheduled. I will tell the entire list then. Regards, Bron. On Tue, 15 Aug 2017, at 11:57, =E0=A4=85=E0=A4=9C=E0=A4=AF =E0=A4=A1=E0=A4= =BE=E0=A4=9F=E0=A4=BE wrote: > Sure.. I shall attend. Please send me connection details..And > IST time.>=20 > Thanks.=20 >=20 > On August 15, 2017 7:16:43 AM GMT+05:30, Bron Gondwana > wrote:>> Hi, >>=20 >> The normal method of remote attending is meetecho and jabber. We >> have successfully had remote participants at previous sessions with >> these technologies, and I expect it will work the same in SIngapore. >> IETF is committed to making it possible to participate remotely.>>=20 >> Regards, >>=20 >> Bron. >>=20 >>=20 >> On Tue, 15 Aug 2017, at 11:41, =E0=A4=85=E0=A4=9C=E0=A4=AF =E0=A4=A1=E0= =A4=BE=E0=A4=9F=E0=A4=BE wrote: >>> Hello Bron, can I also join this session remotely and how to join ?>>>= =20 >>> On August 15, 2017 7:06:39 AM GMT+05:30, IETF Meeting Session >>> Request Tool wrote:>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> A new meeting session request has just been submitted by Bron >>>> Gondwana, a Chair of the jmap working group. >>>>>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Working Group Name: JSON Mail Access Protocol >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Area Name: Applications and Real-Time Area >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Session Requester: Bron Gondwana >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Number of Sessions: 1 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Length of Session(s): 2 Hours >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Number of Attendees: 50 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Conflicts to Avoid:=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> First Priority: dispatch >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Second Priority: httpbis >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Third Priority: dmarc >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> People who must be present: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Barry Leiba >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Alexey Melnikov >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Bron Gondwana >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Resources Requested: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Flipcharts: please specify number in Special Requests field >>>>>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Special Requests: >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> 1 flipchart is handy for demonstrating dataflows >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Jmap mailing list >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> Jmap@ietf.org >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> https://www.ietf.org/mailman/listinfo/jmap >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>> -- >>> Sent from my Android device with BharatSync Communicator.=20 >>=20 >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >>=20 >>=20 >>=20 >>=20 >>=20 >> Jmap mailing list >>=20 >> Jmap@ietf.org >>=20 >> https://www.ietf.org/mailman/listinfo/jmap >>=20 >=20 > -- > Sent from my Android device with BharatSync Communicator.=20 > _________________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap -- Bron Gondwana, CEO, FastMail Pty Ltd brong@fastmailteam.com --_----------=_150276285510867080 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
They will be available once the ses= sion has been scheduled.  I will tell the entire list then.

Regards,

Bron.

On Tue, 15 Aug 2017, at 11:57, =E0=A4=85=E0=A4=9C=E0=A4=AF =E0=A4=A1= =E0=A4=BE=E0=A4=9F=E0=A4=BE wrote:
Sure.. I shall = attend. Please send me connection details..And IST time.

Thanks.

On Au= gust 15, 2017 7:16:43 AM GMT+05:30, Bron Gondwana <brong@fastmailteam.co= m> wrote:
Hi,

The normal method of remote attending is = meetecho and jabber.  We have successfully had remote participants at = previous sessions with these technologies, and I expect it will work the s= ame in SIngapore.  IETF is committed to making it possible to particip= ate remotely.

Regards,

Bron.


On Tue, 15 Aug 2017, at 11:41, =E0=A4=85=E0=A4=9C=E0=A4=AF =E0=A4=A1= =E0=A4=BE=E0=A4=9F=E0=A4=BE wrote:
Hello Bron, can= I also join this session remotely and how to join ?

On August 15, 2017 7:06:39 AM GMT+05= :30, IETF Meeting Session Request Tool <session-request@ietf.org> wro= te:














A new meeting session request has just be=
en submitted by Bron Gondwana, a Chair of the jmap working group.



























Working Group Name: JSON Mail Access Prot=
ocol






Area Name: Applications and Real-Time Are=
a






Session Requester: Bron Gondwana













Number of Sessions: 1






Length of Session(s):  2 Hours






Number of Attendees: 50






Conflicts to Avoid: 






 First Priority: dispatch






 Second Priority: httpbis






 Third Priority: dmarc




















People who must be present:






  Barry Leiba






  Alexey Melnikov






  Bron Gondwana













Resources Requested:






  Flipcharts: please specify number in Sp=
ecial Requests field













Special Requests:






  1 flipchart is handy for demonstrating =
dataflows



























Jmap mailing list






Jmap@ietf.org

--
Sent from my Android device with BharatSy= nc Communicator.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com






Jmap mailing list


Jmap@ietf.org

--
Sent from my Android device with BharatS= ync Communicator.
_______________________________________________
Jmap mailing list

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com


--_----------=_150276285510867080-- From nobody Tue Aug 15 05:37:14 2017 Return-Path: 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 6DAA6120721; Tue, 15 Aug 2017 05:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 qcMqcwqX9Lg0; Tue, 15 Aug 2017 05:37:08 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18DF013213F; Tue, 15 Aug 2017 05:37:08 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 76so3936961ith.0; Tue, 15 Aug 2017 05:37:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=J9kHfZwHPStbOubJeBpHjaKE9i1ysnTk6M09BbXnqac=; b=aOj7xckQjv0kpkZ33mDJUnHIsA5w+SYsjMHYmH1n6bzWgDJ/sUw044jD6Qx8fpnB0x 54GEL+d3Mhbj4qOVVNCqR5RFueHDq2wXUPObCizM0z5RiHl9e7K8JMgBEHsXVOeuE+qk NSXeoRi6rDADmqJMVBIi7hkbYIA11X5gAcbqY2+7fvYJ1fNPeWVvv/+o37w4CN1FJpOK PDd8hVuV3T0GM3fGFJMIuKAkaB85c9xzsfMZ+R46OJgM+JE7KG9FnYw0OngbZLYpaR/M Gd+2SaiRTNxRNtVVGjxQMB31QGY2fX4O0I3SJFTdab4R0T4TWsQSOmwfUyAwsNx2eAfr oWzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=J9kHfZwHPStbOubJeBpHjaKE9i1ysnTk6M09BbXnqac=; b=Ullo90sn1yx1wuUO+jsKTCmFFp8T4LZJlWCxzFZDoFUsn6jo3nLUgKGgv8aNVteh0o VB42ckg6DqiSiOtHBbtASkcW1sBdj6ukTGotCc0+mxrHORgpUpqh4N6zF2/lsl8CJU+j kkLxpVi3IowR0uoHW94oLRQKScndbZgWz246vl2Yvqy7294+2GHwBoXQjfYQYpR4fx95 yCxAlVxwSHLob7E3FRdpLpO3qd40tY1WfbVVn1IHPRBbZtx3swltg4wNKb3JJzEB0OF9 qsSuzPT/z/o//jMi3FxWRvorib6q6Jc3D1UR3ZiL67Ra+HVs+mOez5WkmgeA0dQTJ1+c l1kA== X-Gm-Message-State: AHYfb5jvmI5YbTzD3pZgx9/CZ170mB9s2e1qpX0ERiqvdtGc+VdGBKgE 3pLwbEAIqaRzxgAGJOg9JbIFgYiu8w== X-Received: by 10.36.173.2 with SMTP id c2mr1792535itf.16.1502800627277; Tue, 15 Aug 2017 05:37:07 -0700 (PDT) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.167.19 with HTTP; Tue, 15 Aug 2017 05:37:06 -0700 (PDT) In-Reply-To: <405602743.6199631502762272577.JavaMail.root@mx2.datainfosys.com> References: <150276099923.21061.13043232639826420017.idtracker@ietfa.amsl.com> <177234649.6191541502761350884.JavaMail.root@mx2.datainfosys.com> <1502761603.1082546.1073548496.7336462E@webmail.messagingengine.com> <405602743.6199631502762272577.JavaMail.root@mx2.datainfosys.com> From: Barry Leiba Date: Tue, 15 Aug 2017 08:37:06 -0400 X-Google-Sender-Auth: Db5y2tB0t2j9okF0vQFrSw1kPuc Message-ID: To: =?UTF-8?B?4KSF4KSc4KSvIOCkoeCkvuCkn+Ckvg==?= Cc: Bron Gondwana , session-request@ietf.org, jmap@ietf.org, jmap-chairs@ietf.org, Alexey Melnikov Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Jmap] jmap - New Meeting Session Request for IETF 100 X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2017 12:37:12 -0000 > Sure.. I shall attend. Please send me connection details..And IST time. When the Singapore meeting agenda is published (preliminary on 13 Oct, final on 20 Oct) you will be able to see it here: https://www.ietf.org/meeting/100/index.html (the "Agenda" links will be clickable at that time) The times will be in Singapore time; you will have to convert that to your own time zone. Barry > On August 15, 2017 7:16:43 AM GMT+05:30, Bron Gondwana > wrote: >> >> Hi, >> >> The normal method of remote attending is meetecho and jabber. We have >> successfully had remote participants at previous sessions with these >> technologies, and I expect it will work the same in SIngapore. IETF is >> committed to making it possible to participate remotely. >> >> Regards, >> >> Bron. >> >> >> On Tue, 15 Aug 2017, at 11:41, =E0=A4=85=E0=A4=9C=E0=A4=AF =E0=A4=A1=E0= =A4=BE=E0=A4=9F=E0=A4=BE wrote: >> >> Hello Bron, can I also join this session remotely and how to join ? >> >> On August 15, 2017 7:06:39 AM GMT+05:30, IETF Meeting Session Request To= ol >> wrote: >> >> >> >> >> >> A new meeting session request has just been submitted by Bron Gondwana, = a >> Chair of the jmap working group. >> >> >> >> >> >> ________________________________ >> >> >> Working Group Name: JSON Mail Access Protocol >> >> Area Name: Applications and Real-Time Area >> >> Session Requester: Bron Gondwana >> >> >> >> Number of Sessions: 1 >> >> Length of Session(s): 2 Hours >> >> Number of Attendees: 50 >> >> Conflicts to Avoid: >> >> First Priority: dispatch >> >> Second Priority: httpbis >> >> Third Priority: dmarc >> >> >> >> >> >> People who must be present: >> >> Barry Leiba >> >> Alexey Melnikov >> >> Bron Gondwana >> >> >> >> Resources Requested: >> >> Flipcharts: please specify number in Special Requests field >> >> >> >> Special Requests: >> >> 1 flipchart is handy for demonstrating dataflows >> >> ________________________________ >> >> >> >> >> ________________________________ >> >> >> Jmap mailing list >> >> Jmap@ietf.org >> >> https://www.ietf.org/mailman/listinfo/jmap >> >> >> -- >> Sent from my Android device with BharatSync Communicator. >> >> >> -- >> Bron Gondwana, CEO, FastMail Pty Ltd >> brong@fastmailteam.com >> >> >> ________________________________ >> >> Jmap mailing list >> Jmap@ietf.org >> https://www.ietf.org/mailman/listinfo/jmap > > > -- > Sent from my Android device with BharatSync Communicator. --=20 Barry -- Barry Leiba (barryleiba@computer.org) http://internetmessagingtechnology.org/ From nobody Sun Aug 27 18:44:13 2017 Return-Path: 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 4D3A0132661 for ; Sun, 27 Aug 2017 18:44:12 -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=GdnJPD9W; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BFJuZnwu 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 xtp3xfjghGw6 for ; Sun, 27 Aug 2017 18:44:10 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2B9E132144 for ; Sun, 27 Aug 2017 18:44:10 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id 03ECF20B8C for ; Sun, 27 Aug 2017 21:44:10 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Sun, 27 Aug 2017 21:44:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=content-transfer-encoding:content-type:date :from:message-id:mime-version:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ijH2Icto2sMjWLEQrPKdgclNCkDfuZ9zT0h/td2UY Gc=; b=GdnJPD9WjyFg9n6gTNXEq1Bej3fqrmw9E0Dzz8s6VuHpjdlx9gsogp3p4 QHhQwiyvrvHgV+td6pbMUtY1nAmv47rCuKtOKZUXzpfaYEDpuArI3ALpiBlRu7ii 42qIceyz4AC5zfk3CN1hywu67IeiNvNtWsqjGs+h9+bVUHMbPP+IL09R+K0oIx0R hrWxEUq/vZsRVAjVJs8LNLTy2429mEIE3y/68XVzQpxJzFDwh6mKQKY9ReyM4J9q zLLH7qX+5i/Um1jiJJKRkXEulcAKUH0hZ64BG0B4y9DstYd3G0PrtZNMDsyAwvM2 jX1CHLb0PuGjdpGzuezozqkUntZJA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=ijH2Icto2sMjWLEQrPKdgclNCkDfu Z9zT0h/td2UYGc=; b=BFJuZnwu5ImfIQfRMEPxTfz+T9B5taR1SD8VBekP7fr39 GwmGMJRVH1Qgw0Fq9yI++a87t6jAP4vHMr1K3hiIQ/FpQgrw5uagbgVJ7piNnD9r CTiiGhaxjvpDvOlnuJY5C2mnPMMpRafLNyydHRzNNrYJKlacZFkxfNqdMV4KNqFo DqXy5LfAoQ5sJtxy9shGDKSirLAYrgQFcjuNoRDCzNTMSYYm0t3KCnZ7jjfHdadk 9h0FWpodlwt1CeAr/GiiF9ciFNxcFbIb9dVBecBA4x+9mcdD1Y84OhCmYy0FbRAX ORIFTaQ6uEAyAo3I3J6hxOvvSKpVQA9P7D3hDctaQ== X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id B40CAE24F9; Sun, 27 Aug 2017 21:44:09 -0400 (EDT) Message-Id: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> From: Neil Jenkins To: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15038846494945252" X-Mailer: MessagingEngine.com Webmail Interface - ajax-dba1c099 Date: Mon, 28 Aug 2017 11:44:09 +1000 Archived-At: Subject: [Jmap] MessageSubmission last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 01:44:12 -0000 This is a multi-part message in MIME format. --_----------=_15038846494945252 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" Hello all, I'm getting back to work on the JMAP spec stuff, and first order of business is getting the MessageSubmission change merged. There were a few minor issues people had raised on the pull request, all of which I've now resolved. I think this is just about ready to merge, so I'm putting out a call for any last comments, clarifications or objections then I'll merge this next week: https://github.com/jmapio/jmap/pull/99 Cheers, Neil. --_----------=_15038846494945252 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
Hello all,

I'm getting back to work on the JMAP spec stuff, and first order of business is getting the MessageSubmission change merged. There were a few minor issues people had raised on the pull request, all of which I've now resolved. I think this is just about ready to merge, so I'm putting out a call for any last comments, clarifications or objections then I'll merge this next week: https://github.com/jmapio/jmap/pull/99

Cheers,
Neil.
--_----------=_15038846494945252-- From nobody Mon Aug 28 10:55:16 2017 Return-Path: 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 1E8FA13295E for ; Mon, 28 Aug 2017 10:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=mailforce.net header.b=XhOFIngU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sHkdYE4g 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 Ed85uvGaoa49 for ; Mon, 28 Aug 2017 10:55:12 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EF613218E for ; Mon, 28 Aug 2017 10:55:12 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 74AC5217D0; Mon, 28 Aug 2017 13:55:11 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Mon, 28 Aug 2017 13:55:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=cc: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:x-sasl-enc; s=fm1; bh=kYyuZE 85NgaTt5AwoIiWLRIbeyRMGM3DP9sI6emeVC4=; b=XhOFIngUaGlqlBSjc7FU0O GSYflDRdMyEpgaM7w9+3q2hAUdlJDV0XyMpuHwLwV5TZEZ27TAWoqoJGAFiMbVtx 1sO8StEQx2iVsXvJ3JNEz19nLMtRMcFMWim2x/TIJQUQWsXtFhjqB81yfM469U4b STQ1CNvUMvzgWUVG/O1tD+5TOxq0tdjCl0GKaIUoWEBcm/hAsf/DWIRnJQQ42Gpr 0zbiDFMwwvIvT94+bjlVPV3E860RgmqnFFI6f+TLw/AxSUxx6i9ST5dSLlmkU8ip carvsJaHHFzALSzwaEuGhRSNwK1c9aiT0ixy2/aQasXf+U5tBUNOC0eVbGrLvkcg == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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:x-sasl-enc; s= fm1; bh=kYyuZE85NgaTt5AwoIiWLRIbeyRMGM3DP9sI6emeVC4=; b=sHkdYE4g Cscmrz+6J6MBpes4NF83Mcfdmpx6mrihfSbborIg/ZTh9Lrp3i++6ziOuowV2esn hfVlAnHMk/yMcAdBSNg4zyI8h6qZoSn47NBOaj8fXXsgwfA/pLTqdFhOT7oLPrcl /cFdHooiwKHrxd2/c4zawhS8jzv5CZRlGzCFDyLZ1Z5VWnf6RDDKcd2Ql1lGu58C 1DQAodkrg8jotlV+co1Z4fN0EZz6QNvcqUGYqtrSdhJCEzqNUeDrPFVw05h3XzXE gLPxChhW/PxMZRd3CeesxC9DLmWetwOwgOxO1eI+xLuo/EM25Hm5z5DxmYddb+jO KSqu+8GVEk+WDQ== X-ME-Sender: X-Sasl-enc: +R9pt2bXrJDP5x2NMo12DS++hDV8JYNi85dE7AObtcIU 1503942910 Received: from [10.226.53.204] (221.sub-97-45-2.myvzw.com [97.45.2.221]) by mail.messagingengine.com (Postfix) with ESMTPA id D00C27E2EA; Mon, 28 Aug 2017 13:55:10 -0400 (EDT) References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> Mime-Version: 1.0 (1.0) In-Reply-To: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> Content-Type: multipart/alternative; boundary=Apple-Mail-75AC06A5-879D-4507-9329-6EC8D4410DBD Content-Transfer-Encoding: 7bit Message-Id: <00E74483-7E9F-4728-A23B-6AD2989C3521@glyphein.mailforce.net> Cc: IETF JMAP Mailing List X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Mon, 28 Aug 2017 13:55:07 -0400 To: Neil Jenkins Archived-At: Subject: Re: [Jmap] MessageSubmission last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 17:55:14 -0000 --Apple-Mail-75AC06A5-879D-4507-9329-6EC8D4410DBD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Should this part of the spec speak to what JMAP will/will not do if a "Retur= n-Path:" header is submitted as part of a message? Stan > On Aug 27, 2017, at 9:44 PM, Neil Jenkins wrote: >=20 > Hello all, >=20 > I'm getting back to work on the JMAP spec stuff, and first order of busine= ss is getting the MessageSubmission change merged. There were a few minor is= sues people had raised on the pull request, all of which I've now resolved. I= think this is just about ready to merge, so I'm putting out a call for any l= ast comments, clarifications or objections then I'll merge this next week: h= ttps://github.com/jmapio/jmap/pull/99 >=20 > Cheers, > Neil. > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --Apple-Mail-75AC06A5-879D-4507-9329-6EC8D4410DBD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Should this part of the spec speak to what JMAP will/will not do if a "Return-Path:" header is submitted as part of a message?


Stan

On Aug 27, 2017, at 9:44 PM, Neil Jenkins <neilj@fastmailteam.com> wrote:

Hello all,

I'm getting back to work on the JMAP spec stuff, and first order of business is getting the MessageSubmission change merged. There were a few minor issues people had raised on the pull request, all of which I've now resolved. I think this is just about ready to merge, so I'm putting out a call for any last comments, clarifications or objections then I'll merge this next week: https://github.com/jmapio/jmap/pull/99

Cheers,
Neil.
_______________________________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman/listinfo/jmap
--Apple-Mail-75AC06A5-879D-4507-9329-6EC8D4410DBD-- From nobody Mon Aug 28 19:11:22 2017 Return-Path: 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 78D0C126E64 for ; Mon, 28 Aug 2017 19:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 T__AzsdwhJHv for ; Mon, 28 Aug 2017 19:11:19 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F8A8120721 for ; Mon, 28 Aug 2017 19:11:19 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v7T2BF6D018004 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Aug 2017 02:11:16 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v7T2BF0l022646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Aug 2017 02:11:15 GMT Received: from abhmp0018.oracle.com (abhmp0018.oracle.com [141.146.116.24]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v7T2BFCh015112; Tue, 29 Aug 2017 02:11:15 GMT Received: from [10.145.239.150] (/10.145.239.150) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Aug 2017 19:11:14 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: "IETF JMAP Mailing List" Date: Mon, 28 Aug 2017 19:11:12 -0700 Message-ID: <0F44D4FC-52D0-47B2-A412-95B739B8FA85@oracle.com> In-Reply-To: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Jmap] MessageSubmission last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 02:11:21 -0000 Overall, I like this approach and support this change. Some substantive issues: On the DeliveryStatus, I don't like having "isQueued" and "delivered" as separate properties because it allows a silly state (isQueued = true, delivered = yes). I think it'd be better to have one string field that doesn't allow silly states. Perhaps: status = {queued, failed, delivered, unknown} where: queued: in a local mail queue and status will change once it exits the local mail queues. This means the smtpReply, if present, may change. failed: permanent delivery failure for recipient. The smtpReply is final. delivered: successfully delivered to recipient. The smtpReply, if present, is final. unknown: unknown or other status; additional information may be present in DSN message for recipient. The smtpReply may or may not change for this status. I'm neutral on whether the other three DSN action values are included {delayed, expanded, relayed}; they seem harmless as a client can just treat them as synonyms for 'unknown' and helpful as clients that cared wouldn't have to fetch & parse the DSN. But I understand there's a desire to keep things simpler so I'm fine either way. The "SHOULD NOT expose ... MDN messages" is fine. The "SHOULD NOT expose DSN" is a problem for failed DSNs because that means any client that fails to build a UI for per-recipient DeliveryStatus / failed will result in silently lost mail. I think hiding of failure DSNs needs to be a client-requested opt-in feature and clients MUST provide users with a mechanism to indicate delivery failure if the client requests that feature. I'd be interested in other opinions on this point. I'm not a fan of client opt-in features, but I don't see a better alternative in this case. For DeliveryStatus, I think we need some discussion about how status for addresses that don't exactly match one of the rcptTo addresses are reported. There are three cases: 1. there's a single DSN that has an original recipient matching a rcptTo address (but for a different actual recipient). 2. there are multiple DSNs with different addresses that match the same original recipient. 3. there are DSNs that don't match any original rcptTo. I'd suggest servers may correlate for case 1, but I think case 2 & 3 should be punted (the server doesn't correlate DSN; it just leaves it in the INBOX). Punting on case 1 is also ok. But the spec needs to advise on the correlation model to get consistent behavior. For smtpReply, how should the JMAP server deal with multi-line responses? And some nits: fgetMes => MessageSubmission succesfully => successfully succesful => successful The deliveryStatus property has redundant text; the following text appears twice and should only appear once: "This property is server-set and MAY not be supported by all servers, in which case it will remain null. Servers that support it SHOULD update the MessageSubmission object each time the status of any of the recipients changes." I believe this text: "This is a map from the email address of each recipient of the message, to the most recent SMTP reply code/text known." should read: "This is a map from the email address of each recipient to a DeliveryStatus object." I believe this should be deleted: "The isFinal property allows clients to know if the status may still change further." "displayed: yes" actually means: the recipient's system claims the message has been displayed to the user. - Chris From nobody Mon Aug 28 19:20:19 2017 Return-Path: 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 49BC9126E64 for ; Mon, 28 Aug 2017 19:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 7ua-RNMj_Ffa for ; Mon, 28 Aug 2017 19:20:17 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C55120721 for ; Mon, 28 Aug 2017 19:20:17 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v7T2KCcT002612 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Aug 2017 02:20:13 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v7T2KC1n007213 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 29 Aug 2017 02:20:12 GMT Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v7T2KBq0018302; Tue, 29 Aug 2017 02:20:12 GMT Received: from [10.145.239.150] (/10.145.239.150) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 28 Aug 2017 19:20:11 -0700 From: "Chris Newman" To: "Stan Kalisch" Cc: "Neil Jenkins" , "IETF JMAP Mailing List" Date: Mon, 28 Aug 2017 19:20:10 -0700 Message-ID: <53D71EC1-E19C-4DCE-B5A8-FB1C85EC143A@oracle.com> In-Reply-To: <00E74483-7E9F-4728-A23B-6AD2989C3521@glyphein.mailforce.net> References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> <00E74483-7E9F-4728-A23B-6AD2989C3521@glyphein.mailforce.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Subject: Re: [Jmap] MessageSubmission last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 02:20:18 -0000 On 28 Aug 2017, at 10:55, Stan Kalisch wrote: > Should this part of the spec speak to what JMAP will/will not do if a > "Return-Path:" header is submitted as part of a message? I think this matter is covered sufficiently in RFC 5321 (e.g., page 58). If we say anything, I'd just say JMAP should comply with rules for a message-originating or message submission SMTP system as described in RFC 5321 and RFC 6409. - Chris From nobody Tue Aug 29 13:10:03 2017 Return-Path: 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 A6F83132707 for ; Tue, 29 Aug 2017 13:10:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=UyS6Z3hs; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=I5cEmAGH 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 ezbENJ_wQ4py for ; Tue, 29 Aug 2017 13:09:59 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65451321D8 for ; Tue, 29 Aug 2017 13:09:59 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1BA4720B9D; Tue, 29 Aug 2017 16:09:59 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Tue, 29 Aug 2017 16:09:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=cc: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:x-sasl-enc; s=fm1; bh=DAKDCR ez2d77icG+v/T2lxezDuB5DW9X/TOSg8vnfbo=; b=UyS6Z3hschQuqCenCFisZu SamXc24jDbHnGdFOfR19QW/JfA7sjpCHXj1FCfhy+JCZPUcoNhuJgRJNGi/4TC72 8VF018ulmfOAKpBJIcQY6PyQ/JNRWZZQR/Z+MS+ohUqTjkWXZ64iLHqeddwBDpGI yK8MwGGY6DYXHVwW/9twVYbOQwxBoPOCICAGIAgGrV0pxZ9+3mOzdM5U//VCQmHz tHKaWj14QNTNRGLdSUiMJhXR4QwbXFTzBoAXnxo7TniMzNLEiOyGtGnIFTVyWfOr u8KXJE1hysdGo+r0V5KGZxK3ebtGsn3V4oKqb4FzyjR/H03UkUheuheeh8jooNAg == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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:x-sasl-enc; s= fm1; bh=DAKDCRez2d77icG+v/T2lxezDuB5DW9X/TOSg8vnfbo=; b=I5cEmAGH Wl0HVGQEidjzSRUuFlNlQT0avRphhXtC9RTiWRXYPv5dQY8n795PxbZmFQr5rxW2 32NJV+QWe7NUKsptucPFG2n/8N/4GrrJEHAMnDAKyMc5ofAC7nr/DpfR2kd72kPp G/XUWdsPYTNJiq+gvJs9twRcuZ3UDlXzMqiTyhC/Cqa7ptLMj/Gn/wIfdbnfPXx+ dbqVDDQV0ZWd+WXGA/+Q74pA2WpnzA5X0zJIz7ga64V8FEplDaxUjnntDWoEylMg f4Ryl7LULuTOG2ICs48Nz2mIRNJjsjWFF7LqChw25hWq7YA+xKxn3Ud+B05duypj Iy4L+XkOGzd04A== X-ME-Sender: X-Sasl-enc: mBVi3mRRIJ8kh+y+k+O/6xbVuM6ikCrQtx2obKe5LC2I 1504037397 Received: from [10.232.162.207] (59.sub-97-45-67.myvzw.com [97.45.67.59]) by mail.messagingengine.com (Postfix) with ESMTPA id 9D0BD7E188; Tue, 29 Aug 2017 16:09:57 -0400 (EDT) References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> <00E74483-7E9F-4728-A23B-6AD2989C3521@glyphein.mailforce.net> <53D71EC1-E19C-4DCE-B5A8-FB1C85EC143A@oracle.com> In-Reply-To: <53D71EC1-E19C-4DCE-B5A8-FB1C85EC143A@oracle.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-2EE8CAD6-824B-4CCA-AD83-B8F0AAE3DEF3 Message-Id: Cc: Neil Jenkins , IETF JMAP Mailing List X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Tue, 29 Aug 2017 16:08:20 -0400 To: Chris Newman Archived-At: Subject: Re: [Jmap] MessageSubmission last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Aug 2017 20:10:02 -0000 --Apple-Mail-2EE8CAD6-824B-4CCA-AD83-B8F0AAE3DEF3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Chris, > On Aug 28, 2017, at 10:20 PM, Chris Newman wrote= : >=20 >> On 28 Aug 2017, at 10:55, Stan Kalisch wrote: >> Should this part of the spec speak to what JMAP will/will not do if a "Re= turn-Path:" header is submitted as part of a message? >=20 > I think this matter is covered sufficiently in RFC 5321 (e.g., page 58). I= f we say anything, I'd just say JMAP should comply with rules for a message-= originating or message submission SMTP system as described in RFC 5321 and R= FC 6409. I think the matter was covered sufficiently at the time those documents were= written. I think that, at minimum, the kind language about SMTP-compliant b= ehavior that you describe would be helpful. I posed my question because a rather significant amount of documents, varyin= g in technical quality, now conflate setting the "Return-Path:" header field= at time of submission (or practical equivalent) with actually setting the r= eturn path. (You do correctly point out, of course, that this behavior runs= counter to, especially, RFC 5321.). I suspect a lot of this stems from the f= act that VERP is now in such massive use in bulk mail operations that we now= have non-technical professionals in disciplines such as marketing intereste= d in using the mechanism they see manifested by a "Return-Path:" header. A l= ot of this documentation, consequently, reads to me like it was written with= these people in mind, but also for IT personnel who have perhaps limited ex= perience with email, and end up becoming confused by the documentation as a r= esult. (If one goes further into the weeds, one finds product documentation= claiming variables one can use to set the "Return-Path:" header's value, di= rectly.) I think, in this light, the spec should say something. Perhaps, even though= it would be less elegant, rather than just refer to SMTP, it should make on= e or two things explicit. > - Chris >=20 > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --Apple-Mail-2EE8CAD6-824B-4CCA-AD83-B8F0AAE3DEF3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi Chris,
On Aug 28, 2017, at 10:20 PM, Chris Newman <chris.newman@oracle.com> wrote:

=
On 28 Aug 2017, at 10:55, Stan Ka= lisch wrote:
Should this part of t= he spec speak to what JMAP will/will not do if a "Return-Path:" header is su= bmitted as part of a message?

= I think this matter is covered sufficiently in RFC 5321 (e.g., page 58). If w= e say anything, I'd just say JMAP should comply with rules for a message-ori= ginating or message submission SMTP system as described in RFC 5321 and RFC 6= 409.

I think the matter was= covered sufficiently at the time those documents were written.  I thin= k that, at minimum, the kind language about SMTP-compliant behavior that you= describe would be helpful.

I posed my question because a rather significant amo= unt of documents, varying in technical quality, now conflate setting the "Re= turn-Path:" header field at time of submission (or practical equivalent) wit= h actually setting the return path.  (You do correctly point out, of co= urse, that this behavior runs counter to, especially, RFC 5321.). I suspect a lot o= f this stems from the fact that VERP is now in such massive use in bulk mail= operations that we now have non-technical professionals in disciplines such= as marketing interested in using the mechanism they see manifested by a "Re= turn-Path:" header.  A lot of this documentation, consequently, reads t= o me like it was written with these people in mind, but also for IT personne= l who have perhaps limited experience with email, and end up becoming confus= ed by the documentation as a result.  (If one goes further into t= he weeds, one finds product documentation claiming variables one can use to s= et the "Return-Path:" header's value, directly.)

I t= hink, in this light, the spec should say something.  Perhaps, even thou= gh it would be less elegant, rather than just refer to SMTP, it should make o= ne or two things explicit.

       - Chris

_______________________________________________
Jmap mailin= g list
Jmap@ietf.org
https:/= /www.ietf.org/mailman/listinfo/jmap
<= /div>
= --Apple-Mail-2EE8CAD6-824B-4CCA-AD83-B8F0AAE3DEF3-- From nobody Wed Aug 30 18:24:22 2017 Return-Path: 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 0DE5A126BFD for ; Wed, 30 Aug 2017 18:24:21 -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=Kvg1q3aK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ea4MX2iB 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 dqZ-FPTkEiaZ for ; Wed, 30 Aug 2017 18:24:18 -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 BAD061204DA for ; Wed, 30 Aug 2017 18:24:18 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id C39DB219B1; Wed, 30 Aug 2017 21:24:17 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 30 Aug 2017 21:24:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc: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=CqBFVm ufukFyGD0c5/VemS5LEi9RXaljGhVn49pvXJQ=; b=Kvg1q3aK3w4iOQPxNQ3K9M +SzGcv7uA4gmWVUJYYkxEesZfhsL3AldEMxXC6p/zIhx6gjnM4nqJtT2hA3a3AVE szCx5tICDdCqdikUKtbRQTHBxsiNvzM6aoY2EHJBtswzv7HvYcZwOFEygR6enktF flgxRoGj+HfyF/Yzm87wJg5kshGVH4NBHkQaYLU6mElug6P342fY0F6n2Pm7kwIn vcvAeCs3IezNNHVaOjLRuHc6oDY911N840az+wozvxEQBxR5zb9OjPtBoXDsktHU do4aK+YN675sLXQlTy5IBLedBZG81kcYa5e5tdsRx2W12DE0zE/e4oGlp1HNBLWQ == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=CqBFVm ufukFyGD0c5/VemS5LEi9RXaljGhVn49pvXJQ=; b=Ea4MX2iBMAmND5POXDH/b3 UfdSWCjGdohc5dRHy7xysPnrVGq+n4+4xpNJUIZZ4bl6T3dXfrI34USOAk1styU+ P91T1vlkZGuZVHxrGXJEUWDS/JaEcx6LaXPDsNgh4pIbmvvUHcTwjPVSejfjocmX chs7cuXwtpYFWq5Cu6jDDKETFp8jGivi67Nze0fOIBXbip45my1eGMrmYPr6WS/P IJ0Qz5eUu20TyoViL5Hsu8puiB/dc82FTtLrD5D7Ceor5WvoodjnWIJMCGacGXqf 0GsBHiRxvKHN1+1o4hTBnda2JmM7qHpwIP5PzY0Thz87weQ2pNewq113g+/LY+9A == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 7208FE2383; Wed, 30 Aug 2017 21:24:17 -0400 (EDT) Message-Id: <1504142657.4136419.1090521048.0D0A3C8E@webmail.messagingengine.com> From: Neil Jenkins To: Chris Newman Cc: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150414265741364191" X-Mailer: MessagingEngine.com Webmail Interface - ajax-dba1c099 References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> <0F44D4FC-52D0-47B2-A412-95B739B8FA85@oracle.com> Date: Thu, 31 Aug 2017 11:24:17 +1000 In-Reply-To: <0F44D4FC-52D0-47B2-A412-95B739B8FA85@oracle.com> Archived-At: Subject: Re: [Jmap] MessageSubmission last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 01:24:21 -0000 This is a multi-part message in MIME format. --_----------=_150414265741364191 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Tue, 29 Aug 2017, at 12:11 PM, Chris Newman wrote: > On the DeliveryStatus, I don't like having "isQueued" and > "delivered" as> separate properties because it allows a silly state (isQueued = true,> delivered = yes) Yes, agreed. > unknown: unknown or other status; additional information may be > present in DSN message for recipient. The smtpReply may or may not > change for this status. I think smtpReply is final in this status, since it has left the local mail queues (otherwise it would be in queued status)? Otherwise, I'm happy to go with this approach; I've pushed a change to the pull request. > I'm neutral on whether the other three DSN action values are included> {delayed, expanded, relayed}; they seem harmless as a client can just> treat them as synonyms for 'unknown' and helpful as clients that cared> wouldn't have to fetch & parse the DSN. But I understand there's a > desire to keep things simpler so I'm fine either way. Yeh, I don't feel super strongly on this, but would probably err on the side of omitting them to keep things simpler. Anyone else got a strong argument either way? > The "SHOULD NOT expose ... MDN messages" is fine. The "SHOULD > NOT expose> DSN" is a problem for failed DSNs because that means any client that > fails to build a UI for per-recipient DeliveryStatus / failed will > result in silently lost mail. I think hiding of failure DSNs > needs to be> a client-requested opt-in feature and clients MUST provide > users with a> mechanism to indicate delivery failure if the client requests that > feature. I'd be interested in other opinions on this point. I'm not a> fan of client opt-in features, but I don't see a better alternative in> this case. This sounds very awkward to me; the DSNs are either messages delivered to the inbox or they're not. Having them in the inbox except if the client opts out sounds way more trouble than it's worth. (You could easily add an implicit extra search term to the getMessageList filter clients send, but there's no easy way to deal with mailbox counts and quotas which would be affected by the messages that the clients couldn't see.) Whether the server should do this or not probably depends on how it expects the user to primarily access their mail. Perhaps we should change this all to a MAY: *JMAP servers MAY choose not to expose DSN and MDN responses as Message objects if they correlate to a MessageSubmission object. It SHOULD only do this if it exposes them in the dsnBlobIds and mdnblobIds fields instead, and expects the user to be using clients capable of fetching and displaying delivery status via the MessageSubmission object.* > For DeliveryStatus, I think we need some discussion about how status > for addresses that don't exactly match one of the rcptTo addresses are > reported. There are three cases: > 1. there's a single DSN that has an original recipient matching a > rcptTo address (but for a different actual recipient). Sorry, what do you mean "different actual recipient"? > 1. there are multiple DSNs with different addresses that match the > same original recipient. > 2. there are DSNs that don't match any original rcptTo.> I'd suggest servers may correlate for case 1, but I think case 2 & 3 > should be punted (the server doesn't correlate DSN; it just leaves it > in the INBOX). Punting on case 1 is also ok. But the spec needs to > advise on the correlation model to get consistent behavior. Can you suggest some text for the spec for this? You're much more familiar with DSNs than I am. Thanks. > For smtpReply, how should the JMAP server deal with multi-line > responses? Good point. I've added this: Multi-line SMTP responses should be concatenated to a single string as follows: * The hyphen following the SMTP code on all but the last line is replaced with a space. * Any prefix in common with the first line is stripped from lines after the first. * CRLF is replaced by a space. For example: 550-5.7.1 Our system has detected that this message is 550 5.7.1 likely spam, sorry. would become: 550 5.7.1 Our system has detected that this message is likely spam, sorry. > And some nits: Thanks, fixed. Neil. --_----------=_150414265741364191 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Tue, 29 Aug 2017, at 12:11 PM, Chris Newman wrote:
On the DeliveryStatus, I don't like having "isQueued" and "delivered" as
separate properties because it allows a silly state (isQueued = true,
delivered = yes)

Yes, agreed.

unknown: unknown or other status; additional information may be
present in DSN message for recipient. The smtpReply may or may not
change for this status.

I think smtpReply is final in this status, since it has left the local mail queues (otherwise it would be in queued status)? Otherwise, I'm happy to go with this approach; I've pushed a change to the pull request.

I'm neutral on whether the other three DSN action values are included
{delayed, expanded, relayed}; they seem harmless as a client can just
treat them as synonyms for 'unknown' and helpful as clients that cared
wouldn't have to fetch & parse the DSN. But I understand there's a
desire to keep things simpler so I'm fine either way.

Yeh, I don't feel super strongly on this, but would probably err on the side of omitting them to keep things simpler. Anyone else got a strong argument either way?

The "SHOULD NOT expose ... MDN messages" is fine. The "SHOULD NOT expose
DSN" is a problem for failed DSNs because that means any client that
fails to build a UI for per-recipient DeliveryStatus / failed will
result in silently lost mail. I think hiding of failure DSNs needs to be
a client-requested opt-in feature and clients MUST provide users with a
mechanism to indicate delivery failure if the client requests that
feature. I'd be interested in other opinions on this point. I'm not a
fan of client opt-in features, but I don't see a better alternative in
this case.

This sounds very awkward to me; the DSNs are either messages delivered to the inbox or they're not. Having them in the inbox except if the client opts out sounds way more trouble than it's worth. (You could easily add an implicit extra search term to the getMessageList filter clients send, but there's no easy way to deal with mailbox counts and quotas which would be affected by the messages that the clients couldn't see.)

Whether the server should do this or not probably depends on how it expects the user to primarily access their mail. Perhaps we should change this all to a MAY:

JMAP servers MAY choose not to expose DSN and MDN responses as Message objects if they correlate to a MessageSubmission object. It SHOULD only do this if it exposes them in the dsnBlobIds and mdnblobIds fields instead, and expects the user to be using clients capable of fetching and displaying delivery status via the MessageSubmission object.

For DeliveryStatus, I think we need some discussion about how status for addresses that don't exactly match one of the rcptTo addresses are reported. There are three cases:
  1. there's a single DSN that has an original recipient matching a rcptTo address (but for a different actual recipient).

Sorry, what do you mean "different actual recipient"?

  1. there are multiple DSNs with different addresses that match the same original recipient.
  2. there are DSNs that don't match any original rcptTo.
I'd suggest servers may correlate for case 1, but I think case 2 & 3 should be punted (the server doesn't correlate DSN; it just leaves it in the INBOX). Punting on case 1 is also ok. But the spec needs to advise on the correlation model to get consistent behavior.

Can you suggest some text for the spec for this? You're much more familiar with DSNs than I am. Thanks.

For smtpReply, how should the JMAP server deal with multi-line
responses?

Good point. I've added this:

Multi-line SMTP responses should be concatenated to a single string as follows:
  • The hyphen following the SMTP code on all but the last line is replaced with a space.
  • Any prefix in common with the first line is stripped from lines after the first.
  • CRLF is replaced by a space.

For example:

            550-5.7.1 Our system has detected that this message is
            550 5.7.1 likely spam, sorry.

would become:

            550 5.7.1 Our system has detected that this message is likely spam, sorry.

And some nits:

Thanks, fixed.

Neil.
--_----------=_150414265741364191-- From nobody Wed Aug 30 18:38:50 2017 Return-Path: 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 D2DE0132256 for ; Wed, 30 Aug 2017 18:38:48 -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=F3/t4dJK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WL4H7AQQ 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 VDKTSxNoJ-CJ for ; Wed, 30 Aug 2017 18:38:47 -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 62F5413219A for ; Wed, 30 Aug 2017 18:38:47 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id D46BF219DA; Wed, 30 Aug 2017 21:38:46 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Wed, 30 Aug 2017 21:38:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc: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=wZPeLX H4XhmnHj/TLTwzCJ6K6W3AYWd5StYDbXqDoD8=; b=F3/t4dJKasMCziu2q5X/SZ 9xkg6AGTmeGmx7vUw3UuCLO3Ngtecbeocmyen6Vq0sDPdi8YlC6GZRd65t+619MA ehUSy6O1Xcej6vWeh8YV/REaXiGRUDqSupJ1mi0z4KLI4TDXHOWljDeTHaXqE6+o qrfq/sH0spBEYmYAX1uxB4mGqxKyt/BXWDOg1DW+8Q6V+HuJ8fK8tzr2suPDmSQR pwQV1a+sE66XAOrvkFvPi4QXQVtUpEV+a2JPCx5z5cW/11LLGD/P6+i3ZcLMn+2w tVGzDFqQ+FCDVmhvU/k2mvYuHNPqFyc+pI4m46hwsBXnpB+ODy/0lY470e6yll0A == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=wZPeLX H4XhmnHj/TLTwzCJ6K6W3AYWd5StYDbXqDoD8=; b=WL4H7AQQ4bI983qENAsF6X f/eaEzYArfBc+AyMNhM0oUI6RXwykVhZ+Qc7smwK/5oDqotDKI6xy2HmyF+tF6q6 EfQVgY0mcE8xfSAWTLQ92/IyDDyr49R1yj83lwTu9/2DpoCDACli1kIM1naKVnql /5qP2eLfcFq7fn3H54p45Axvc4gT7KgbmvEh3KZn/y07u4npxuPrlVR6toRpKQnh cmcl9q4X04LcOUHyMv8WjJW+rqC0VTyuiHgqpVbxbbKnynxwCAeO2ee5uFSJGJ0y P0+K4/ddZguIos9EuKD6xt74yJkhBCN4nSBTpn6hBs+XupB3b17q/DAHuWF84oPQ == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8F838E2383; Wed, 30 Aug 2017 21:38:46 -0400 (EDT) Message-Id: <1504143526.4159271.1090530528.43C23F38@webmail.messagingengine.com> From: Neil Jenkins To: Stan Kalisch Cc: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_150414352641592710" X-Mailer: MessagingEngine.com Webmail Interface - ajax-dba1c099 Date: Thu, 31 Aug 2017 11:38:46 +1000 In-Reply-To: References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> <00E74483-7E9F-4728-A23B-6AD2989C3521@glyphein.mailforce.net> <53D71EC1-E19C-4DCE-B5A8-FB1C85EC143A@oracle.com> Archived-At: Subject: Re: [Jmap] MessageSubmission last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 01:38:49 -0000 This is a multi-part message in MIME format. --_----------=_150414352641592710 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Wed, 30 Aug 2017, at 06:08 AM, Stan Kalisch wrote: > I think, in this light, the spec should say something. Perhaps, even > though it would be less elegant, rather than just refer to SMTP, it > should make one or two things explicit. I'm not sure this is necessary; if we start providing advice about correct use of SMTP the spec length will greatly increase, and it's not directly relevant to JMAP specifically. Having said that, do you have a suggested text you would like to see in the spec? We can then consider that on the list. Cheers, Neil. --_----------=_150414352641592710 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Wed, 30 Aug 2017, at 06:08 AM, Stan Kalisch wrote:
I think, in this light, the spec should say something.  Perhaps, even though it would be less elegant, rather than just refer to SMTP, it should make one or two things explicit.

I'm not sure this is necessary; if we start providing advice about correct use of SMTP the spec length will greatly increase, and it's not directly relevant to JMAP specifically. Having said that, do you have a suggested text you would like to see in the spec? We can then consider that on the list.

Cheers,
Neil.
--_----------=_150414352641592710-- From nobody Wed Aug 30 20:20:19 2017 Return-Path: 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 6A42C126BFD for ; Wed, 30 Aug 2017 20:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=BpUd+HWE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eTQxihdd 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 SeYR4g_G7plA for ; Wed, 30 Aug 2017 20:20:16 -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 2E3B8126E64 for ; Wed, 30 Aug 2017 20:20:16 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 85AE820D68; Wed, 30 Aug 2017 23:20:15 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 30 Aug 2017 23:20:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=cc: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:x-sasl-enc; s=fm1; bh=VqXfO6 hMSRdwJyY7M2aGzjz4bF27jTDvmkCmjtpbn1k=; b=BpUd+HWEDogTAbEfVNP836 0xrZrMkO5yVphh7y0UrRLFdysyeK/Y0TZ+iw5fvWAwXrSQd7g69UH0lbs+uqJcDP NKoAeCA8Ro8wtkzuEFImknPm11XHaaVTLVHQ3CfCybVxsGhhv+NDOUtTJ1w6QGVU vlZ8VcDy0xEnXu3TcldOm0/9F1YNvrK9LxmnqB55He3owws+41Ob2n31DSkTJ31J jSXqwGO2rodePnjcdEBTxTJyn/elS7DibhRDA1lpqcan1TbX0pXeeBFRbRXpBbw6 B0KYiu4KxwPfdqAj1VlPYH2xBBk3ET5kyHg1JIui2pVJMPaNYbcHS1+5BLKFP4jg == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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:x-sasl-enc; s= fm1; bh=VqXfO6hMSRdwJyY7M2aGzjz4bF27jTDvmkCmjtpbn1k=; b=eTQxihdd B5Yi/2iivVWvV2vHuYA1S8exIRVMmJYuM7yANq51dCatEv1BaKjVBljW5lvq6ixY k1qmwKfaM5OXyQwQDXV85Xtyy+TAX1q4gQjRW+yD34e0FYaw0iVBEZdPl3FFeSs+ wWSSRaCw65TH2CPbEcLwuceoyvIq8zlbfA4Szflq2Ela+jH3b/tlFVwBKgOhrsmH XQK8jEAsab9fEJis4HZvDKGQ7CmA66qv4WkQCPuMA1Pr98TujxdWdu+N7CXOLvAu xM/o0L6EgITzb+HIkgurOYg/gF2yniE64gQ0uHj0XOzcwl1gU4aRy9mEGSPHy/2J 4hE3rUplOMl1CQ== X-ME-Sender: X-Sasl-enc: Y+DvAKUV6lFpjYnsy/ovIXF8mSs35EU0M2Y1p1HpaArN 1504149615 Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id 14F707E542; Wed, 30 Aug 2017 23:20:15 -0400 (EDT) References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> <00E74483-7E9F-4728-A23B-6AD2989C3521@glyphein.mailforce.net> <53D71EC1-E19C-4DCE-B5A8-FB1C85EC143A@oracle.com> <1504143526.4159271.1090530528.43C23F38@webmail.messagingengine.com> In-Reply-To: <1504143526.4159271.1090530528.43C23F38@webmail.messagingengine.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <254E0102-A637-4BA0-83AB-DD93B5691402@glyphein.mailforce.net> Cc: jmap@ietf.org X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Wed, 30 Aug 2017 23:20:12 -0400 To: neilj@fastmailteam.com Archived-At: Subject: Re: [Jmap] MessageSubmission last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 03:20:18 -0000 Hi Neil, >> On Aug 30, 2017, at 9:38 PM, Neil Jenkins wrote:= >>=20 >> On Wed, 30 Aug 2017, at 06:08 AM, Stan Kalisch wrote: >> I think, in this light, the spec should say something. Perhaps, even tho= ugh it would be less elegant, rather than just refer to SMTP, it should make= one or two things explicit. >=20 > I'm not sure this is necessary; if we start providing advice about correct= use of SMTP the spec length will greatly increase, and it's not directly re= levant to JMAP specifically. I personally agree that it's not directly relevant and have no qualms if tha= t's the way you want to go. > Having said that, do you have a suggested text you would like to see in th= e spec? We can then consider that on the list. Something brief, possibly even as short as this: > The server MUST NOT generate the *mailFrom* property from the email in the= "Return-Path" header field, if present in the referenced message. Does this work? (I really have no opinion on "MUST NOT" vs. "SHOULD NOT" fo= r this language.) Thanks, Stan From nobody Wed Aug 30 22:13:15 2017 Return-Path: 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 AEE0C126BFD for ; Wed, 30 Aug 2017 22:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mL8kpajrjzy8 for ; Wed, 30 Aug 2017 22:13:10 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983A21328EA for ; Wed, 30 Aug 2017 22:13:10 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v7V5D7UX020445 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 31 Aug 2017 05:13:07 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v7V5D6YR031246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 31 Aug 2017 05:13:07 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v7V5D6jr006562; Thu, 31 Aug 2017 05:13:06 GMT Received: from [10.154.178.61] (/10.154.178.61) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 30 Aug 2017 22:13:05 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: "IETF JMAP Mailing List" Date: Wed, 30 Aug 2017 22:13:03 -0700 Message-ID: <2B534D34-C93A-4D04-86B9-0989C97F18AB@oracle.com> In-Reply-To: <1504142657.4136419.1090521048.0D0A3C8E@webmail.messagingengine.com> References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> <0F44D4FC-52D0-47B2-A412-95B739B8FA85@oracle.com> <1504142657.4136419.1090521048.0D0A3C8E@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: Re: [Jmap] MessageSubmission last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 05:13:13 -0000 On 30 Aug 2017, at 18:24, Neil Jenkins wrote: > On Tue, 29 Aug 2017, at 12:11 PM, Chris Newman wrote: >> On the DeliveryStatus, I don't like having "isQueued" and >> "delivered" as> separate properties because it allows a silly state >> (isQueued = true,> delivered = yes) > > Yes, agreed. > >> unknown: unknown or other status; additional information may be >> present in DSN message for recipient. The smtpReply may or may not >> change for this status. > > I think smtpReply is final in this status, since it has left the > local mail queues (otherwise it would be in queued status)? It could be in a remote mail queue that supports the DSN extension, so a subsequent notification of successful delivery via a DSN can still happen. > Otherwise, I'm happy to go with this approach; I've pushed a change > to the pull request. >> I'm neutral on whether the other three DSN action values are >> included> {delayed, expanded, relayed}; they seem harmless as a >> client can just> treat them as synonyms for 'unknown' and helpful as >> clients that cared> wouldn't have to fetch & parse the DSN. But I >> understand there's a >> desire to keep things simpler so I'm fine either way. > > Yeh, I don't feel super strongly on this, but would probably err on > the > side of omitting them to keep things simpler. Anyone else got a strong > argument either way? >> The "SHOULD NOT expose ... MDN messages" is fine. The "SHOULD >> NOT expose> DSN" is a problem for failed DSNs because that means any >> client that >> fails to build a UI for per-recipient DeliveryStatus / failed will >> result in silently lost mail. I think hiding of failure DSNs >> needs to be> a client-requested opt-in feature and clients MUST >> provide >> users with a> mechanism to indicate delivery failure if the client >> requests that >> feature. I'd be interested in other opinions on this point. I'm not >> a> fan of client opt-in features, but I don't see a better >> alternative in> this case. > > This sounds very awkward to me; the DSNs are either messages delivered > to the inbox or they're not. Having them in the inbox except if the > client opts out sounds way more trouble than it's worth. (You could > easily add an implicit extra search term to the getMessageList filter > clients send, but there's no easy way to deal with mailbox counts and > quotas which would be affected by the messages that the clients > couldn't see.) > Whether the server should do this or not probably depends on how it > expects the user to primarily access their mail. Perhaps we should > change this all to a MAY: > *JMAP servers MAY choose not to expose DSN and MDN responses as > Message > objects if they correlate to a MessageSubmission object. It SHOULD > only > do this if it exposes them in the dsnBlobIds and mdnblobIds fields > instead, and expects the user to be using clients capable of fetching > and displaying delivery status via the MessageSubmission object.* I can personally live with that wording, but it may make other reviewers uncomfortable. >> For DeliveryStatus, I think we need some discussion about how status >> for addresses that don't exactly match one of the rcptTo addresses >> are >> reported. There are three cases: >> 1. there's a single DSN that has an original recipient matching a >> rcptTo address (but for a different actual recipient). > Sorry, what do you mean "different actual recipient"? Suppose I send an email to jdoe@forwarder.example.com, I can get a DSN containing this: Original-Recipient: rfc822;jdoe@forwarder.example.com Final-Recipient: john.doe@mailstore.example.net Action: delivered Status: 250 So is that DSN left in the INBOX because the final-recipient doesn't match a RCPT TO address, or does it get correlated into the MessageSubmission DSNs field based on the original-recipient field? >> 1. there are multiple DSNs with different addresses that match the >> same original recipient. >> 2. there are DSNs that don't match any original rcptTo.> I'd suggest >> servers may correlate for case 1, but I think case 2 & 3 >> should be punted (the server doesn't correlate DSN; it just leaves it >> in the INBOX). Punting on case 1 is also ok. But the spec needs to >> advise on the correlation model to get consistent behavior. > Can you suggest some text for the spec for this? You're much more > familiar with DSNs than I am. Thanks. Once we determine a model, I can suggest text. >> For smtpReply, how should the JMAP server deal with multi-line >> responses? > > Good point. I've added this: > > Multi-line SMTP responses should be concatenated to a single string > as follows: > * The hyphen following the SMTP code on all but the last line is > replaced with a space. > * Any prefix in common with the first line is stripped from lines > after > the first. > * CRLF is replaced by a space. > For example: > > 550-5.7.1 Our system has detected that this message is > 550 5.7.1 likely spam, sorry. > > would become: > > 550 5.7.1 Our system has detected that this message is > likely spam, sorry. Nicely worded. - Chris >> And some nits: > > Thanks, fixed. > > Neil. From nobody Wed Aug 30 23:31:31 2017 Return-Path: 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 34A3E13207A for ; Wed, 30 Aug 2017 23:31:30 -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=SXUWw3+e; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Z6WjMcvW 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 Posu7HFc4053 for ; Wed, 30 Aug 2017 23:31:28 -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 86E4F13218F for ; Wed, 30 Aug 2017 23:31:28 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id E558D22297; Thu, 31 Aug 2017 02:31:27 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 31 Aug 2017 02:31:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc: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=pc4FB0 kDjMz6Z4sUW+HXQW60UylRLTsIWSf+A0j92mQ=; b=SXUWw3+eyshfX04fdYA54+ +pUs0PQrCVK5kPJXw31euQ4dOo3+6qeKigKpLz0HGtWJ7wlGAmaewT5qt+HAH6Cd 34YtjlrYCvsoLEYSraSJ3fO2ZyYyvL4Jbob1fPOBxQwABVXkG7lgtZEBQctc3tS4 Rwx5PYf34pZD6Nzey/iX1t3R5wR+ffQxuniudDMslvCVpN0mQLwcIoqBUiwgurAd KYdHSjZDr490MqhhGzc6uBbqWFR26+ECjtj4P7s0gvz5VRYRH4P3r0YIkDPqN+7F jf+lLyalBJYBdAcnUFbdMDZX5r4V/bTa1a1lNIN6bUybvBFIL3Y6YAzXExJJSQbQ == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=pc4FB0 kDjMz6Z4sUW+HXQW60UylRLTsIWSf+A0j92mQ=; b=Z6WjMcvWXV5yNKU3XnX3VY /Ynha/OTGOA/Eq6TqR7XgMdPhl6Rg+/LHfrpK8GwCHoBhCEbiboGpedn0+b5iTI2 vAFDxS9Z2+E8cEl/Uk4lHKbjV0h+gNs8/G5SGLKRwSD2kjEYJsgoACFA959NDthd 7f7lJHq9OUcHOnVH3y6iZ779/qy4sB67igUJomR284E2rzpor7fPxdaXoKlF8ZUo /EH/0F4WPRKcj75IbAPPRz9FybwG3bwk4KiyJudazpkQ/p3oOMgcFalTirCaEfm4 SMLmXhLnE3sduUdBxlrkJjjwAgn03odv369gbOITMX2wfFfq6cSGyRmow7h/MhAw == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 9DD4EE23D3; Thu, 31 Aug 2017 02:31:27 -0400 (EDT) Message-Id: <1504161087.242402.1090702816.36084ECD@webmail.messagingengine.com> From: Neil Jenkins To: Chris Newman Cc: IETF JMAP Mailing List MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15041610872424020" X-Mailer: MessagingEngine.com Webmail Interface - ajax-dba1c099 References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> <0F44D4FC-52D0-47B2-A412-95B739B8FA85@oracle.com> <1504142657.4136419.1090521048.0D0A3C8E@webmail.messagingengine.com> <2B534D34-C93A-4D04-86B9-0989C97F18AB@oracle.com> In-Reply-To: <2B534D34-C93A-4D04-86B9-0989C97F18AB@oracle.com> Date: Thu, 31 Aug 2017 16:31:27 +1000 Archived-At: Subject: Re: [Jmap] MessageSubmission last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 06:31:30 -0000 This is a multi-part message in MIME format. --_----------=_15041610872424020 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, 31 Aug 2017, at 03:13 PM, Chris Newman wrote: > On 30 Aug 2017, at 18:24, Neil Jenkins wrote: >> I think smtpReply is final in this status, since it has left the >> local mail queues (otherwise it would be in queued status)? > It could be in a remote mail queue that supports the DSN > extension, so a> subsequent notification of successful delivery via a DSN can still > happen. Sure, but it's not going to get a new SMTP reply code, so the *smtpReply* property is final. The *delivered* property can still change from "unknown" to "delivered" should a DSN arrive. > I can personally live with that wording, but it may make other > reviewers uncomfortable. The other option I see is to cut the line altogether (servers may of course do it anyway; the spec doesn't say you can't). > So is that DSN left in the INBOX because the final-recipient doesn't > match a RCPT TO address, or does it get correlated into the > MessageSubmission DSNs field based on the original-recipient field? I would say this should be correlated based on the original-recipient field, so this would be considered a successful delivery. Cheers, Neil. --_----------=_15041610872424020 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, 31 Aug 2017, at 03:13 PM, Chris Newman wrote:
On 30 Aug 2017, at 18:24, Neil Jenkins wrote:
I think smtpReply is final in this status, since it has left the
local mail queues (otherwise it would be in queued status)?
It could be in a remote mail queue that supports the DSN extension, so a
subsequent notification of successful delivery via a DSN can still
happen.

Sure, but it's not going to get a new SMTP reply code, so the smtpReply property is final. The delivered property can still change from "unknown" to "delivered" should a DSN arrive.

I can personally live with that wording, but it may make other reviewers uncomfortable.

The other option I see is to cut the line altogether (servers may of course do it anyway; the spec doesn't say you can't).

So is that DSN left in the INBOX because the final-recipient doesn't match a RCPT TO address, or does it get correlated into the MessageSubmission DSNs field based on the original-recipient field?

I would say this should be correlated based on the original-recipient field, so this would be considered a successful delivery.

Cheers,
Neil.
--_----------=_15041610872424020-- From nobody Wed Aug 30 23:34:47 2017 Return-Path: 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 6ED6F13218F for ; Wed, 30 Aug 2017 23:34:46 -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=pdZThA/7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Nd/2HlaR 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 3Wx6a9uSWI9G for ; Wed, 30 Aug 2017 23:34:45 -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 612A713201E for ; Wed, 30 Aug 2017 23:34:37 -0700 (PDT) Received: from betaweb1.internal (betaweb1.nyi.internal [10.202.2.10]) by mailout.nyi.internal (Postfix) with ESMTP id C977D21FE1; Thu, 31 Aug 2017 02:34:36 -0400 (EDT) Received: from betaweb1 ([::ffff:10.202.2.10]) by betaweb1.internal (MEProxy); Thu, 31 Aug 2017 02:34:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=cc: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=pdvP3n LjwiNvooN9JE+BI5jvNsLts6a5pXV9e3Bsn10=; b=pdZThA/7j1svppk/KrtJW9 OyS9MrX3+s+FUbevwQNTXXyGKBv26yyJPw2HXIFhfCWE6MRA5zE75hoGbm0hSx95 f2k7KMlAk3MVgxDDne4lYhuDOzPWIUw/GNHhA3x+9ZnSpKSJbWfMZTMIWtvPjJCc jRMCgBDF0d8OrQ3j3b2fRLkfDOe5fECZJK6QpO0ej4cUndIzkBwfQHsu6ZBY2x7T CxgywNzAxXkus0QTb1W75hD8p6kP7sxfuDBNVZnfCrLWsuzdAm9KX87FZXartUVD 79H5INeuMGW5GmQBjQ+Whn8ceS4qOcWxLuCx0bWZ+UgfZyfUmdbK5jr2SdWUQwVQ == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=pdvP3n LjwiNvooN9JE+BI5jvNsLts6a5pXV9e3Bsn10=; b=Nd/2HlaRUIOCVB6nEXJ7sg 7WmzfqcZGBd/Yq0Cc1dKBX3chjylvlwsQATYhblSaruNPLcmMiuXVpdfOQ5WikT4 F6fWd+wnow/3GkXR9z7dyFRp3daxOlU+JI+bqoZE/55uuSWegZc97G4x6fmrXeFr 9ek45Zvi+9WClrDpjAdZPbsQNEDuZJF8QQlIBJEHpEf97ZC+NhYeKdvJa3e6+U/O JsfS6lg1PzpkUuJmbsekrrfgn857hTrioBjqKCOF5EZ7xjN9g5aQfPtYrEM6yCoy lpWUk4bC3y3lH2qtoVXlQKohLGiJF+EnOwUYVdC/cnRwQcI2Er0Rp53spkUYyVsg == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 8339AE23D3; Thu, 31 Aug 2017 02:34:36 -0400 (EDT) Message-Id: <1504161276.228386.1090707248.05BACDB5@webmail.messagingengine.com> From: Neil Jenkins To: Stan Kalisch Cc: jmap@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary="_----------=_15041612762283860" X-Mailer: MessagingEngine.com Webmail Interface - ajax-dba1c099 References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> <00E74483-7E9F-4728-A23B-6AD2989C3521@glyphein.mailforce.net> <53D71EC1-E19C-4DCE-B5A8-FB1C85EC143A@oracle.com> <1504143526.4159271.1090530528.43C23F38@webmail.messagingengine.com> <254E0102-A637-4BA0-83AB-DD93B5691402@glyphein.mailforce.net> In-Reply-To: <254E0102-A637-4BA0-83AB-DD93B5691402@glyphein.mailforce.net> Date: Thu, 31 Aug 2017 16:34:36 +1000 Archived-At: Subject: Re: [Jmap] MessageSubmission last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 06:34:46 -0000 This is a multi-part message in MIME format. --_----------=_15041612762283860 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" On Thu, 31 Aug 2017, at 01:20 PM, Stan Kalisch wrote: >> The server MUST NOT generate the **mailFrom** property from the email >> in the "Return-Path" header field, if present in the referenced >> message.> Does this work? It seems superfluous to me, because there's already a very specific algorithm in the spec for how to generate the mailFrom if the envelope is not supplied, and as it doesn't reference the Return-Path header, using this would already be a clear violation of the spec. Neil. --_----------=_15041612762283860 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="utf-8"
On Thu, 31 Aug 2017, at 01:20 PM, Stan Kalisch wrote:
The server MUST NOT generate the *mailFrom* property from the email in the "Return-Path" header field, if present in the referenced message.
Does this work?

It seems superfluous to me, because there's already a very specific algorithm in the spec for how to generate the mailFrom if the envelope is not supplied, and as it doesn't reference the Return-Path header, using this would already be a clear violation of the spec.

Neil.
--_----------=_15041612762283860-- From nobody Thu Aug 31 10:56:55 2017 Return-Path: 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 11C931321DE for ; Thu, 31 Aug 2017 10:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 y_G5JMjv1MCI for ; Thu, 31 Aug 2017 10:56:52 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 873BE1200F3 for ; Thu, 31 Aug 2017 10:56:52 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v7VHulvQ026961 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 31 Aug 2017 17:56:48 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id v7VHulXg012904 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 31 Aug 2017 17:56:47 GMT Received: from abhmp0009.oracle.com (abhmp0009.oracle.com [141.146.116.15]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v7VHukBw022603; Thu, 31 Aug 2017 17:56:46 GMT Received: from [10.154.170.78] (/10.154.170.78) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 31 Aug 2017 10:56:46 -0700 From: "Chris Newman" To: "Neil Jenkins" Cc: "IETF JMAP Mailing List" Date: Thu, 31 Aug 2017 10:56:38 -0700 Message-ID: In-Reply-To: <1504161087.242402.1090702816.36084ECD@webmail.messagingengine.com> References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> <0F44D4FC-52D0-47B2-A412-95B739B8FA85@oracle.com> <1504142657.4136419.1090521048.0D0A3C8E@webmail.messagingengine.com> <2B534D34-C93A-4D04-86B9-0989C97F18AB@oracle.com> <1504161087.242402.1090702816.36084ECD@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [Jmap] MessageSubmission last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 17:56:54 -0000 On 30 Aug 2017, at 23:31, Neil Jenkins wrote: > On Thu, 31 Aug 2017, at 03:13 PM, Chris Newman wrote: >> On 30 Aug 2017, at 18:24, Neil Jenkins wrote: >>> I think smtpReply is final in this status, since it has left the >>> local mail queues (otherwise it would be in queued status)? >> It could be in a remote mail queue that supports the DSN >> extension, so a> subsequent notification of successful delivery via a >> DSN can still >> happen. > > Sure, but it's not going to get a new SMTP reply code, so the > *smtpReply* property is final. The *delivered* property can still > change > from "unknown" to "delivered" should a DSN arrive. Actually, the "status" and "diagnostic" fields in the DSN are a new SMTP reply so I presumed that would replace the old one. If you just want to save only the SMTP submission reply, or only SMTP replies seen by the local ADMD the field definition needs to say that. >> I can personally live with that wording, but it may make other >> reviewers uncomfortable. > The other option I see is to cut the line altogether (servers may of > course do it anyway; the spec doesn't say you can't). >> So is that DSN left in the INBOX because the final-recipient doesn't >> match a RCPT TO address, or does it get correlated into the >> MessageSubmission DSNs field based on the original-recipient field? > I would say this should be correlated based on the original-recipient > field, so this would be considered a successful delivery. Yes, but which address is used as the key in the map? Does the status appear under both addresses, or just the original recipient? - Chris From nobody Thu Aug 31 11:57:39 2017 Return-Path: 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 2C5191321AE for ; Thu, 31 Aug 2017 11:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mailforce.net header.b=EOplZR0c; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=CRhEJ5mh 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 dzSjCX6Y46_Y for ; Thu, 31 Aug 2017 11:57:36 -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 03CD81328DB for ; Thu, 31 Aug 2017 11:57:35 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 89E29209B4; Thu, 31 Aug 2017 14:57:34 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Thu, 31 Aug 2017 14:57:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailforce.net; h=cc: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:x-sasl-enc; s=fm1; bh=U0z4se AejjHvOwOGja0lzj1iWtD5iPEWS0yX27nwADA=; b=EOplZR0cttG47PS44dYMoe 7oMuKkbAZeED/9/OEwYyQ9+eAIcbxMTEI9k9MtyrVXsLuODFuv2zN9TBUYQcrLCI A/PfLobKSoAuq5JEGvHe1PUtfBL47K5j7MAYQqdT9ad4H/3n4YMBlt7bbOJUFeyE UtJMyIsH3tnZYHI9HVm7Pt7ngzBiv0K13WCY3qTR6m/PU6A4fre+hcxX2ZJmdTCY 0E9XgPeL/P+fYVS2XvTklMaPHH6vy9mZDXECQ4tcMpsw9a4FRFVJlMjXyClrzmY3 1MJ3m/yiWfodxLRF5G/htkMHY6IiawyzNgwKwyF0ks7XiGweeawiNu1vqHSnZUZg == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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:x-sasl-enc; s= fm1; bh=U0z4seAejjHvOwOGja0lzj1iWtD5iPEWS0yX27nwADA=; b=CRhEJ5mh 6pjdztKD+tKdzsAMavbmmU7Akcl7Zxa3oHqVCv0fkJQp+QC5IAySPxYhL/SX/p2q ZHU08gPTs9OzjMU3w3OnJZz1ke6poKnCdxGM3FbcIpq3MXGCddNAll45zOsluXRJ Gzj/BwYthzC4GXKPiu4UocdMvl9ROnhwHWzp3nMqi11w6Pcrnw36mmzsgPhZ/NJa sVKDdWh1IQaHiY1SverPYizkkCcAv/vOMr+QLPQJwGzjYEJOfcWKgxL9fDNZeDQ/ dCpUxVkDtBgjTPCyurVv8IZlVku+q4BH/KCpnN+wX1T1mYFbnWpnJVgXBFJTzQw9 fqWMqJK9FKqZxA== X-ME-Sender: X-Sasl-enc: 7N28Av4o6z+Ob97B9oxl1QH+Y1yOJbgMh2xDuHSJw4Xw 1504205854 Received: from [192.168.1.71] (108-84-31-27.lightspeed.tukrga.sbcglobal.net [108.84.31.27]) by mail.messagingengine.com (Postfix) with ESMTPA id 3001F7F9BC; Thu, 31 Aug 2017 14:57:34 -0400 (EDT) References: <1503884649.494525.1086840240.2E811968@webmail.messagingengine.com> <00E74483-7E9F-4728-A23B-6AD2989C3521@glyphein.mailforce.net> <53D71EC1-E19C-4DCE-B5A8-FB1C85EC143A@oracle.com> <1504143526.4159271.1090530528.43C23F38@webmail.messagingengine.com> <254E0102-A637-4BA0-83AB-DD93B5691402@glyphein.mailforce.net> <1504161276.228386.1090707248.05BACDB5@webmail.messagingengine.com> In-Reply-To: <1504161276.228386.1090707248.05BACDB5@webmail.messagingengine.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-BEA5667D-CF4B-4F01-BAA4-1A0354A2B66E Message-Id: <8E919058-A9CD-4001-AEB1-2040A506094B@glyphein.mailforce.net> Cc: jmap@ietf.org X-Mailer: iPhone Mail (13G36) From: Stan Kalisch Date: Thu, 31 Aug 2017 14:57:32 -0400 To: Neil Jenkins Archived-At: Subject: Re: [Jmap] MessageSubmission last call X-BeenThere: jmap@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: JSON Message Access Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 18:57:38 -0000 --Apple-Mail-BEA5667D-CF4B-4F01-BAA4-1A0354A2B66E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable > On Aug 31, 2017, at 2:34 AM, Neil Jenkins wrote: >=20 >> On Thu, 31 Aug 2017, at 01:20 PM, Stan Kalisch wrote: >> The server MUST NOT generate the *mailFrom* property from the email in th= e "Return-Path" header field, if present in the referenced message. >> Does this work? >=20 > It seems superfluous to me, because there's already a very specific algori= thm in the spec for how to generate the mail=46rom if the envelope is not su= pplied, You're right, and it's clear that I haven't communicated properly that I'm c= ognizant that what I'm trying to address isn't a technical necessity for the= spec. It seemed to me this was something feasible to incorporate without b= ecoming a nuisance, but after rereading your text for MessageSubmission, I n= ow agree it's something that gets in the way more than it helps. (It also s= eems the issue I raised seems to be of greater concern to me than anyone els= e, and that's fine.) In any event, it's not important enough of an issue to stop you from getting= this section out the door and merged. Thanks for your patience. Stan > and as it doesn't reference the Return-Path header, using this would alrea= dy be a clear violation of the spec. >=20 > Neil. > _______________________________________________ > Jmap mailing list > Jmap@ietf.org > https://www.ietf.org/mailman/listinfo/jmap --Apple-Mail-BEA5667D-CF4B-4F01-BAA4-1A0354A2B66E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On Aug 31, 2017, at 2:34 AM, Neil Jenkins <neilj@fastmailteam.com> wrote:

On Thu, 31 Aug 2017, at 01:20 PM, Stan Kalisch wrote:
The server MUST NOT generate the <= b>*mailFrom* property from the email in the "Return-Path" header field, i= f present in the referenced message.
Does this work?

It seems superfluous to me, because there's already a very specific alg= orithm in the spec for how to generate the mail=46rom if the envelope is not= supplied,

You're right, and it'= s clear that I haven't communicated properly that I'm cognizant that what I'= m trying to address isn't a technical necessity for the spec.  It seeme= d to me this was something feasible to incorporate without becoming a nuisan= ce, but after rereading your text for MessageSubmission, I now agree it's so= mething that gets in the way more than it helps.  (It also seems the is= sue I raised seems to be of greater concern to me than anyone else, and that= 's fine.)

In any event, it's not important enough o= f an issue to stop you from getting this section out the door and merged. &n= bsp;Thanks for your patience.


Stan
and as it doesn't reference the R= eturn-Path header, using this would already be a clear violation of the spec= .

Neil.
____________________= ___________________________
Jmap mailing list
Jmap@ietf.org
https://www.ietf.org/mailman= /listinfo/jmap
= --Apple-Mail-BEA5667D-CF4B-4F01-BAA4-1A0354A2B66E--