When it comes to a complete personal internet services setup, the single most important service is probably e‑mail. It is crucial for many different tasks:
- Of course, sending and receiving information to and from other people.
- Having a base for the other services to verify or re-verify authentication – ever tried to reset a password to a service without an e‑mail account?
- Getting information about the health of the own systems or confirmation messages of automatic tasks.
Network cables, potentially transporting e‑mail
E‑mail is important. The question is: Host yourself or use a service? To be clear: Hosting an e‑mail server yourself these days is not a simple task. There is a plethora of – more or less clever – schemes against spamming and fraud and if your server does not follow them, it is quite likely that outgoing messages will simply be blocked or even thrown away by other systems. If you mess up your setup, the same could accidentially happen to incoming messages. And unfortunately, you will not find a tool which you install out of the box so that you just „have” a mail server. You have to configure multiple programs so that they play nicely together.
The advantages, however, are obvious: It’s your own e‑mail on your own server. You are not bound to any storage capacities you have to pay for. You can configure the services as you like. If you misconfigure them, it’s your fault and only your fault.
Having said all this, there is one thing that is absolutely impossible today: Running an e‑mail server for a domain without an IPv4 address. While this is technically no problem, there are so many e‑mail servers out there which are frankly IPv4-only that you are more or less cut off any meaningful e‑mail service. And due to the aforementioned anti-spam measures, it is also not possible to use port-forwarding from the physical host into the virtual machine for the IPv4 connectivity. At least, I could not figure out how to do this reliably.
So, unfortunately the very first „real” service we describe in this „IPv6-only” article series will be dual-stacked with its own IPv4 address.
Basic server and network setup
So, here we are. Start with bringing up a fresh virtual server as described in the previous article of this series. All the advises I mentioned there apply. I gave my e‑mail server a virtual harddisk of 250 GB – of which 60 GB are currently used. It has 6 GB of main memory. This is rather a lot, but with 64 GB of physical memory in the host, it is no problem either…
Perform all steps so that you have your e‑mail server-to-be accessible from outside via IPv6 ssh connections with an DNS entry of your domain.
Add IPv4 connectivity
As I explained, our virtual server with the e‑mail services needs its own IPv4 address. We add this only for the needs of the e‑mail system. Apart from that, the server is still IPv6-only. If we ever come to a point where e‑mail servers can operate IPv6-only, it can simply be switched off and everything continues to work. Add IPv4 connectivity to the virtual mail host as follows:
- Obtain an additional IPv4 address for your server from your hoster. If you already have a network of them assigned to your server, you can use one of those, of course.
- The actual setup, of course, depends on the network scheme of your provider. Hetzner implements a direct peer-to-peer routing of IPv4 addresses. With Ubuntu 18.04, do this:
- On a system with systemd-network setup, add an entry to the bridge device configuration. In the initial article of this series, this is the file
/etc/systemd/network/21-br0-conf.network. Add the following lines:123[Address]Address=<IPv4 address of the host>Peer=<IPv4 address of the guest for e-mail server>/32There are two [Address] entries now in this file which both have the same Address but different Peer entries. That’s intentional.
- If the host is configured with Netplan, add the route to the virtual guest explicitly:
- On the virtual mail server, add the IPv4 address to the Netplan configuration, usually in
/etc/netplan/01-netcfg.yaml. It reads completely like this:12345678network:version: 2renderer: networkdethernets:ens3:dhcp6: yesaddresses: [ IPv4 address for the guest/24 ]gateway4: IPv4 address OF THE HOSTThe host is the IPv4 gateway!Note that – at least in the Hetzner network – it is crucial that you declare the host machine as the gateway for IPv4 traffic from the virtual guest servers! If you set the gateway given by Hetzner, traffic is not routed. In this case, you can reach the guest from the host but from nowhere else via IPv4. - Now, add DNS and reverse DNS entries for both the IPv4 and IPv6 address for the mail server.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
root@merlin ~ # cat /etc/netplan/01-netcfg.yaml network: [...] bridges: br0: [...] addresses: - 241.61.86.241/32 - 2a01:4f8:1:3::2/64 routes: [...] - to: 241.61.86.104/32 # <– IPv4 address of the virtual machine via: 241.61.86.241 # <– IPv4 address of the host [...] |
After these steps, your virtual e‑mail server should be accessible via ssh by both IPv4 and IPv6 connections.
Setup of the mail system
After having the server prepaired on network and system level, it is time to actually setup the mail system. And here I must admit, that I have not developed my own scheme. Instead, I followed
https://thomas-leister.de/en/mailserver-debian-stretch/
Thomas describes the setup of a modern e‑mail server setup. The server allows for incoming and outgoing traffic. It is setup according to all anti-spam requirements with DKIP, DMARC and SPF entries in DNS. It offers SMTP and IMAP access for clients. It is a multi-user multi-domain setup. I run this for nearly a year now without any problems.
Additional notes
Having said this, there are some points to add:
First and foremost, it helped me tremendously to understand that you should use a totally unrelated domain for the mail server – especially, if you plan to serve multiple domains on it. Let’s assume you want to serve example.net and example.com e‑mail on your server. My advise to setup this:
- Obtain
beispiel.deas an independent domain only for e‑mail. For my own setup, I obtained a.emaildomain. It costs a bit more than a simple.dedomain, but it’s really nifty… - Use this domain as primary domain in the setup documentation.
- Let the main e‑mail name server, usually
mx0.beispiel.de, haveAandAAAADNS entries. After all, this setup works for both IP address spaces. - Point the
MXentry for any domain you want to serve on your server to thatmx0.beispiel.de. Remember – the MX for a domain can be in any domain! - After having setup the DNS for the first „real” domain, say
example.net, you can simply copy SPF, DMARC, and DKIP entries from that domain toexample.comand whichever other domain you want to serve. - Add the IPv4 addresses and the IPv6 network of the whole server to the
mynetworkslist in/etc/postfix/main.cf. That makes your mailserver a smart host for all other servers. So, every of your virtual servers – and even the physical machine – can send e‑mail without any further setup steps. You just have to add the mail server as smart host (or forwarding host) for all outgoing e‑mail. - Regarding the DNS setup of the mail server itself: This is the only of your virtual servers which should not use the DNS64/NAT64 setup of the physical host! This server is fully connected to IPv4, so it can reach all IPv4 servers directly. It also must do so, otherwise outgoing IPv4 connections would come from the „wrong” IPv4 address and the whole anti-spam mayhem would start again. The mail server setup instructions suggest to install a small DNS server on the mail server. Just follow that instructions and you’re done.
DNS on arbitrary guests with additional IPv4 connectivityIf you add direct IPv4 connectivity to a virtual machine for other reasons than mail traffic, the routing of outgoing IPv4 traffic is not critical. The machine may connect to IPv4 servers through NAT64 without any drawbacks. The important thing this is that the virtual guest serves incoming IPv4 connections directly – and this is the case with the configuration described above. Remember that the whole NAT64/DNS64 magic happens at the DNS layer. My advice is to generally not configure a special DNS server for virtual guests with direct IPv4 connectivity but use the DNS64-enhanced system from the IPv6 auto configuration.
Setting things up like this makes the further DNS setup rather simple: All your mail clients connect to the dedicated mail server domain, in the example mx0.beispiel.de, also those for example.net, example.com or whatever. This way, you only need SSL certificates for the mail domain.
Consistency of DNS entries
Two things are absolutely crucial regarding the name service setup of the mail server:
- The DNS and reverse DNS entries for the mail exchange server must be consistent! The
AandAAAArecord formx0.beispiel.demust both point to the virtual server in your setup and thePTRreverse entries of the IP addresses must point back tomx0.beispiel.de. This is the main reason why we need that additional IPv4 address and why I strongly recommend to use a dedicated domain for this. If you fail in this setup step, you will have massive problems with outgoing e‑mail being spamblocked (and noone willing to help you…). - It is also important that the
myhostnamesetting in/etc/postfix/main.cfmust contain the full qualified domain name of that mail server, i.e.mx0.beispiel.dein this example. The whole mail server is mainly known in DNS by its mail domain name.
Setup of mail clients
As I already explained, the mail domains which are hosted on the system can have totally different names! There are also no PTR records needed. For each mail domain, the following steps must be done:
- An MX entry in DNS must exist and point to
mx0.beispiel.de. - The domain and the users must be entered in the data storage for postfix and dovecot (no reboot required after changes). Just follow the setup description of Thomas Leister above.
- Users set the login name in their mail programs to e.g.
username@example.net. - They should, as already explained, set IMAP and SMTP server name to the name of the mail server, e.g.
mx0.beispiel.de, not to anything in their actual domain! Even if there are DNS entries pointing to the mail server, there would be massive certificate warnings as the SSL certificates do not contain the mail domains, but only the domain of the mail server.
Looking forward
As I wrote, I use this setup now for almost a year without any problems. I’ve also added a number of domains to my server. This takes only minutes, works without problems and covers all kinds of setups like local delivery, delivery to multiple addresses, forwarding, catch-all addresses. It is a really fine thing.
You might miss a webmail interface. I have decided not to add that to the mail server, but to one of the virtual web servers. Setup of those is covered in the next article of this series. Stay tuned.
History
- 2020-03-19: Enhance description of Netplan-based configuration of the host
- 2020-08-09: Replaced by the IPv6-first guide
Regarding IPv4 and netplan, I couldn’t get your host example to work, instead I had to add an explicit route to the IPv4 VM on the host.
network:
# …
bridges:
br0:
# …, addresses section does *not* include guest address
routes:
– on-link: true
to: 0.0.0.0/0
via: x.y.z.a # Hetzner gateway address
– to: x.y.z.b # guest address
scope: host
The „scope: host” is essential, I believe.
Netplan config on guest is as in your example.
Thank you very much for this guide, I have been struggling to get IPv6 working on another libvirt-based Hetzner setup.
Hello Jan,
thank you for your comment. Indeed, this setup was never tested by me. Now I had the situation for the first time with a Netplan-based host system. For the combination of German hoster Hetzner and Ubuntu 18.04 I found that I had to change NOTHING at the host configuration. Traffic is just routed into the bridge and taken by the virtual machine. I’ve updated the description accordingly.
Best regards,
Dirk