This document only addresses email submission and access because a single document that covered email submission, access, relaying, key lookup/verification, and message encryption would be huge and take forever to get consensus on. It made more sense to divide up the work. It just happens that this piece got finished first, probably because it's the simplest piece. Others are working on improving the security of relaying which is harder because in general there's no a priori explicit relationship between an SMTP client and an SMTP server relaying the message - so the client has no way to know on initial contact whether its connection with the server has been intercepted (which would allow the interceptor to downgrade the connection to cleartext and thwart automatic future use of TLS). But even when relaying is more secure, the messages will still be in the format submitted while being relayed, and after being delivered - i.e. usually cleartext.
Making whole message encryption work on a large scale, and incrementally deployable, is hard, because there are lots of corner cases to deal with. For instance, if you leave messages encrypted on the recipient's server, then the server can't assist in searching the text of those messages, which makes searching slow and especially bad for mobile devices. Or you want to know when sending a message if it's safe to encrypt it or not, but even if you define some service to query whether there's a public key associated with the recipient's domain name, that service may not work well if the recipient has their mail forwarded elsewhere. You want the message encryption service to be widely applicable but you also want the user interface to be simple - and corner cases complicate user interfaces.
Or you could start over from scratch (as has been and is being tried by others) and see how hard it is to displace the existing system without an incremental upgrade path. Hopefully we'll get there one way or another.
You don't need an email provider, you can just set up a mail server on your own computer. If the person you are sending your mail to also has their own mail server you send it directly to them without any provider every seeing it.
EDIT: Yes I know... It's not trivial to setup and keep running, "own computer" might need to mean hosted somewhere (VPS, datacenter, etc), and all your contacts might also need to setup mail servers because providers like Gmail might reject your mails. In the end it might not be worth your time, but there's absolutely no technical reason why you'd need a mail provider for emails.
Except that most consumer ISPs block outgoing traffic on port 25 to make spamming more difficult. So you won't be able to send mail directly to the recipient's SMTP server.
> You don't need an email provider, you can just set up a mail server on your own computer.
Not really. It's not possible to send mail from a dynamic IP at all, and there is a lot of technical minutia to not get thrown in the spam folder for major providers. In fact, many major providers simply assume mail sent from an unfamiliar domain and/or IP is spam by default, and you will have to contact them to ask for permission to send to them.
> and there is a lot of technical minutia to not get thrown in the spam folder for major providers. In fact, many major providers simply assume mail sent from an unfamiliar domain and/or IP is spam by default, and you will have to contact them to ask for permission to send to them.
These myths are popular, in my experience they are not true.
> These myths are popular, in my experience they are not true.
I am speaking from personal experience. I've run my own mail server for about 15 years.
A few months I had to publicly complain on twitter about Microsoft blocking my email in order to get them to stop putting my email in the spam folder (after having to move to a new IP). Their support people before I publicly complained just kept responding with a form letter with advice for commercial senders sending transactional, newsletter and marketing content.
I haven't asked anybody for permission, yet email still works. Just follow the basics. Reverse DNS, SPF and DKIM will instantly grant you a place in non-spam.
I just went through the pain of switching to a new IP for my mail server a few months ago.
All major providers except Google were putting my messages in the spam folder by default despite me getting myself whitelisted in DNSWL and having proper FcRDNS, SPF, DKIM and DMARC configuration.
The IP was not in any reputable public blacklists, and the domain had been in use for many years.
Yes, I did. It was clean as far as I could tell. It was not just Microsoft, I also had issues with Yahoo, AOL and some others. The block I'm in is listed in some RBL called "spamgrouper"[1] but as far as I can tell nobody pays attention to it. No other lists showed any trouble.
> ...and all your contacts might also need to setup mail servers
If you can already get your contacts to install software for you, why stay with email at all? You might as well use Telegram, SSB or whatever you want then.
Making whole message encryption work on a large scale, and incrementally deployable, is hard, because there are lots of corner cases to deal with. For instance, if you leave messages encrypted on the recipient's server, then the server can't assist in searching the text of those messages, which makes searching slow and especially bad for mobile devices. Or you want to know when sending a message if it's safe to encrypt it or not, but even if you define some service to query whether there's a public key associated with the recipient's domain name, that service may not work well if the recipient has their mail forwarded elsewhere. You want the message encryption service to be widely applicable but you also want the user interface to be simple - and corner cases complicate user interfaces.
Or you could start over from scratch (as has been and is being tried by others) and see how hard it is to displace the existing system without an incremental upgrade path. Hopefully we'll get there one way or another.