Network cables, potentially transporting e-mail

Root server with IPv6-only KVM guests (III): Mail server with Postfix, Dovecot – and IPv4 2


This artic­le is out­da­ted, find its repla­ce­ment in the IPv6-first guide
I’ve updated this artic­le bet­ween 2018 and 2020 con­stant­ly but final­ly deci­ded that I need ano­ther for­mat for this infor­ma­ti­on. So I wro­te the IPv6-first gui­de which you can read online as HTML or PDF docu­ment. It’s CC-BY-SA-licen­sed and its sources can be found on Github
Root ser­ver with IPv6-only KVM guests
(1) The basic set­up(2) NAT64, DNS64, and KVM – (3) Mail ser­ver with Post­fix, Dove­cot – and IPv4 – (4) The IPv6-first guide

When it comes to a com­ple­te per­so­nal inter­net ser­vices set­up, the sin­gle most important ser­vice is pro­ba­b­ly e‑mail. It is cru­cial for many dif­fe­rent tasks:

  • Of cour­se, sen­ding and recei­ving infor­ma­ti­on to and from other people.
  • Having a base for the other ser­vices to veri­fy or re-veri­fy authen­ti­ca­ti­on – ever tried to reset a pass­word to a ser­vice wit­hout an e‑mail account?
  • Get­ting infor­ma­ti­on about the health of the own sys­tems or con­fir­ma­ti­on mes­sa­ges of auto­ma­tic tasks.
Network cables, potentially transporting e-mail

Net­work cables, poten­ti­al­ly trans­port­ing e‑mail

E‑mail is important. The ques­ti­on is: Host yours­elf or use a ser­vice? To be clear: Hos­ting an e‑mail ser­ver yours­elf the­se days is not a simp­le task. The­re is a ple­tho­ra of – more or less cle­ver – sche­mes against spamming and fraud and if your ser­ver does not fol­low them, it is quite likely that out­go­ing mes­sa­ges will sim­ply be blo­cked or even thrown away by other sys­tems. If you mess up your set­up, the same could acci­den­ti­al­ly hap­pen to inco­ming mes­sa­ges. And unfort­u­na­te­ly, you will not find a tool which you install out of the box so that you just „have” a mail ser­ver. You have to con­fi­gu­re mul­ti­ple pro­grams so that they play nice­ly together.

The advan­ta­ges, howe­ver, are obvious: It’s your own e‑mail on your own ser­ver. You are not bound to any sto­rage capa­ci­ties you have to pay for. You can con­fi­gu­re the ser­vices as you like. If you mis­con­fi­gu­re them, it’s your fault and only your fault.

Having said all this, the­re is one thing that is abso­lut­e­ly impos­si­ble today: Run­ning an e‑mail ser­ver for a domain wit­hout an IPv4 address. While this is tech­ni­cal­ly no pro­blem, the­re are so many e‑mail ser­vers out the­re which are frank­ly IPv4-only that you are more or less cut off any meaningful e‑mail ser­vice. And due to the afo­re­men­tio­ned anti-spam mea­su­res, it is also not pos­si­ble to use port-for­war­ding from the phy­si­cal host into the vir­tu­al machi­ne for the IPv4 con­nec­ti­vi­ty. At least, I could not figu­re out how to do this reliably.

So, unfort­u­na­te­ly the very first „real” ser­vice we descri­be in this „IPv6-only” artic­le series will be dual-sta­cked with its own IPv4 address.

Remar­kab­ly low amount of IPv6 traffic
It is remar­kab­le how small the amount of IPv6 e‑mail traf­fic actual­ly seems to be. This set­up crea­tes a mail ser­ver which is reacha­ble by IPv4 and IPv6 in abso­lut­e­ly equal man­ner. Howe­ver, the actu­al amount of inco­ming IPv6 traf­fic is less than 2%. And the­se are the num­bers of August 2019. It is a bit devastating…

Basic server and network setup

So, here we are. Start with brin­ging up a fresh vir­tu­al ser­ver as descri­bed in the pre­vious artic­le of this series. All the advi­ses I men­tio­ned the­re app­ly. I gave my e‑mail ser­ver a vir­tu­al hard­disk of 250 GB – of which 60 GB are curr­ent­ly used. It has 6 GB of main memo­ry. This is rather a lot, but with 64 GB of phy­si­cal memo­ry in the host, it is no pro­blem either…

