Re: [Jmap] Submission

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

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.

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.

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.

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.

		- Chris