Re: [Jmap] Submission

[Brandon Long <[e-mail]>]

On Wed, Apr 19, 2017 at 12:29 PM, Chris Newman <[e-mail]>
wrote:

> The original IMAP designer always opposed adding submission to IMAP as a
> matter of functional separation. While I strongly agree with the need for
> functional specification, it is possible to design a protocol in such a way
> that multiple separable functions are provided in the same protocol. As a
> result I support adding submission to JMAP in a way that preserves
> functional separation.
>
> When deploying a large mail service it's important to keep the submission
> mail queues (which have management/monitoring issues) functionally separate
> from the mail store (which has very different management/monitoring
> issues). If the JMAP design requires a mail queue to be present on the JMAP
> server or present in the mail store, that is an unacceptable protocol
> design error as it hinders the manageability of large deployments.
>
> Furthermore, SMTP submission is a full standard IETF protocol that
> continues to be extended. JMAP should leverage the semantics of the
> existing standard in such a way that it's not necessary to change the JMAP
> specification when a new submission extension that's useful to JMAP is
> added. In addition to giving JMAP clients access to all the useful
> submission extensions like FUTURERELASE, UTF8SMTP, DELIVERBY, etc. This
> will ultimately make the JMAP specification simpler (as it won't have to
> deal with submission extensions directly) and more flexible to deploy.
>

SMTPUTF8 I presume.


> 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?  I mean, SMTPUTF8, sure, should be a requirement for jmap.

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?


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

Brandon