Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Suppose you're truly paranoid (I assume the majority here identify with this?) and you don't want Google or other email service providers reading your email (to serve ads, etc). You don't want your ISP making backups of your messages (even with good intentions) because when you delete an email, you want it to be deleted.

One solution is to use encryption, but how many of your correspondents are sophisticated enough to use email encryption? Does Mom send you encrypted email? Probably not.

My solution is to run my own box, in my home, with a mail server that I control. Of course, the (plaintext) message could still be getting backed up somewhere: perhaps your ISP logs every packet? Or the NSA is spying on citizens again?

Question: Is my solution (home mail server) the best for my goal? Is there something better?

share|improve this question
add comment

3 Answers

up vote 6 down vote accepted

It's not paranoia if you've conducted a proper analysis and have identified a likelihood that they are out to get you in excess of your acceptable risk threshold.

Running your own server is a fairly reasonable control for the risk that the admin of your mail server reads your mail or is subpoenaed for their backups. You must weigh it against the cost and the risk that you introduce new vulnerabilities.

For example, Google is certainly going to have better high availability solutions available to them than you do. They have better paid mail admins and security officers and pen testers. The physical security at their data centres is better.

Also, even if you remove this vulnerability, there are many, many others you haven't addressed and may not be able to. You've already identified the fact that non-encrypted emails can easily be read in transit. One you've missed (and everyone misses this one) is that it doesn't matter how secure your end of a mail communication is if the other end is insecure. If you send a mail to my gmail account, it's going to get stored on gmail's servers whatever you do.

In short, unless you use application level encryption, general email is inherently insecure; you should accept that and if you have sensitive material to send, encrypt it or don't use email for it.

share|improve this answer
    
Rocking answer! It's all about what you are concerned for - a perfect case of availability vs. control. –  bethlakshmi Sep 14 '12 at 13:11
    
Oh - wanted to add one thing - for high paranoia, I would actually recommend a separation of data. Most high-security work environments will both use encryption and control their employee to employee email infrastructure. There are rules about contact with personal email/communication systems on work machines - that isolates the high risk data from the uncontrolled systems. Same thing within the personal space - if I was going to be concerned about privacy to a high degree, publicly hosted email is simply too public of a medium. –  bethlakshmi Sep 14 '12 at 13:16
    
There is a slight catch with this approach - most large email handlers will use various services to identify potential spam. This includes checking against lists of DHCP pools (which accounts for most home broadband solutions). Hence don't expect to deliver most of your email unless you've got at least a T2/E2 with a static address and PTR pointers to your domain. (whoops - just noticed I already said this a year ago below :$) –  symcbean Jan 11 at 21:20
add comment

Is my solution (home mail server) the best for my goal?

As you've already noted, the email passes through other machines to get to you. And SSMTP is only really supported for MUA to MTA connections.

Unless you have your own domain and a dedicated IP address outside of the main consumer blocks, along with symmetric PTR records, then you'll likely find that your outgoing mail will be flagged as spam.

share|improve this answer
    
A small number of organizations do support opportunistic encryption (MTA to MTA) via STARTTLS. Google's one of them. So it is actually supported and even sometimes implemented. You're quite right, though, to assume that most email will be plain text. –  gowenfawr Sep 14 '12 at 21:07
    
I thought about adding this to my answer but brevity won the day. Yes, thanks to opportunistic TLS many of your emails will be encrypted; the problem is a) knowing which ones and more important b) what to do about the ones that aren't. –  Graham Hill Sep 17 '12 at 12:37
add comment

I think it's a complete waste of time to be completely honest. Take the example of your mother. You send her an email, and on the other side her provider has a copy. You can delete it from your system, shred the hard drive, and melt the pieces in a plasma torch but there's still a copy on the other side and there's nothing you can do about it.

This would only work if you only allowed your email server to connect to other privately held email servers run by people who thought the same as you, but that limits utility massively, and would only be assured if the security of both sides is assured and both sides agree on the disposition of email.

As an example, say in your network of trusted email servers you send an email to Joe. You later decide you want this email deleted but Joe disagrees and won't delete his copy. There will still be a record of it somewhere. It's unworkable.

If you want a server-based solution where you control the disposition of information completely you'll have to build a system where users have to log in to your server and can only post information on that using some sort of app that loads from the page that's designed to delete any information totally after it is used. Even then that's not perfect because the user could run a video capture program to record the session. And by having such an onerous system in place you'll erode its usefulness as people will do their best to circumvent it, or simply refuse to use it.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.