Re: [Jmap] Submission

["Adrien de Croy" <[e-mail]>]

------ Original Message ------
From: "Ted Lemon" <[e-mail]>
To: "Chris Newman" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Sent: 20/04/2017 1:55:39 PM
Subject: Re: [Jmap] Submission

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

I'd love to see a mail client that does at least initial validation on 
destination email addresses as they are added to the message, so that 
errors in the addresses which can be resolved at that stage (e.g. 
NXDOMAIN) can be raised with the email author before the mail is even 
submitted.

Due to DNS issues, this may need to be handled on the server, but could 
be something as simple as an MX lookup, or something.  Late bounce 
messages relating to bad domain parts of an email address are 
ridiculously user-unfriendly and we could do so much better.

If we're doing a new mail protocol, we should be targeting the user 
experience we want, rather than just whatever it takes to replicate what 
we have maybe with fewer configuration points.

It should be possible in many cases to even give realtime updates about 
the delivery status of the message whilst it's sitting in some folder 
(whether that's outbox or sent) in the case where the JMAP server is 
also the SMTP client for delivery upstream.

I can imagine sitting at my desk after sending a mail, watching the 
status icon on the message go from submitted to connecting to delivered 
to destination mailbox.  Why not consider something like some way to 
give status updates back to the client for this kind of thing.

People are moving away from SMTP to things like Facebook messaging due 
to these sorts of reasons.  They focused on user experience.  If we 
don't then we are wasting our time.

Adrien

>
>
>The point that I am arguing is that sent messages really do have a 
>place in something that is notionally a mail store, and those messages 
>serve as a place where delivery status can be found.   Message 
>submission should not be a transaction: it should be a process.   
>Notification should work even if the MUA isn't present at the time of 
>failure, and should be available in all MUAs, not just the sending MUA. 
>It should be presentable to the user in a way that makes sense.   A 
>"sent" folder makes sense.   A separate queue construct does not.   
>Forcing the MUA to fake this isn't going to produce a good user 
>experience.
>