From: tomas@tuxteam.de
We do agree that local encryption of messages is a Good Thing. But just like that, without context, this phrase just amounts to Marketing Oriented Hand Wawing, sorry. The meat of the discussion (and what was being talked about in this thread is:
where do you decrypt? (1)Server-side? (1.1) Only on the "running" server? (nearly equivalent to this would be to have a permanent key storage on the server, but suitably armored by passphrase). (1.2) On the "quiescent" server? (2)client-side?
Now it all amounts to the threat models you want to protect against.
(1.2) just protects you against very little. Whoever "gets" the server (dead or alive) gets the decryption key. You've lost. And if your server is sufficiently protected, you just don't need encryption.
(1.1) would protect yoou against someone "getting" the "dead" server (e.g. by stealing its disk). Just the same as encrypting the whole disk (assuming the unlock passprhase isn't stored near the server). Encrypting the whole disk has even the advantage that your swap space will be encrypted, which protects you against key bits hitting swap (by some dumb bug in key management software -- this has definitely happened!).
This option doen't offer any relief if someone hi-jacks the "live" server (trojan or similar). So For this threat model (no hi-jacking, just loss of hardware) I'd definitely go for whole-disk encryption. That's what I do with my laptops.(2) This is actually the best solution. It won't protect you against the client being hi-jacked or stolen, but all other schemes above are vulnerable against that.
Did I forget anything?
I think that's a pretty good summary of the situation. Where I'd differ is your risk assessment of the hijacking of a live server. This, of course, depends a lot on the environment its running in so everyone's experience is going to differ.
Encrypting the whole disk is good if the server gets pinched. My servers are behind several layers of hi-tech locks with permanent security guards on the door. I'm not too worried about them.
What experience has shown me is that there's a good chance that a running server will compromised eventually. If you think your software locks are good enough it probably means you haven't been around long enough. Remember Qpopper? No? 'nuff said.
A quick reminder - the risk level is the product of the probability and the severity of an event occuring. The probability can be a lot less than unity when the severity relates to the theft of everyone email (including passwords, CC details &c) - not to mention the embarrassment factor.
So, encrypting the mail file makes a lot of sense. If it's done properly (not always a given). No alien process could read the mail, even if it had access to the file itself. Depending on the 'whole disk' encryption scheme used, if the attacker had root access there'd be no protection whatsoever. It's long been a rule-of-thumb to assume that the root password is compromised in any security scenario.
Part of the definition of 'done properly' above is NOT placing the decryption keys in backing store.
I'm not in favour of whole disk encryption for data recovery and forensic reasons.
Another advantage of doing your own encryption is the possibility of only encrypting the message bodies. Having the message headers in clear text has obvious advantages. I'm sure we're all used to skipping through mail files to find out what's gone wrong - you never want to read the message anyway.
Protection against a rogue admin by encryption is a red herring. Such a person would simply not enable the encryption in the first place.
Having said all this, I'm fairly relaxed about not having mail files encrypted. I've frequently told everyone to assume that their email is insecure, and if they've got a problem with it they need to use PGP or some other end-to-end encryption on their mail clients. Not my problem!
Regards, Frank