SkillAgentSearch skills...

EndtoEndEncryptedMailServer

Securely host your own e-mail accounts, as e-mail was originally designed to work!

Install / Use

/learn @d3cod3/EndtoEndEncryptedMailServer
About this skill

Quality Score

0/100

Category

Design

Supported Platforms

Universal

README

End-to-end (E2EE) Encrypted Email Server

Table of Contents

Description

Secure (reasonably) host your own e-mail accounts, as e-mail was originally designed to work!

Let's make ourselves more independent from corporations, from others minding our own business, and most important, re-gain control of our personal communication over the web, in this case specifically over e-mail.

Yes, those electronic mail boxes that others maintain for us, the technical infrastructure that give us this ability to communicate instantly with everyone all over the planet, this last revision of what long ago was smoke messages, or carrier pigeons, through the centuries of postal systems, till the actual technology, where we do have, now, nor knowledge or control about every part of the entire mechanism, but hey, they give it to us for free!!!

So

Corporations and governments read and/or store all our emails, plus, we can't even complain about it anymore (from august 2013), and that doesn't mean necessary "spying" until it eventually became that.

And if you're ok with it, then you don't need this tutorial

But in case you are not, good news, i'm going to explain here how to set up an End-to-end encrypted (E2EE) email server, and hosting it in your personal server at home. I'm assuming here you know how to configure a reasonably secure server at home, but if you don't, you can check my Raspbian Secure Server Config Tutorial first.

Sources

This is a list of sources and other articles i've used to learn, prototype and realize what i'll try to explain in detail in this tutorial.

Thanks to all this people for the help and knowledge:

http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/

https://scaron.info/blog/debian-mail-postfix-dovecot.html

https://appbead.com/blog/how-to-setup-mail-server-on-debian-8-jessie-with-postfix-dovecot-1.html

https://appbead.com/blog/how-to-setup-mail-server-on-debian-8-jessie-with-postfix-dovecot-2.html

https://www.digitalocean.com/community/tutorials/how-to-set-up-a-postfix-email-server-with-dovecot-dynamic-maildirs-and-lmtp

https://security.stackexchange.com/questions/81944/perfectly-secure-postfix-mta-smtp-configuration

https://scaron.info/blog/debian-mail-spf-dkim.html

https://www.upcloud.com/support/secure-postfix-using-lets-encrypt/

https://gist.github.com/jkullick/bbb36828a1f413abd6b9d6431bafa54b

https://www.void.gr/kargig/blog/2013/11/24/anonymize-headers-in-postfix/

http://kacangbawang.com/encrypting-stored-email-with-postfix/

https://www.grepular.com/Automatically_Encrypting_all_Incoming_Email

https://www.digitalocean.com/community/tutorials/how-to-install-and-use-postgresql-9-4-on-debian-8

https://www.void.gr/kargig/blog/2013/11/24/anonymize-headers-in-postfix/

DNS

So, we'll start with the DNS records, and obviously we need a domain, we can buy one through some hosting platform, or we can obtain one for free (with some limitations, on the name for example). Take a look at FreeDNS if you want to learn more about free DNS hosting and domain hosting. So we'll use here an example domain called supersecure.mydomain.net, and just to avoid confusion, a possible mail address could be: astronaut57@supersecure.mydomain.net. We are using here a different subdomain to avoid the disruption of the standard mail service usually packed with standard hosting services, for example mymail@mydomain.net, so we will maintain the standard mail service on our domain and add a new super-secure encrypted one on a subdomain. When we have our domain, we'll just need to configure it to point to our public IP address:

  • DNS A record, that maps your domain name to the IP address
supersecure  A   YOUR_IPv4_ADDRESS
  • MX record, which tells to the others mail servers where deliver mails
supersecure           MX      supersecure.mydomain.net
  • TXT/SPF record, a Sender Policy Framework (SPF) record in order to not be considered a spammer
default._domainkey.supersecure    TXT     v=DKIM1; h=sha256; p=v=DKIM1;h=sha256;k=rsa;p=YOUR_DKIM_KEY; s=email; t=s
supersecure                       txt     v=DKIM1;h=sha256;k=rsa;p=YOUR_DKIM_KEY
supersecure                       TXT     v=spf1 a mx ip4:YOUR_IPv4_ADDRESS ip6:YOUR_IPv6_ADDRESS ~all
  • TXT/SPF record, DMARC record in order to not be considered a spammer by big e-mail providers (google, yahoo, etc...)
supersecure           TXT     v=DMARC1; p=none
_dmarc.supersecure    TXT     v=DMARC1; p=none

Regarding the YOUR_DKIM_KEY field, we'll work on that later, when configuring OpenDKIM (Domain Keys Identified Mail sender authentication system), so you can wait for that, or jump to the section and close the DNS records config right now, your choice!

That's a standard scenario, feel free to customize yours!

Usually DNS propagation takes a while, so it could be useful to set it at the beginning.

One easy step more, edit the file /etc/mailname

sudo nano /etc/mailname

and enter your selected mail domain name, in our case supersecure.mydomain.net

Let's start talking about encryption!

ENCRYPTION

Ok, this step is delicate, so i'll start describing what we're trying to achieve here: first i want an encrypted mail store for my mail server, but most important, i want every mail account associated with a gpg public key to asymmetrically encrypt messages, so only the users, with his/her private gpg key, will be able to decrypt and read their messages, plus, in case of server compromised, the attacker will own only a bunch of gpg encrypted texts!

So, before we start implementing this, a little reminder:

Even if you're using the best encrypted super secure mail account of the entire universe, when you write to someone that don't, well, your conversation is potentially already compromised. A reasonably secure conversation over the web must be encrypted on both sides.

If you ended up here not randomly, probably you already know that, but just in case, check this tutorial from Free Software Foundation about email self-defense

Perfect, let's analyze in depth how and why we'll implement the required conditions to obtain such server encryption level.

ENCRYPT the Mail Store

I'll start with the easy one, encrypt the mail store, and for that we'll use gocryptfs, a project inspired by EncFS

WHY

Someone could be asking, why encrypt the mail store if we are going to asymmetrically encrypt every single message with users public gpg keys? Well, is actually a redundancy, but let's consider this, on one side we'll learn how to properly configure generic encrypted filesystem in user-space, and on another side, we can consider it as planting some kind of honeypot for possible attackers; imagine someone taking control of our server, with read/write access to our mail store, he/she will rapidly detect the presence of gocryptfs, that, like every filesystem encryption mechanism, is potentially vulnerable to some kind of advanced attacks, so he/she will probably start to try to exploit the gocryptfs vulnerabilities (if your are interested, take a look at this audit here), and after some time, maybe, with some luck, he/she will decrypt the mail store, finding a bunch of asymmetric gpg encrypted messages!!! Wouldn't you like, just in that moment, to see his/her face? And to go further, we could plant some other kind of hidden side-channel remote logging system over our encrypted mail store, in order to try to extract information about our potential attacker working on our compromised server, but this is just a little far away from the purposes and skill level of this tutorial, so i'll let this particular point in the hands of the interested enthusiastic contributor that will teach us how to implement this properly (thanks in advance!).

HOW

As always, let's install it:

sudo apt

Related Skills

View on GitHub
GitHub Stars78
CategoryDesign
Updated24d ago
Forks11

Security Score

100/100

Audited on Mar 13, 2026

No findings