Per­form all steps so that you have your e‑mail ser­ver-to-be acces­si­ble from out­side via IPv6 ssh con­nec­tions with an DNS ent­ry of your domain.

Add IPv4 connectivity

As I explai­ned, our vir­tu­al ser­ver with the e‑mail ser­vices needs its own IPv4 address. We add this only for the needs of the e‑mail sys­tem. Apart from that, the ser­ver is still IPv6-only. If we ever come to a point whe­re e‑mail ser­vers can ope­ra­te IPv6-only, it can sim­ply be swit­ched off and ever­y­thing con­ti­nues to work. Add IPv4 con­nec­ti­vi­ty to the vir­tu­al mail host as follows:

  • Obtain an addi­tio­nal IPv4 address for your ser­ver from your hos­ter. If you alre­a­dy have a net­work of them assi­gned to your ser­ver, you can use one of tho­se, of course.
  • The actu­al set­up, of cour­se, depends on the net­work sche­me of your pro­vi­der. Hetz­ner imple­ments a direct peer-to-peer rou­ting of IPv4 addres­ses. With Ubun­tu 18.04, do this:
  • On a sys­tem with sys­temd-net­work set­up, add an ent­ry to the bridge device con­fi­gu­ra­ti­on. In the initi­al artic­le of this series, this is the file /etc/systemd/network/21-br0-conf.network. Add the fol­lo­wing lines: 

    The­re are two [Address] ent­ries now in this file which both have the same Address but dif­fe­rent Peer ent­ries. That’s intentional.

  • If the host is con­fi­gu­red with Net­plan, add the rou­te to the vir­tu­al guest explicitly: 
  • More infor­ma­ti­on needed
    The­re is not that much infor­ma­ti­on about Net­plan-based net­work con­fi­gu­ra­ti­on stuff in the inter­net, unfort­u­na­te­ly. Let me know if this con­fi­gu­ra­ti­on did not work for you.
  • On the vir­tu­al mail ser­ver, add the IPv4 address to the Net­plan con­fi­gu­ra­ti­on, usual­ly in /etc/netplan/01-netcfg.yaml. It reads com­ple­te­ly like this: 

    The host is the IPv4 gateway!
    Note that – at least in the Hetz­ner net­work – it is cru­cial that you decla­re the host machi­ne as the gate­way for IPv4 traf­fic from the vir­tu­al guest ser­vers! If you set the gate­way given by Hetz­ner, traf­fic is not rou­ted. In this case, you can reach the guest from the host but from nowhe­re else via IPv4.
  • Now, add DNS and rever­se DNS ent­ries for both the IPv4 and IPv6 address for the mail server.

After the­se steps, your vir­tu­al e‑mail ser­ver should be acces­si­ble via ssh by both IPv4 and IPv6 connections.

Setup of the mail system

After having the ser­ver pre­pai­red on net­work and sys­tem level, it is time to actual­ly set­up the mail sys­tem. And here I must admit, that I have not deve­lo­ped my own sche­me. Ins­tead, I followed

https://​tho​mas​-leis​ter​.de/​e​n​/​m​a​i​l​s​e​r​v​e​r​-​d​e​b​i​a​n​-​s​t​r​e​t​ch/

Tho­mas descri­bes the set­up of a modern e‑mail ser­ver set­up. The ser­ver allows for inco­ming and out­go­ing traf­fic. It is set­up accor­ding to all anti-spam requi­re­ments with DKIP, DMARC and SPF ent­ries in DNS. It offers SMTP and IMAP access for cli­ents. It is a mul­ti-user mul­ti-domain set­up. I run this for near­ly a year now wit­hout any problems.

Additional notes

Having said this, the­re are some points to add:

