Running your own mail server

Motivation

Not too long ago there was some hubub around https://myaccount.google.com/purchases. In brief, if you use google mail, it tracks your purchases through receipts received in email. Now, some people see this as no big deal or even a feature. Others see it as a privacy invasion, and are reminded that all their data can be mined by the email provider and possibly third parties. Of those, some advoate getting a paid email provider. Agreed, that provides less incentive to monetize your data… but only a bit. Eventually, any company, however good its initial intentions, goes through leadership changes, is bought out, or goes bankrupt. At that point, your data is one of the assets being bargained with.

The other alternative, of course, is to run your own mail server. I won’t lie – this is not for everyone. But it’s not as bad as some make out. I recently reinstalled mine, so I wrote down the steps I took, and will leave them here. I’ve been holding onto this for at least 6 months hoping to eventually run through them again to work out some of the finer details. That hasn’t happened yet, so I’ll just post what I have now as a start.

Running your own mail server is not free. In particular, you’ll need to pay for a domain name ($10-15/year), and some place to run the mail server. If you have an always-on machine at home, and stable IP address, then you can run it there. You can pay for a tiny cloud instance on amazon/rackspace/digitalocean/etc. There are cheaper options (including “one year free” amazon micro instances), but a small digitalocean instance will be $5/month. Personally, I keep a large server online for running many VMs and containers, and run the mail server there.

You will also need a certificate. That’s now easy and free with letsencrypt.

There are also some non-monetary costs. You may get a bit more spam. And once in awhile, you may run into a case where your mail server is being rejected by another.

On the other hand, the server is entirely yours. You can create as many accounts for individual purposes as you like. You can point multiple domain names at it, so that you don’t give away your primary one for every little purchase you make. Ten, twenty years from now, you can still have all your friends’ and family emails in the same place, in the same format. This last one is too often overlooked, yet one of the best advantages of open source for all applications.

Setup

I picked up a new hosted server, and installed Ubuntu 18.04 on it. First thing I did was go to my dns provider and register a name for it, and set up the new mx record to point to it. The details of this vary a bit depending on your dns provider, so I won’t go into detail here (I’ll do a post if people ask for clarification). If you’re looking for a provider, I do recommend zoneedit.

I installed lxc and created a new container in which to run my mailserver:

apt-get -y install lxc1
lxc-create -t download -n mail -- -d ubuntu -r bionic -a amd64

I gave it a static ip address through dnsmasq:

echo "dhcp-host=mail,10.0.5.155" >> /etc/lxc/dnsmasq.conf
echo "LXC_DHCP_CONFILE=/etc/lxc/dnsmasq.conf" >> /etc/default/lxc-net
sudo systemctl stop lxc-net
sudo systemctl start lxc-net

The point of the static ip address is to facilitate forwarding mail related ports into the container. I did this with a script started at boot by systemd:

cat > /usr/bin/container-ports-fwd << EOF
nic=enp0s31f6
iptables -t nat -A PREROUTING -p tcp -i ${nic} --dport 25 -j DNAT --to-destination 10.0.5.155:25
iptables -t nat -A PREROUTING -p tcp -i ${nic} --dport 465 -j DNAT --to-destination 10.0.5.155:465
iptables -t nat -A PREROUTING -p tcp -i ${nic} --dport 993 -j DNAT --to-destination 10.0.5.155:993
iptables -t nat -A PREROUTING -p tcp -i ${nic} --dport 587 -j DNAT --to-destination 10.0.5.155:587
EOF
chmod 755 /usr/bin/container-ports-fwd
cat > /etc/systemd/system/container-ports-forward.service << EOF
[Unit]
Description=Bring up port forwards for lxc
After=lxc-net.target
Before=lxc.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/container-ports-fwd

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable container-ports-fwd
systemctl start container-ports-fwd

I also installed and ran letsencrypt on the host:

sudo apt -y install letsencrypt
letsencrypt -d mail.example.org -m me@my.mail certonly

Next I started up the container and installed the basic mail tools:

sudo lxc-start -n mail
sudo lxc-attach -n mail apt -y install dovecot-imapd postfix mutt

New since my last mail server install is the removal of dovecot-postfix in favor of the mail-stack-delivery package:

sudo lxc-attach -n mail apt -y install mail-stack-delivery

After this I copied the letsencrypt keys into the container

lxc-attach -n mail -- mkdir -p /etc/letsencrypt/live/mail.example.org
cp /etc/letsencrypt/live/mail.example.org/* /var/lib/lxc/mail/rootfs//etc/letsencrypt/live/mail.example.org

and edited
/etc/postfix/main.cf and /etc/dovecot/conf.d/10-ssl.conf to point to those using these lines:

smtpd_tls_cert_file = /etc/letsencrypt/live/mail.example.org/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mail.example.org/privkey.pem

This is enough to be able to send and receive mail. Personally, I want to run this server in a uid-mapped container and from a luks-encrypted device. While you can setup the whole container that way from the start, for simplicity of examples, you could at this point copy over and uid-shift the container contents to a new device, and update the container configuration accordingly.

Some notes which I should elaborate on later:

SPF
• postscreen setup
• /etc/postfix/master.cf, i.e. uncomment smtps
• /etc/dovecot/conf.d details
Advertisement