Mailcow-dockerized: Ciphermail

Created on 3 Dec 2017  路  26Comments  路  Source: mailcow/mailcow-dockerized

Is it possible to include ciphermail as an optional container?
See here:
https://www.ciphermail.com/

I currently use the virtual appliance in front of the mailserver.

dunno

All 26 comments

This really sounds interesting. Can you elaborate a bit more on what ciphermail does and how it does it? Perhaps some use-cases and apps that you use with it?

ciphermail will do encryption for you!

You can configure it as you wish, you can have your own CA for self signing smime certificates. PGP integration is also integraded.

I bought an official SMime certificate and every mail will be signed automatically with this certificate and if i know and trust to a public certificate, ciphermail will automatically encrypt the email.

The best part is, that your mail will be encrypted and all incoming messages will be decrypted and stored plaintext on the server. You do not have to keep all these old certificates to decrypt your old mails.

Zeyple is already built into Mailcow, though not integrated by default. It only does PGP and does not decrypt incoming mail though.

@mkuron Is there a guide as to how to integrate this/set this up?

Edit: Didn't find one; playing around to figure this out now, then will open a PR for configuration guide.

oh wow that's really awesome. Didn't know that.
What about mails back, and adding automatic decryption for that?

@ChessSpider You don't really want automatic decryption on the server, as this encryption is designed to store encrypted mails in such a way that the server cannot access them (to protect against attacks, administrators, server hosts etc accessing your mail). The idea is that only you can decrypt them once they're on your own device :)

Hi @stevesbrain
i understand what you're saying, however I'm doing the IT of a small company where configuring the different (desktop/mobile) clients for proper PGP usage is not feasible for the individual employees. However I do want to enable my employees to communicate in the most secure fashion possible. As long as "most secure" doesn't impact usability too much.

By the way, by doing automatic encryption server-side in postfix only when sending. Aren't the unencrypted versions of those emails both present in the IMAP-databases on the server in the "Inbox" and "Sent" folders anyway? E.g. the a malicious administrator/server host could still access those emails.

That's fine by me, the trust starting at the server level is good enough for our use case. But then automatic decryption on the server makes sense as well. Preferably as a opt-in solution for our users. Like ciphermail. But Ciphermail doesn't seem to offer pop3, imap, activesync, etc.

@ChessSpider - no worries, just wanted to make sure you/whomever was fully aware of what you were asking/saying :) Admittedly, I haven't read the Ciphermail page, so that very well may be what you're after, but it sounds like the inbuilt Zeyple is not for your particular use case.

Re: Sent mail, you're absolutely right - it would be be worth noting that for when one is sending between internal users. I'll make a note in the PR - thanks :) I will read up on Ciphermail now, but from what you're saying it sounds like it's similar to Protonmail in that sense? Decrypt when user needs to access, but not auto decrypt in terms of when it's just being stored?

@stevesbrain No worries. By the way, it also counts for communicating with external users. As mail clients usually append the entire email chain is to your reply ;-)

Zeyple is great, but it should be combined with a server-side solution which automatically creates and publishes private keys for mailboxes and handle their automatic decryption.

@ChessSpider Added to the PR in commit https://github.com/mailcow/mailcow-dockerized-docs/pull/60/commits/2f4f0be61515518e908f9f1b49246cb7e1234a37 - credit given to you for the observation as well :)

cool thx 馃憤

@stevesbrain
Thank you very much for this great hint.
I set up everything according to your documentation.
I also noticed that zeyple or postfix (which, i dont know) changed DKIM so that mails are sent to the junk ...
Is there some workaround?

DKIM signing and Zeyple/Ciphermail are mutually exclusive. The former is done by a milter (pre-queue), while the latter are content filters (post-queue). So the encryption always breaks the signature.

Ok, understood.
But is there any possibility to do the signing after encrypting the mail?
Having encrypted all mails is a very good thing, but in a productive environment?
What ist best practice here?

@Feuernatter I'm not sure if there's a way to change the order in which these are done (though I suspect there's not), however, this is at least useful for ensuring all received mail is stored encrypted for you (even if not encrypting all outgoing mail).

@mkuron Thanks for pointing that out - I hadn't noticed DKIM signing was broken yet (as I was only using it to store encrypted - I don't rely on automated systems for sending encrypted in case the system drops [as a matter of not wanting to get into bad habits]). I've updated the PR to reflect that in https://github.com/mailcow/mailcow-dockerized-docs/pull/60/commits/c9c050d4301c95e85bb474268fea1c649a522384 :)

have you guys seen https://github.com/vstakhov/rspamd/issues/1912 ?
rspamd would probably be the best place to do automatic encryption/decryption. As it already sits in right in the middle of sending/receiving email and does activities which require both the encrypted (dkim sign check) and unencrypted (weighing of content) versions of the email

@mkuron

DKIM signing and Zeyple/Ciphermail are mutually exclusive.

That is not the case if you use Postfix. If you use milter's, make sure that DKIM signing is the last milter. If using CipherMail, you can enable the DKIM milter for the Postfix reinjection port (10026). Alternatively you can use the DKIM signing functionality built into CipherMail (which I'm using since I'm a CipherMail developer ;)

Thanks for chiming in, @martijnbrinkers.

If you use milter's, make sure that DKIM signing is the last milter.

Yes, that would work. Put Ciphermail before rspamd for outgoing mails (so the encrypted message is DKIM signed, though this breaks spam checking for outgoing messages) and vice versa for incoming ones (to check the decrypted messages for spam). I wasn鈥榯 aware that Ciphermail can be a milter. I don鈥檛 think Zeyple can.

If using CipherMail, you can enable the DKIM milter for the Postfix reinjection port (10026).

We prefer milters over SMTP proxies, but of course that would do it too.

Alternatively you can use the DKIM signing functionality built into CipherMail

Our private keys are stored in Redis, which might make this difficult.

I would love to see some progress in this direction. Having encrypted mails out-of-the-box is something that more and more people want to have but don't want to invest a lot of time in (client-side encryption can still be a mess, especially when trying to have it working on multiple devices and webmail).

I wonder why so many p2p-communication protocols/technologies are encrypted by default today but email still isn't; and people just keep sending sensitive data that way for everyone on the physical line to look at :/.

I would like to see something implemented to use PGP.

Use it in a client. Or use Zeyple (as soon as it is fixed). Or sponsor it. :-)

How much would that cost if someone would sponsor this kind of feature?

Maybe we can raise a gofundme? ;)

Naah, it's fine. It is just that we already have Zeyple and Ciphermail is something to be included in the docs.

I don't have time to add it. :-/

No, seriously. If you would include a proper way in the docs or even make it easily configurable by some env variable, people would gladly participate in crowdfunding, I'm sure.

I mean, after all it would be another thing that gets added to the stack which someone has to look after and update and stuff...

I hope everyone appreciates the work that is being put in here.

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

lgleim picture lgleim  路  3Comments

pgollor picture pgollor  路  3Comments

mritzmann picture mritzmann  路  3Comments

CrAazZyMaN21 picture CrAazZyMaN21  路  3Comments

Adorfer picture Adorfer  路  3Comments