Encryption at rest

SYSTEM INFORMATION
OS type and version Alma 9
Webmin version 2.11
Virtualmin version 7.10.0 Pro
Related packages Procmail Dovecot

I’ve been pondering this for a few days now, and I’m not sure the best approach really. Dovecot has encryption at rest available as a plugin, which works.

Procmail on the other hand does not, and virtualmin uses procmail to deliver incoming email to folders that dovecot then reads. (as far as I understand it).

So, its either encrypt with procmail using the same key(s) that dovecot then uses to decrypt, OR, let dovecot save the email’s (dovecot/deliver). The latter means we’d loose all the nice things that procmail does, and integrates well with virtualmin.

The procmail code (procmail.c) which actually puts the file on disk is quite complex and seems to take account of every possible scenario so if we were going to implement this in procmail it would be best to do it before the actual delivery, imo.

I am thinking here global keys rather than per user, but it doesn’t have to be.

So there is the question…

You are right, promail is used to process and deliver the email to the right folder.

Procmail is a Mail Delivery Agent (MDA)

Encryption cannot be added before the mail arrives in the folder because SpamAssassin and ClamAV need to read the emails, and if the emails are encrypted when they arrive in the destination folders, Usermin would not be able to read them as if I remember right, Usermin accesses the email files directly from the disk and does not use POP3/IMAP bypassing Dovecot.

Furthermore in Virtualmin Pro I think you can search emails and this feature might get broken

It is technically possibly but I think there would be a lot of work would be involved and it is not just Dovecot that needs to be updated.

1 Like

Surely SA/AV is done in the postfix realm as milters and no via procmail? I guess it can be done outside of postfix but I’m not sure why that would be the case? can you expand on this?

I cant add much more but I belive the procmail solution was put in place so per domain filtering rules can be used.

ProcMail is a great solution and it provides some really smart features that just aren’t available via dovecot/postfix, but, it does make encryption at rest harder.

Encryption at rest is everywhere now, in Europe everyone wants maria/mongo encrypted at rest (which we can do) and call recordings now have to be encrypted at rest to comply with GDPR, and we already have clients who insist on encryption at rest for email (which we’ve done with postfix/dovecot) in a container. And before anyone brings up the private key on the same server - I know ok.

We could do it with an encrypted fs mounted into /home, which would technically be encrypted at rest, but that would mean EVERYTHING would be, not just email and that would be a performance overhead.
We could potentially mount an encrypted fs over /home/xxxx.xxx so just some clients are encrypted but that approach means we’d need to be mess’in with the dev’s perl code and that’s something I absolutely don’t want to be doing on prod systems.

I guess I’m not looking for a solution out of the box, but my hope is that its something that could be put on the todo list and slowly implemented in the future.

Something to launch into that ever growing “Blue Sky” then?
(about as welcome as a flight to the moon perhaps - like GDPR is to the US)

GDPR, like PCI-DSS was written by people who In terra somniorum vivit like most ‘tech’ related legislation. No one hates it more than the people forced to rewrite half the front end to comply with this stupidity.

Regardless, encryption at rest is banded around boardrooms as a ‘thing’ that’s needed, and if done correctly, and private keys are secured correctly on the same server then its fairly secure from insider threats, and that’s the goal really, and that’s not fixed with volume encryption.

None of this made sense to me so I looked it up. The Dovecot implementation seems to use it to encrypt stored emails. They aren’t encrypted when received. It just makes it harder for ‘casual’ users being able to read it? It seems to me that is what the ‘at rest’ implies. While sitting in the inbox. Nothing to do with the transport.

doc.dovecot.org/configuration_manual/mail_crypt_plugin/

mail-crypt-plugin

Introduction

The Mail crypt plugin is used to secure email messages stored in a Dovecot system. Messages are encrypted before written to storage and decrypted after reading. Both operations are transparent to the user.

perhaps another confusion between “Encryption” and “Hashing”?
the former being 2-way the latter being only “1-way” (no way to undo it)

That’s exactly what it is, at rest. One threat that this mitigates is the insider threat, that is, a third party, even a reseller who has access to a virtual domain right now can read all the email’s of any mailbox they can reach.

Dovecot encryption works well, on a server with just postfix & dovecot, but its not easy on virtualmin because procmail has no ability to encrypt, and usermin for example (not checked but probably) just reads the files from the users home Maildir and doesn’t use dovecot.

Implementing something like this would need all these systems to use the same keys, and encrypt/decrypt accordingly. Procmail, Dovecot and even virtualmin are open source so its not impossible, but its far from simple.

One possibility would be to spool up encrypted storage with luks/vera/ecrypt/encfs etc for each user, and then mount those volumes into the users Maildir. Everything would work with that (AFAIK) but it would need to be implemented into the ‘add user’ and ‘remove user’ as well as at startup to re-mount all the volumes, and these volumes would then need to be sized accordingly, expand, contract, all sorts of madness to deal with quota’s… probably not the right approach - but tell me I’m wrong?

You sound very confident about that, but it’s very rare for all spam filtering to happen in the mail server, and it’s not a very good way to do it…Postfix does not have fine-grained filtering capabilities. Either the mail is rejected or it is delivered (or passed to the delivery agent).

You’d generally always want something else that can make finer-grained decisions about spam and viruses, as well as making other filtering decisions. There are many options for that. Mailscanner is a popular one. Procmail is another (though it’s pretty old and was even mostly abandoned for a while, but has been back in somewhat active development for a few years…it’s too useful to die, I guess). But, you would not want Postfix in charge of spam filtering decisions.

Well postfix is just an MTA, and when I say in the postfix ‘realm’ I don’t mean postfix itself, I mean filters that postfix routes the message through and pulls insights from, e.g. OpenDKIM, OpenDMARC, Policyd-spf and of course Amavis(-new) which can be enhanced with spamassassin and clam. I’m not saying SA isn’t a great filter on its own, it is, but its not perfect and being able to adjust scores in amavis before postfix makes a routing choice is quiet valuable imo. This is what we use on our message routers.

Regardless, it doesn’t really matter what route email takes to get to the mailbox, and I’m not criticising procmail in any way, its a really powerful filter; the question is whether mail can be encrypted before it reaches its final destination in the users Maildir in a way that is compatible with Dovecot’s mail-crypt, since dovecot has to be able to decrypt it to serve it to clients…

I suspect the way to solve this short term is with a custom mail solution just using postfix and dovecot on its own VM, which is the work-around currently in use for those twitchy clients.