Maybe a heterogenous bunch if them so you'd have to crack all of them to get all messages.
You could periodically reset them in case they still get infected.
You could add a transparant proxy that specifically looks for odd, repeated requests, to detect re-infectations.
You'd set up alerts for attempts at communication/scanning from those servers, to detect virusses trying to move laterally between the different instances, and/or isolate them from eachother on the network layer.
You could have a separare hardware device that scans the memory of these servers to detect tampering.
It could also try to detect "plaintextness" and abort as soon as it detects that, so you only have the beginning of the message in memory.
This doesn't help when the ISP is recording (and it probably is), but it makes it very hard to retrieve the data from inside the email datacenter.
Yeah, well, who is your adversary?
I assume NSA and GCHQ by default just log all SMTP traffic. Especially the ones to services like these.
If your adversary is someone sniffing your unencrypted WiFi connection, they'll have your unencrypted e-mail like this one as well.
If your adversary is network and sysadmins who run your SMTP server then all bets are off. I think the danger lies, just like within Tor, that there's a mole in such a team who does harm while being undetected.
If you're protecting against the local authorities ensuring to get a remote, secure connection with a country who isn't playing along with your local authorities is key. Which is why Putin wants Russians to use local services.
Just have them rebuild themselves from ROM after each processed mail :)
There's no way to stop a user's contacts sending plaintext emails for all the ISP's/intelligence agencies to see, but you can make sure you touch them as little as possible when they do arrive (see GP) and discourage those contacts from doing it again by not delivering/returning error codes.
Unless you drop SMTP altogether. I think Riot with E2E is looking pretty good, but it's not been hardened at all.
Then don't put your users at risk by using SMTP.
>The techniques I mentioned are to reduce the risk of these (partial) plaintexts being captured, but should be paired with a refusal to deliver.
Techniques you mentioned are nothing more than pointless showmanship, which you'll cease as soon as the government asks you to.
>There's no way to stop a user's contacts sending plaintext emails for all the ISP's/intelligence agencies to see
Which is why you shouldn't put them in a situation where they will inevitably do so.
>Unless you drop SMTP altogether.
If you're going to launch a service that advertises secure communications, you have to. Otherwise you're just endangering your users, just like lavabit did.
We're not talking hypotheticals here. Lavabit already fucked over their users trying to pull silliness like this.
You can't rely on your ability to block them either, or you'll end up just like lavabit did.