Re: [Jmap] Submission

[Ted Lemon <[e-mail]>]

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.

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.