Re: [Jmap] Submission

["Chris Newman" <[e-mail]>]

On 19 Apr 2017, at 18:55, Ted Lemon wrote:
> On Apr 19, 2017, at 9:28 PM, Chris Newman <[e-mail]> 
> wrote:
>> To clarify my point, I think having an "outbox" with combined mail 
>> store and mail queue semantics as a mandatory architectural element 
>> of JMAP is a protocol design error because it breaks functional 
>> separation. And that violation of functional separation is 
>> particularly problematic in larger deployments where mail stores and 
>> mail queues each add management and monitoring complexity and require 
>> different designs and storage models to scale effectively.
>>
>> JMAP needs to have a submission action that has semantics matching 
>> the IETF Submission standard. It's fine for that command to pull data 
>> from the mail store as part of the submission action (as RFC 4468 
>> does). But the JMAP protocol needs to allow implementations where 
>> mail queue and mail store semantics are separate.
>
> Perhaps so.   However, the semantics of submission protocols aren't 
> really right either.   What I think we want is to tell the MUA that 
> delivery failed if it did, and to allow the MUA to know the current 
> status of delivery at least at the first hop, if delivery is not yet 
> complete.   But the SMTP submit protocol doesn't do this.   It's fire 
> and forget: all you get is confirmation that the message has been 
> queued.

There's RFC 3887 (Message Tracking Query Protocol). The product I work 
on has implemented that.

> Granting that the point of this working group is not to fix SMTP, the 
> semantics of the JMAP submit protocol ought to allow for delivery of 
> failure status without generating a needless bounce message just as a 
> place to put information from the site MTA's delivery attempt.

Agreed.

> If the failure happens farther down the line in a forwarding chain, we 
> can't do anything about it, but from a usability perspective bounce 
> messages are worse than useless, so anything that can reduce the 
> number of such messages that users see is a net win.

Bounce messages that are standards compliant are useful (and are 
frequently used to implement automatic un-subscription for mailing 
lists). But what I would say is that a mail client UI that shows bounce 
messages as "just another message in the INBOX" is not a good UI.

> The point that I am arguing is that sent messages really do have a 
> place in something that is notionally a mail store,

Draft Messages and Sent Messages belong in a mail store; the \Sent and 
\Draft RFC 6154 folders are well-within scope for JMAP.

> and those messages serve as a place where delivery status can be 
> found.

I'm generally supportive of this goal. However, I want the JMAP base 
spec to deploy quickly so I'd like to keep the amount of additional 
mandatory system complexity JMAP requires over-and-above Submission+IMAP 
to a minimum. I'm supportive of some additional complexity in exchange 
for ease-of-client development. But I don't think improved bounce 
handling is the right place to make that tradeoff in the base JMAP spec. 
Improved bounce handling could make a good JMAP extension.

		- Chris