First and fore­most, it hel­ped me tre­men­dous­ly to under­stand that you should use a total­ly unre­la­ted domain for the mail ser­ver – espe­ci­al­ly, if you plan to ser­ve mul­ti­ple domains on it. Let’s assu­me you want to ser­ve example.net and example.com e‑mail on your ser­ver. My advi­se to set­up this:

  • Obtain beispiel.de as an inde­pen­dent domain only for e‑mail. For my own set­up, I obtai­ned a .email domain. It cos­ts a bit more than a simp­le .de domain, but it’s real­ly nifty…
  • Use this domain as pri­ma­ry domain in the set­up docu­men­ta­ti­on.
  • Let the main e‑mail name ser­ver, usual­ly mx0.beispiel.de, have A and AAAA DNS ent­ries. After all, this set­up works for both IP address spaces.
  • Point the MX ent­ry for any domain you want to ser­ve on your ser­ver to that mx0.beispiel.de. Remem­ber – the MX for a domain can be in any domain!
  • After having set­up the DNS for the first „real” domain, say example.net, you can sim­ply copy SPF, DMARC, and DKIP ent­ries from that domain to example.com and whi­che­ver other domain you want to serve.
  • Add the IPv4 addres­ses and the IPv6 net­work of the who­le ser­ver to the mynetworks list in /etc/postfix/main.cf. That makes your mail­ser­ver a smart host for all other ser­vers. So, every of your vir­tu­al ser­vers – and even the phy­si­cal machi­ne – can send e‑mail wit­hout any fur­ther set­up steps. You just have to add the mail ser­ver as smart host (or for­war­ding host) for all out­go­ing e‑mail.
  • Regar­ding the DNS set­up of the mail ser­ver its­elf: This is the only of your vir­tu­al ser­vers which should not use the DNS64/NAT64 set­up of the phy­si­cal host! This ser­ver is ful­ly con­nec­ted to IPv4, so it can reach all IPv4 ser­vers direct­ly. It also must do so, other­wi­se out­go­ing IPv4 con­nec­tions would come from the „wrong” IPv4 address and the who­le anti-spam may­hem would start again. The mail ser­ver set­up ins­truc­tions sug­gest to install a small DNS ser­ver on the mail ser­ver. Just fol­low that ins­truc­tions and you’­re done.
    DNS on arbi­tra­ry guests with addi­tio­nal IPv4 connectivity
    If you add direct IPv4 con­nec­ti­vi­ty to a vir­tu­al machi­ne for other reasons than mail traf­fic, the rou­ting of out­go­ing IPv4 traf­fic is not cri­ti­cal. The machi­ne may con­nect to IPv4 ser­vers through NAT64 wit­hout any draw­backs. The important thing this is that the vir­tu­al guest ser­ves inco­ming IPv4 con­nec­tions direct­ly – and this is the case with the con­fi­gu­ra­ti­on descri­bed abo­ve. Remem­ber that the who­le NAT64/DNS64 magic hap­pens at the DNS lay­er. My advice is to gene­ral­ly not con­fi­gu­re a spe­cial DNS ser­ver for vir­tu­al guests with direct IPv4 con­nec­ti­vi­ty but use the DNS64-enhan­ced sys­tem from the IPv6 auto configuration.

Set­ting things up like this makes the fur­ther DNS set­up rather simp­le: All your mail cli­ents con­nect to the dedi­ca­ted mail ser­ver domain, in the exam­p­le mx0.beispiel.de, also tho­se for example.net, example.com or wha­te­ver. This way, you only need SSL cer­ti­fi­ca­tes for the mail domain.

Consistency of DNS entries

Two things are abso­lut­e­ly cru­cial regar­ding the name ser­vice set­up of the mail server:

  1. The DNS and rever­se DNS ent­ries for the mail exch­an­ge ser­ver must be con­sis­tent! The A and AAAA record for mx0.beispiel.de must both point to the vir­tu­al ser­ver in your set­up and the PTR rever­se ent­ries of the IP addres­ses must point back to mx0.beispiel.de. This is the main reason why we need that addi­tio­nal IPv4 address and why I stron­gly recom­mend to use a dedi­ca­ted domain for this. If you fail in this set­up step, you will have mas­si­ve pro­blems with out­go­ing e‑mail being spam­blo­cked (and noo­ne wil­ling to help you…).
  2. It is also important that the myhostname set­ting in /etc/postfix/main.cf must con­tain the full qua­li­fied domain name of that mail ser­ver, i.e. mx0.beispiel.de in this exam­p­le. The who­le mail ser­ver is main­ly known in DNS by its mail domain name.

