As someone fairly well-versed in the email ecosystem, I don't understand this proposal, like, at all. - Is it even federated? It seems like not--it seems like

As someone fairly well-versed in the email ecosystem, I don't understand this proposal, like, at all. - Is it even federated? It seems like not--it seems like it's proposing a protocol for organizations to use to run their own messaging service in-house? - If it's not, this doesn't really get at either the _interesting_ parts of email--the universal federation--or what makes it _hard_. (The reason email has spam, authentication, and confidentiality problems really boils down to the difficulty in securely establishing authoritative identities; this is why protocols like DANE, DMARC, DKIM, SPF, and MTA-STS are tacked on top.) - If it is, the documentation is woefully underemphasizing this point. :) - The proposal (as others have noted) seems to mix application features with message delivery. This doesn't seem useful. - Instead of using encryption, the proposal says that "To prevent theft of correspondence (in the event of a compromised account or server) the messaging service must store only messages that have not yet been delivered". This is...a really problematic design choice. - The proposal suggests a bunch of reasonable application features which many email providers (at the MTA or MUA level) do already support (like "blocking anyone", "selecting [who] can correspond with you", etc). Email is fully compatible with these features! - Conversely, the proposal suggests some features which are not obviously satisfied by the proposal itself, like "always know from which site a message originated." Again, where is identity even discussed? To be blunt, this proposal doesn't seem like it was written with an eye to what's actually challenging about email. The fact that SMTP is not JSON is really not a significant problem; the focus of this proposal is just in the wrong place. To make this more constructive, I would suggest reading the IETF SMTP WG archives to understand the kinds of problems implementors and spec-authors face. I'm frankly pessimistic about the prospect for a wholesale (non-incremental) replacement of SMTP, but even as a design exercise, starting with what real implementors struggle with makes sense.