The mailbox at your house doesn't require security patches, trouble-shooting, upgrade cycles, and that's just the software stack itself. When you get to the issue of blacklisting/deliverability that's a whole new set of problems.
Ultimately, I do want to run my own email server but not until it's a lot closer to 'fire-and-forget' (which for me, will be something Unikernel-based).
Zimbra is pretty much what you are after it sounds like. Just set it up once, and it just works. Just keep the OS updated and install any updates Zimbra releases. There is some manual work to get it going up front, but it's not hard.
The only way you can guarantee your email is kept private and not shared to any gov't agency or anything is to run it yourself. Then at least they have to serve you directly to get your emails ;P
What kind of a box do you really need for that, though? The requirements seem to say 4G of RAM, which seems to demand a big VPS or a dedicated box... (would be $40/month for a 4G RAM VPS at digital ocean or Linode)
Take a look at https://github.com/mail-in-a-box/mailinabox It's not production ready yet, but it aims to be suitable for cheap VPS (current requirement is 1G of RAM, IIRC).
admittedly it's intended as corporate email server - ie. MS Exchange replacement. You can run it with less ram, things will just be slower, however if you only have a few accounts, it may not be a big deal. I like it because they package all the components you need: postfix, mariadb, web ui frontend, spammassasian, etc all together and you don't have to do any configurations other than the initial setup script it comes with.
For me, it's because GMail is hands-down the best email client I have EVER used.
For comparison, I have used at length on a daily basis Pine, Elm, Agent, Mutt, Thunderbird, Outlook, Outlook Express, Lotus Notes and GMail. GMail is so stupidly better I can hardly believe nobody's done a decent fat-client imitation.
Looks good as a client but they have some issues with / absence of STARTTLS support ( for both IMAP and SMTP ) at the beta stage, so I would advise people against using it outside a controlled or test environment right now
Oddly, I used to feel the same. I recall vaguely liking Mutt back in the day, but I really liked gmail. Especially with the keyboard shortcuts enabled (and without... I actually hate it).
Not that surprisingly, the lure of emacs really hit me and I find gnus to be a better interface now. Much better.
I'm not a sysadmin, but I'm a software engineer generally pretty comfortable doing ops stuff...and I'm pretty daunted by the thought of running my own email server. Beyond the setup(1), which isn't child's play, there's ongoing maintenance, possible issues with deliverability, security concerns, availability concerns (what if my server goes down while I'm off the grid on vacation and all my emails bounce for a week?). Basically it's an awful lot of effort for...not much reward, in my opinion.
For a personal mail server, it really isn't that hard and isn't much more work than setting up an HTTP server. Obviously if you're going to be a mail admin for an organization you'll need to put more work into it, but propping up postfix and some mail frontend on a personal server is pretty easy.
No frontend you use will ever be as useful and simple as a big webmail provider's (like Gmail), but just ensuring successful delivery and receipt of mail really isn't that hard unless your server happens to be in some IP space with poor reputation. If it was that hard, email would be a lot more broken than it currently is.
you could just install Zimbra (on it's own box/vm) -- it's pretty maintenance free unless you require some custom configs. Just make sure you keep the OS updated, and when Zimbra has an update, do it quickly.
you still will have to setup MX records and A records in DNS... but that's not too tough. Also you could get a backup MX service for like $10 a month to ensure you never bounce emails if you go down (you won't really bounce anything until after being down for 48 hours anyways, most email services will retry up to 48 hours then give up).
BTDT and it was a huge relief when I moved my domain to Google Apps and started using Gmail. Unless it's gotten hugely more effective than it was a few years ago, Spamassassin is nowhere near as good as Gmail at recognizing spam, and spamfighting was the biggest of many chores involved in running my own server. I was constantly having to tweak and refine things to keep my spam filtering effective.
As a counterpoint my home mail server has no spam filtering at all, and I receive at most 10 items of spam per year.
Instead I spend time tweaking fun stuff on my mail server, like setting-up X.509 user certificate-based authentication instead of IDs and passwords. And transparent on-server S/MIME [ de|en ]cryption using Anubis. Stuff that the big mass-market providers won't implement.
Not everyone here uses Macs, and Thunderbird is, while an excellent mailclient, no match for the Gmail UI when on the road (e.g. internet cafe, a friend's computer)...
Now that's ironic. Using code words supposedly designed to attract automated monitoring system attention which are actually themselves a form of code to an encrypted message.
Despite the banality of this project. I think the idea itself could be interesting: That is, mapping your encrypted email into authentic looking text. Sending the text. Then your receiver would need to know that the text is encrypted (don't tell them in the email). This /might/ be a temporarily effective dodge against bulk storage of PGP encrypted emails.
It would be reasonably straightforward to generate encoded messages that are about as coherent as spambots plucking a series of random phrases from the web.
I don't know how you'd generate anything plausibly human, though, unless you're doing obvious steganography with whitespace or capitalization.
It's probably easier and secure to embed this kind of data into signature images. Those are quite common and a normal user can't see that data is injected, as opposed to a system where data is transformed to look like a normal conversation using words.
You might be interested in format transforming encryption then.[0] It is used in tor to prevent deep packet inspection from detecting the initial connection to tor.
Using FTE you can make ciphertext match an arbitrary regex. In the case of tor they are making ciphertext match HTTP traffic.
That is an interesting idea, but I'm not sure that it's actually doable. How would you do implement it? Moreover it seems to me that it would be likely not worth the work, because training some ML algorithm to detect this kind of messages would be always much easier than to design and implement this kind of mapping in the first place.
This would play merry hell with spam filters, so it may not work for email services that do server side spam blocking (and may get your source email address tagged as likely spambotted).
Depends how "real" the content needs to look, especially as most email spam is almost illegible anyway. Would receiving this[1] from a random .ru email really be something that would flag suspicion?
Cool idea.
If each PGP character is mapped to one (or more each) noun, verb, adjective, and adverb one could construct a message that looked like boring text but was actually encrypted.
As far as I can tell, this is mapping each base64 character of the encrypted blob to one full word? This will obviously multiply the message size a great deal.
Mapping each base64 char to one word seems rather inefficient. If you have a longer list of N swears (say 256 because it's the size of a byte, making encoding easier), you could produce a more efficient base-N encoding, e.g.:
var bytes = atob(base64msg),
swearsMsg = '';
for (var i = 0; i < bytes.length; i++) {
newMsg += swears[bytes[i].charAt(0)] + ' ';
}
Of course, it's still less efficient than base64, but it's an improvement. :)
Well, for some X there's always a base-2^X encoding you could use. If you can find 512 swears, you could do base-512. You don't actually have to do a base-2^X encoding, but that's more convenient as it means you're encoding X bits with each "digit".
But yeah, I'm not sure there are that many recognisable swear words in English. Unless you count massive compounds, but now all your words are really long, so you haven't gained anything.
A nice simple alternative to the pain of setting up and running your own mail server (and yes, this is painful to monitor, patch, maintain, protect) is to use a simple email encryption product like Jumble email encryption (https://jumble.io) which integrates on top of the Gmail UI providing end to end encryption
You would be unable to tell an encrypted message from normal discourse with a sailor.