Setup of mail clients

As I alre­a­dy explai­ned, the mail domains which are hos­ted on the sys­tem can have total­ly dif­fe­rent names! The­re are also no PTR records nee­ded. For each mail domain, the fol­lo­wing steps must be done:

  • An MX ent­ry in DNS must exist and point to mx0.beispiel.de.
  • The domain and the users must be ente­red in the data sto­rage for post­fix and dove­cot (no reboot requi­red after chan­ges). Just fol­low the set­up descrip­ti­on of Tho­mas Leis­ter above.
  • Users set the log­in name in their mail pro­grams to e.g. username@example.net.
  • They should, as alre­a­dy explai­ned, set IMAP and SMTP ser­ver name to the name of the mail ser­ver, e.g. mx0.beispiel.de, not to any­thing in their actu­al domain! Even if the­re are DNS ent­ries poin­ting to the mail ser­ver, the­re would be mas­si­ve cer­ti­fi­ca­te war­nings as the SSL cer­ti­fi­ca­tes do not con­tain the mail domains, but only the domain of the mail server.

Looking forward

As I wro­te, I use this set­up now for almost a year wit­hout any pro­blems. I’ve also added a num­ber of domains to my ser­ver. This takes only minu­tes, works wit­hout pro­blems and covers all kinds of set­ups like local deli­very, deli­very to mul­ti­ple addres­ses, for­war­ding, catch-all addres­ses. It is a real­ly fine thing.

You might miss a web­mail inter­face. I have deci­ded not to add that to the mail ser­ver, but to one of the vir­tu­al web ser­vers. Set­up of tho­se is cover­ed in the next artic­le of this series. Stay tuned.

This artic­le is out­da­ted, find its repla­ce­ment in the IPv6-first guide
I’ve updated this artic­le bet­ween 2018 and 2020 con­stant­ly but final­ly deci­ded that I need ano­ther for­mat for this infor­ma­ti­on. So I wro­te the IPv6-first gui­de which you can read online as HTML or PDF docu­ment. It’s CC-BY-SA-licen­sed and its sources can be found on Github

History

  • 2020-03-19: Enhan­ce descrip­ti­on of Net­plan-based con­fi­gu­ra­ti­on of the host
  • 2020-08-09: Repla­ced by the IPv6-first gui­de
This artic­le is out­da­ted, find its repla­ce­ment in the IPv6-first guide
I’ve updated this artic­le bet­ween 2018 and 2020 con­stant­ly but final­ly deci­ded that I need ano­ther for­mat for this infor­ma­ti­on. So I wro­te the IPv6-first gui­de which you can read online as HTML or PDF docu­ment. It’s CC-BY-SA-licen­sed and its sources can be found on Github

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

2 Gedanken zu “Root server with IPv6-only KVM guests (III): Mail server with Postfix, Dovecot – and IPv4

  • Jan Söderback

    Regar­ding IPv4 and net­plan, I could­n’t get your host exam­p­le to work, ins­tead I had to add an expli­cit rou­te to the IPv4 VM on the host.

    network:
    # …
    bridges:
    br0:
    # …, addres­ses sec­tion does *not* include guest address
    routes:
    – on-link: true
    to: 0.0.0.0/0
    via: x.y.z.a # Hetz­ner gate­way address
    – to: x.y.z.b # guest address
    scope: host

    The „scope: host” is essen­ti­al, I believe.

    Net­plan con­fig on guest is as in your example.

    Thank you very much for this gui­de, I have been strugg­ling to get IPv6 working on ano­ther libvirt-based Hetz­ner setup.

    • Dirk Hillbrecht Autor des Beitrags

      Hel­lo Jan,

      thank you for your com­ment. Inde­ed, this set­up was never tes­ted by me. Now I had the situa­ti­on for the first time with a Net­plan-based host sys­tem. For the com­bi­na­ti­on of Ger­man hos­ter Hetz­ner and Ubun­tu 18.04 I found that I had to chan­ge NOTHING at the host con­fi­gu­ra­ti­on. Traf­fic is just rou­ted into the bridge and taken by the vir­tu­al machi­ne. I’ve updated the descrip­ti­on accordingly.

      Best regards,
      Dirk