How do I configure an e-mail service to provide (close to) zero-knowledge?

Question

DISCLAIMER – I'm fishing for ideas, so I can see that some people will start downvoting and flagging this as unsuitable for SF, but hey, if you know of a better place to ask this question, there is a comment box down there, don't just hide behind your clicks.

I have this tiny production server that I'm sharing with colleagues and close clients. I've been asked to provide an e-mail service. I guess I never thought about this, but I was horrified to discover that the various mailbox formats store messages in clear text, and close to nobody seem to care very much. So I figured, those fancy providers must be doing something behind the scenes. I'm not necessarily thinking of ProtonMail, but I guess Google does store messages with some form of encryption – and yes, I realise these services might have developed their own software, but hey. So I started reading up, and the closest I got was a relatively complex Exim4 setup involving a GPG transport_filter with per-user key pairs.

The truth is that the messages that will likely go around the server will not be very confidential, and my colleagues and clients are savvy enough to use GPG themselves if need be. My main concern, rather, is that these messages are available in clear text for anybody – I can see this happening as soon as I won't be the only one managing the server, the occasional cat /var/mail/username (or whatever) will happen. Worst of all, the messages will be backed up in clear text – true, I can encrypt the backups.

As I said, I don't want to provide a protonmail-like service, I'm just looking for something that provides some form of smokescreen against careless admins. In particular, some form of clear text will be necessary during transit, for stuff like anti-virus and anti-spam. However, if you have compelling and uncomplicated solutions for something more secure, I'm open to all suggestions.

Answer 1

I'm just looking for something that provides some form of smokescreen against careless admins.

Short answer: no, you can't.

If you dealing with admins the first, last and only one defence is end2end encryption. So GPG is the answer.

Who has root access to the server (should) have it because they need it, and probably known how services are configured (in order to maintain them or fix them if something goes wrong).

So if you set up some obfuscation who has root probably know how this obfuscation was made and know how decode the messages, so:

• It doesn't add any valid security layer
• Create a false sense of security

A security system is only as secure as its secret. Beware of pseudo-secrets.

(Eric Raymond - The Cathedral and the Bazaar)

Instead you should choose wisely WHO has admin credentials:

• They really need them?
• A proper limited sudo access to some specific commands can be enough?

Other solutions:

Automatic GPG encryption of all incoming mails

PRO:

• Keep IMAP mailboxes protected by peepers
• Data are safe even if stolen

CONS:

• Need a proper configured client to read mails (no webmail access)
• Customer must agreed to it, provide their public GPG key and configure their mail clients (need tech skills)
• Sender, recipient, subject and all headers are unencrypted (customers must be aware of it)
• Need some work server side and a proper way to validate customer public keys
• The message land in clear text on your server, so it can be wiretapped before GPG encryption

Full disk encryption on server

PRO:

• Can keep data safe if the server or disks are stolen/seized
• Full transparent, no need to special configuration of mailserver or other services

CONS:

• No protection from admins or if the server is hacked
• Need to input the password at every boot (trough SSH if only data partition is encrypted or trugh a KVM) and you must trust that channel.
• You will get lesser i/o performance

Use of end2end encryption

PRO:

• Safest way, even you can't access to these data

CONS:

• Customers must do it and who customers contact must be proper do it
• To be safe must be do on all mails in/out, about all online service send mails unencrypted (welcome mails, password change mails, notifications etc)

Answer 2

It's always a surprise to learn that it is obviously not common knowledge how the System Administrator (of an Email Server) and all his C-Level buddies can know about you and your communication going on in your company. GPG as mentioned in detail above is obviously one option - and you are right: your users could be the ones taking care of it. As soon as they do, you (the SysAd) can't read their emails anymore ... unless you have their key as well. Giving the facts you described, a good number of the email users are not using it.

The good old fashion way would probably be to write them an email suggesting doing so ... but this might be an approach beyond the purpose of this platform. A very compelling solution nevertheless (imho).

Having said this, back to the technical options:

Some years back in a company that offered this kind of user-managed privacy protection we used PGP (which offers a Pretty Good Privacy ;-) which is certainly a good alternative to GPG (these GNU people always want to twist our minds, don't they?), but it is still per-user-based.

Keep in mind that privacy and knowledge are pretty different in meaning. From what you are writing I think what you want is an additional level of privacy for others ... like out of some altruistic kind of thinking or caring about sensitive information sitting around and each and every admin having access to it. I think it's nice of you to think like this and you probably are overdoing it for some users if you think like this. They might not even want you to change what everybody got used to (or got used to not knowing). So, if you want to go beyond the level of having every individual taking care of their sensitive information included in emails and a individualized encryption solution is not available for any kind of reason ... I guess you have to go with the server solution as discussed very nicely by @Tsumi or you really go for protonmail.

Or - once again - you go for the human solution mentioned above - good luck finding the best decision for your use case!