[bryankeithmoore]

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.