Re: [Jmap] Submission

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

On 21 Apr 2017, at 7:34, Arnt Gulbrandsen wrote:
> Ted Lemon writes:
>> I think the distinction comes from whether you actually think that 
>> the SMTP submission protocol is always going to be what's behind a 
>> message submitted via JMAP.   If you think that, then it's going to 
>> look really weird to not just replicate that exact paradigm with the 
>> JMAP submission process.
>
> Hm?
>
> Won't the nexthop generally be the thing that the port-587 server 
> forwards to? After all, JMAP already handles authentication, and it's 
> not clear to me that a typical JMAP server is easily able to 
> authenticate on behalf of the end user in a way that a port-587 server 
> accepts.

There are lots of standard ways for a proxy to authenticate on behalf of 
another user to another server. SASL PLAIN over TLS is the most obvious, 
but a TLS client certificate plus SASL EXTERNAL also works. The OAuth 
SASL mechanism could also be useful if it was designed correctly (sorry, 
I haven't reviewed it in detail with respect to that use case).

My product's existing JMAP-like proxy is a JSON/HTTP to submission/IMAP 
proxy. One of the design errors that was made (back in the 1990s) was to 
not support submission extensions. This is one of the largest remaining 
design errors in our proxy and has caused significant problems. I do not 
want the JMAP standard to repeat the mistake we made.

> Assuming that JMAP forwards to the filter or smarthost, then requiring 
> that JMAP servers be able to forward SMTP extensions looks really odd. 
> A submission server on port 587 cannot forward SMTP extensions from 
> its nexthop, why should one on port 443 have to?

Submission servers do forward hop-to-hop extensions to the next hop. 
It's how they have to work. SMTP extensions like DELIVERBY, RRVS, 
SMTPUTF8, MTRK require hop-to-hop forwarding of SMTP parameters.

> The usual answer is "so as to not need a corresponding JMAP RFC 
> whenever there's a new SMTP RFC". That strikes me as poor. A new 
> extension requires an RFC and three kinds of implementations (SMTP 
> client, submission server, filter server). The RFC publication bit 
> isn't usually the bottleneck among those four.

We're going to need submission servers until all useful software is 
updated to use JMAP submission. I'd guess that at many sites that will 
never happen. So if we must have SMTP submission, then it's desirable to 
keep JMAP submission as close in semantics to SMTP submission as 
possible in order to minimize the attack surface and code complexity of 
the system. Yes, there are some specific tradeoffs where there might be 
a good reason to deviate from full submission semantics; for example, 
I'm unsure per-recipient status is useful to most clients so an option 
where any failed recipient results in failed submission would make sense 
to me in JMAP. And, of course, JMAP submission should be one round-trip 
and may have helpful side-effects like moving a message from the \Drafts 
folder to \Sent folder on success.

>> The point is that whichever choice we make, we are going to pay a 
>> price for it.   It's worth asking what that price is, and also asking 
>> what the advantages are to the choices we have, and then deciding on 
>> that basis.   The fact that we would pay a price for not replicating 
>> SMTP submission can definitely be taken as a given.
>
> +1
>
> Arnt

		- Chris