Re: [Jmap] Submission is not hard

[Ned Freed <[e-mail]>]

> In article <[e-mail]> you write:
> >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.

> Um, this is the IETF.  If you want to invent a new, different, and
> incompatible mail system, JMAP is definitely not the place to do so.

> I am scratching my head about why people are having such trouble with
> the submission model.  It's not complicated.  The message goes into a
> queue, the envelope and message are separate, the envelope addresses
> can have annotations, and the server tells the client what optional
> features it supports.  That's it.  The options are, you know,
> optional, but many of them are useful.

Exactly right. And the envelope format can and should be dead easy to generate
- dare I suggest using JSON? - making this quite easy for clients to do.

> Before someone suggests that we should use some better scheme, I would
> point out that a lot of mail transport designs have come and gone over
> the past 40 years, and all of the others are dead.  You're going to
> need a really good story about why this time is different.

Having spent considerable time implementing most of the other designs that have
come and gone over the years, one of the conclusions I've reached is that full
envelope separation is a key design principle along the same lines as the
end-to-end principle. It's a shame it isn't recognized as such.

				Ned