If you want even a hint of privacy, you'll have to rent some rackspace and put a tamper-resistant box of your own in there - and stop trusting it the first time it goes down unexpectedly.
This paper describes (and implements) a few of these (Chapter "Key Identification"): http://cryptome.org/0003/RAMisKey.pdf
This 5-year marketing video for police demonstrates switching a computer over to another power source without powering down:
As such, an encrypted file system even on a VPS provides slightly more protection than an unencrypted one. If it's worth the effort depends on your threat model.
So, if you're really the person who needs a tamper-resistant box that's untrusted after unexpected downtime, even renting rackspace is a bad idea. You probably want it under physical control.
If you're however an average user, a VPS with encrypted FS provides decent protection against most casual attackers. For many of us, that's enough.
The NSA hasn't changed that.
Instead, they're both questions of degrees of inconvenience and degrees of difficulty.
This is exactly how I feel about Google Apps. I used to recommend it to customers, now I hesitate to recommend it, even though the alternatives aren't as easy or fully-featured without a lot more work. Thanks to the author for setting this lot up, I'll definitely be looking at it, and possibly using a few of the pieces.
Ansible is great though; even if you're not setting up your own private cloud it's worth taking a look at for deployment. AnsibleWorks really should set up an extensive library of playbooks like this, each isolated so that they can easily be mixed and matched. Their examples were a bit limited and specific last time I looked.
Does anyone have any tales of using Dovecot (good or bad), as I'm considering installing it?
I've been using it on a server at home to basically archive my email (since the account I use to receive new email gets fussy if it gets too full) for a number of years now; it's worked great for me. I particularly like the fact that as of version 2.0, it supports sieve filtering out of the box, including a ManageSieve server, so I can easily set up complex filtering rules.
A decent Postfix configuration + up2date SpamAssassin can do wonders. One of the "secrets" is to train Spamassassin.
What I do for example is to move all the spam I receive in my inbox to a special folder that I later run "sa-learn --spam" on from a cronjob. You don't even need a webmail/interface for this.
1. RBL: zen.spamhaus.org. This kills 95% of incoming spam.
2. Greylisting. This catches the 4.99% of stuff that gets through zen.spamhaus.org
3. SpamAssassin: Everything else. The last time spam got this far appears to have been over a year ago.
The RBL is pretty trivial to set up in postfix, and there is an effective greylist implementation included by default nowadays. Between these two alone, I get less spam in my own mail than I do in gmail..
1 - try not to use greylisting (it can be quite annoying some time when you are waiting for an important email)
2 - RBLs should be used from within SpamAssassin in such a way that it raises the spam score, not directly in the MTA. There are loads of "good" addresses listed in RBLs due to carelessness and/or incompetence of the operators.
2 preconceived ideas really.
Semantics, semantics, but rkhunter is intrusion detection, not prevention. I don't know what rkhunter would do to stop an intrusion, and fail2ban stopping a brute-force on your SSH login is hardly the likely intrusion vector for a server running this many services.
These tools still require a huge amount of systems administration work before it really counts as a "personal cloud". rkhunter looks for some basic rootkits but will not really protect you from emerging threats, other than to tell you you have a file integrity mismatch on a common file such as /usr/bin/login.
Since this is installing everything, it seems wise to add better host-based intrusion detection/file integrity checking across all services and configurations, via AIDE or Samhain, which you could do with this type of automated setup. Both can then use the local MTA to alert you directly to your mail client if something is compromised, plus you gain the security of your configuration files for these services not having been tampered with.
What about running unattended-upgrades for security patches to things like Apache et al? Given the adversaries expected here, I assume that we aren't worried about false packages, etc. as a risk.
I will publish what I have soon, just need to build a few more applications containers(think rss reader, owncloud, git repo).
It seems like a useful thing to have and I am curious if there is a demand for such a tool.
In any event, I have been looking into Cyrus IMAP because a) it used by Fastmail, they even host their forked version of the code  and b) there is a alpha-beta feature right now for a CardDAV and CalDav server baked in. 
Maybe I can try and work on my own sovereign-like setup with this.
Every couple of weeks, ejabberd will attempt to eat all of the RAMs. Scheduling restarts was easier than trying to figure out why that was happening.
Since switching to prosody, we've seen much better stability.
It's been several years since I last set up self-hosted email. At the time Roundcube was the best out there, but it wasn't in the same league as Gmail.
I feel relatively safe that I could drop this file anywhere I want and it would be useless to anybody without access to my brain or keystrokes, so I just put it in unsecure cloud storage. If I'm wrong about that, then I'm screwed, because all of my finances and identity would be full compromised. Each backup is pretty small since it's mostly text files and a few binaries and images. I have a minimal amount of media files so I don't bother to back up larger things that are mostly replaceable.
But the real goal here is not to stop a targeted government attack. It's to avoid cost-effective, bulk surveillance. For that, a server in your basement is quite good.