Re: [Jmap] Submission

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

My first impression is that if we considered the entire gamut of ESMTP 
submission extensions, most would not be relevant for the client, and 
therefore most would not need to be reflected in JMAP.

The client should not care if the payload is sent chunked, whether the 
next hop server supports pipelining.  The only extensions would relate 
to the things the client needs to know in order to emit a properly 
formed message and envelope.  If we make delivery status updates a core 
(and mandatory) part of JMAP, whether the upstream SMTP infrastructure 
can support it or not is not particularly important.  The JMAP server 
can provide something regardless, and in a tightly-integrated system 
(e.g. one JMAP client sending mail to another on the same server) then 
the user experience can be excellent.  Even things like 8BITMIME should 
be the default, mandatory in the client<->JMAP server and if the 
upstream SMTP system needs to redo the message then that's what it needs 
to do.  It's ridiculous we are still bound to a 7-bit-compatible mail 
transport where the only machines now that are 7 bit are in museums.

I think it would be a shame to get hung up on non-necessary SMTP 
extensions and use that as a justification to not progress on 
improvements.  We need to be sure that we have a realistic but useful 
set of minimum requirements which safeguard an excellent user 
experience, because we need to do better than what is currently there or 
this will not be adopted.

Adrien


------ Original Message ------
From: "Chris Newman" <[e-mail]>
To: "Brandon Long" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Sent: 21/04/2017 8:56:48 AM
Subject: Re: [Jmap] Submission

>On 19 Apr 2017, at 21:46, Brandon Long wrote:
>>On Wed, Apr 19, 2017 at 12:29 PM, Chris Newman 
>><[e-mail]>
>>wrote:
>>>Finally, if JMAP supports submission then I expect a client author 
>>>will
>>>want to use the JMAP submission mechanism for all submissions. If 
>>>JMAP has
>>>a rigid design where each submission extension requires an additional 
>>>JMAP
>>>extension then a high-end client will eventually be forced to 
>>>implement
>>>SMTP submission in addition to JMAP submission. And it will be stuck 
>>>doing
>>>both (the former for functionality, the latter for ease-of-setup). I 
>>>don't
>>>want JMAP clients to be forced down that path.
>>
>>Is there any proof that the majority of clients would bother? I 
>>realize
>>that's the argument that's always been made about including submission 
>>in
>>IMAP, but is there proof that the majority of clients used by people
>>implement these?
>
>Of course there is no proof related to future actions of third parties. 
>But semantic equivalent guarantees the problem won't happen.
>
>>I mean, SMTPUTF8, sure, should be a requirement for jmap.
>
>I'm unsure we should require all JMAP servers to support SMTPUTF8. I 
>presently don't have strong feelings one way or the other, but I think 
>there are a number of important tradeoffs that should be understood to 
>inform the decision.
>
>>>What this means is that for JMAP to support submission correctly, it 
>>>must
>>>be able to function as an SMTP submission proxy from a semantic 
>>>viewpoint.
>>>This creates a number of requirements. The basic requirements are:
>>>
>>>1. It must be possible to query the JMAP server for the set of 
>>>Submission
>>>ESMTP extensions semantically equivalent to the SMTP submission EHLO
>>>response. The JMAP server needs to omit the extensions that aren't 
>>>relevant
>>>(e.g., AUTH, STARTTLS, PIPELINING).
>>>2. It must be possible to provide an SMTP envelope for submission 
>>>that is
>>>semantically identical to the submission protocol. This needs to 
>>>support
>>>MAIL FROM, one or more RCPT TO, and ESMTP parameters to those 
>>>envelope
>>>components. There needs to be an algorithmic way to convert from JMAP
>>>envelope syntax to SMTP Submission envelope syntax.
>>>3. It must be possible to get submission errors that are semantically
>>>identical to those provided by a submission server. Including at 
>>>least
>>>3-digit SMTP code, optionally enhanced SMTP code and human readable 
>>>text of
>>>error and potentially one response for mail from, one for each rcpt 
>>>to and
>>>one for data/bdat final response.
>>
>>Why?
>
>These three requirements would give JMAP semantic equivalence to 
>standard IETF Submission, which preserves functional separation 
>(improving scalability and security/privacy models), and simplifies 
>deployment in sites with existing submit servers (which is presently 
>all sites). I don't think 1 or 2 should be controversial. Some debate 
>about item 3 may be appropriate.
>
>>>So that's the submission functionality JMAP needs to provide if it
>>>provides submission at all. If you want to also provide a simpler 
>>>model for
>>>submission in JMAP, I won't object as long as the full model is 
>>>mandatory.
>>
>>Maybe that's the simplest way to avoid the argument.
>
>Debating the technical tradeoffs between different proposals is an 
>important part of getting a good standard. If you think I'm wrong, it'd 
>be good to explain the alternate viewpoint and technical reasoning 
>behind that viewpoint. As I work on server software products, I tend to 
>have some server bias in designs but I recognize there are tradeoffs 
>between ease-of-development/ease-of-deployment for server vs. client 
>software. As a long time IETF participant, I also view 
>IMAP+Submission+standard-extensions as the starting point for JMAP 
>design. That's a different viewpoint from people who view the problem 
>entirely from the client viewpoint and ignore the constraints of 
>presently deployed infrastructure. A good JMAP standard should probably 
>end up somewhere in the middle.
>
>   - Chris
>
>_______________________________________________
>Jmap mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/jmap