Re: [Jmap] Submission

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

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