Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP

Ned Freed <ned.freed@mrochek.com> Fri, 11 November 2016 14:47 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D76AF129469 for <imapext@ietfa.amsl.com>; Fri, 11 Nov 2016 06:47:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Level:
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-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 Qa0ttF65owb3 for <imapext@ietfa.amsl.com>; Fri, 11 Nov 2016 06:47:18 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.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 9C5BA1299A1 for <imapext@ietf.org>; Fri, 11 Nov 2016 06:46:24 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q76JQRLHO000XJMT@mauve.mrochek.com> for imapext@ietf.org; Fri, 11 Nov 2016 06:41:18 -0800 (PST)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01Q75BN31BMO011WUX@mauve.mrochek.com>; Fri, 11 Nov 2016 06:41:15 -0800 (PST)
Message-id: <01Q76JQPJI2Q011WUX@mauve.mrochek.com>
Date: Fri, 11 Nov 2016 06:34:55 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 11 Nov 2016 11:47:35 +0000" <alpine.DEB.2.11.1611111136170.22672@grey.csi.cam.ac.uk>
References: <1478539079.1706686.780110457.75B1F9CF@webmail.messagingengine.com> <a786d82d-7134-c7bc-24ef-5dfb56e7bbac@isode.com> <01Q7166TP70G011H9Q@mauve.mrochek.com> <b85870ed-86e0-0f97-fece-476399124e81@isode.com> <01Q74JCZZYFG00Z4TS@mauve.mrochek.com> <E99C5826138657241662E74E@JcK-HP8200> <1478836665.322873.784300457.3FB705B7@webmail.messagingengine.com> <alpine.DEB.2.11.1611111136170.22672@grey.csi.cam.ac.uk>
To: Tony Finch <dot@dotat.at>
Archived-At: <https://mailarchive.ietf.org/arch/msg/imapext/vpjKjmgTrfeYrP9JgUiqOccdzww>
Cc: Neil Jenkins <neilj@fastmail.com>, imapext@ietf.org
Subject: Re: [imapext] [ietf-smtp] Fwd: Request to form a new WG: JMAP
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Nov 2016 14:47:19 -0000

> A few vague thoughts...

> One of the problems with separating message submission and storage is that
> there are a lot of tricky error handling and state transition issues as
> the message moves from Drafts -> Outbox -> Sent, rolling back properly if
> sending failed, partial failures for a subset of recipients, etc. It's not
> uncommon for users who have been having problems to say something like
> "but the message is in my Sent folder, it must have been sent!"

Problems which are exacerbated by using magic folders.

> Also, my experience of MUAs reporting SMTP errors to users doesn't fill me
> with confidence. The servers I used to run went to some effort to avoid
> SMTP-time errors as much as possible, preferring to accept and bounce.
> There's lots of scope to do much better in this area.

Actually, this varies enormously depending on where you are and what sorts of
clients you use. We offer both "accept and report errors later" and "report as
much as possible immediately" modes and we find our servers are overwhelmingly
configured to do the latter.
 
The problem with "accept and report errors later" is the lack of immediate
feedback. This, coupled with poor/nonexistent support for correlating DSNs with
sent messages, works so poorly that a client has to be truly terrible at
reporting errors at submit time for it to be viable.

But there are some truly terrible clients out there.

				Ned