If the MTA supports regular SMTP, POP and IMAP, then it cannot be said to perform end-to-end encryption. When a client accesses mail through any of these legacy protocols, the server must decrypt all messages before pushing them down the last hop. This used to be Lavabit's way of offering "encrypted" email.
If the MTA also supports some other protocol that affords end-to-end encryption, that's great, but now you need to use special client software that is either proprietary or seriously lacking in features. This is ProtonMail's way of offering encrypted email.
ProtonMail is currently working on a proxy called ProtonMail Bridge that runs on the client and talks to legacy MUAs. All communication between Bridge and the outside world is still encrypted. That sounds like a good idea to me, since I have no intention to stop using Thunderbird anytime soon. It's also probably the only way to bring end-to-end encryption to a large number of people, since it embraces and accommodates the inertia around email instead of arrogantly telling people to switch and wondering why they don't. When it comes to email, backward compatibility is everything.
I'm not sure if Lavavit's Magma can fill the same need; the documentation is rather sparse. But I would gladly run a local MTA if it means I can have my cake (end-to-end encryption) and eat it too (compatibility with legacy MUAs). DIME also looks like a much more open protocol than the vendor-specific stuff that ProtonMail is using.
While you lose a lot of the benefits of IMAP if the server does not have access to the content of messages, this is absolutely not necessary for POP and the only information which must be transferred in the clear to use SMTP is the TO address (and even then, only in the envelope, not in the actual message). Claiming that these protocols inherently are incompatible with transferring encrypted content is like claiming that any protocol that sits on top of TCP or HTTP is incapable of end-to-end encryption. What I think you are actually trying to say is "compatibility with existing clients without any additional software or plugins", but that is unrelated to the usage of SMTP, POP, and IMAP.
You're technically correct, but I don't think it's realistic to separate the payload format (plain unencrypted RFC 2822) from the various transfer protocols that have grown with and around it.
You mention HTTP, but do you think HTTPS have been as ubiquitous as it is now if people had to install a browser plugin in order to enable it? That sounds suspiciously similar to what South Korea has been trying with their infamous ActiveX plugins for their own national PKI. Nowadays they've moved away from ActiveX to actual browser plugins for Chrome/Firefox/etc, but nobody likes it as long as they have to install even a single plugin. "Compatibility with existing clients" really just means "compatibility with existing clients without any plugins". People don't like installing plugins.
Maybe a few years from now, every well-known email client from Outlook to Thunderbird to SquirrelMail will support an E2E encrypted email protocol (either a modified version of SMTP/POP/IMAP or a brand-new protocol) out of the box. Then, and only then, I think it might have a chance to become as successful as STARTTLS has been.
Please don't call ProtonMail "end-to-end encrypted email". They are mailing links to content hosted on their own servers.
The worst part is that they could easily allow interop and implement proper features in the client. Too bad they don't care and the competitor(s) (is there anyone else than Tutanota with a full e2e impl?) don't care about the users either.
I worked for a competitor a while ago, was ruined by a relatively incompetent CEO. The team is still fiddling with various small projects related to the field, but creating a proper solution without funding is quite hard, as it's a very extensive, challenging project.
You should look at the DIME spec: darkmail.info/spec specifically where it describes account modes. What we have working now is trustful mode, where the server acts a proxy to allow legacy clients to continue working. We're building DMAP clients which will allow cautious and paranoid mode, but it's taking awhile to get things built properly.
If the MTA also supports some other protocol that affords end-to-end encryption, that's great, but now you need to use special client software that is either proprietary or seriously lacking in features. This is ProtonMail's way of offering encrypted email.
ProtonMail is currently working on a proxy called ProtonMail Bridge that runs on the client and talks to legacy MUAs. All communication between Bridge and the outside world is still encrypted. That sounds like a good idea to me, since I have no intention to stop using Thunderbird anytime soon. It's also probably the only way to bring end-to-end encryption to a large number of people, since it embraces and accommodates the inertia around email instead of arrogantly telling people to switch and wondering why they don't. When it comes to email, backward compatibility is everything.
I'm not sure if Lavavit's Magma can fill the same need; the documentation is rather sparse. But I would gladly run a local MTA if it means I can have my cake (end-to-end encryption) and eat it too (compatibility with legacy MUAs). DIME also looks like a much more open protocol than the vendor-specific stuff that ProtonMail is using.