Network cables, potentially transporting e-mail

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


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, Dovecot – and IPv4

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­bab­ly e‑mail. It is cru­ci­al for many dif­fe­rent tasks:

  • Of cour­se, sen­ding and recei­ving infor­ma­ti­on to and from other peop­le.
  • 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 messa­ges of auto­ma­tic tasks.
Network cables, potentially transporting e-mail

Net­work cables, poten­ti­al­ly trans­por­ting 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 pletho­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 qui­te likely that out­go­ing messa­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­m­ing messa­ges. And unfor­tu­n­a­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 tog­e­ther.

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­lute­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 mea­ning­ful 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­tivi­ty. At least, I could not figu­re out how to do this reli­ab­ly.

So, unfor­tu­n­a­te­ly the very first „real” ser­vice we descri­be in this „IPv6-only” arti­cle series will be dual-sta­cked with its own IPv4 address.

Remar­kab­ly low amount of IPv6 traf­fic
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 reach­a­ble by IPv4 and IPv6 in abso­lute­ly equal man­ner. Howe­ver, the actu­al amount of inco­m­ing IPv6 traf­fic is less than 2%. And the­se are the num­bers of August 2019. It is a bit devas­ta­ting…

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 arti­cle 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 cur­r­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 eit­her…

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

Add IPv4 connectivity

As I exp­lai­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­ything con­ti­nues to work. Add IPv4 con­nec­tivi­ty to the vir­tu­al mail host as fol­lows:

  • Obtain an addi­tio­nal IPv4 address for your ser­ver from your hos­ter. If you alrea­dy have a net­work of them assi­gned to your ser­ver, you can use one of tho­se, of cour­se.
  • 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 arti­cle 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 inten­tio­nal.

  • If the host is con­fi­gu­red with Net­plan, sim­ply add the IPv4 address to the bridge’s addres­ses:
  • This is untested
    Note that I actual­ly could not test the Net­plan-based set­up on a machi­ne. Plea­se let me know if this does not work as inten­ded – and how to fix it…
  • 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:

  • Now, add DNS and rever­se DNS ent­ries for both the IPv4 and IPv6 address for the mail ser­ver.

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

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 fol­lo­wed

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­m­ing and out­go­ing traf­fic. It is set­up accord­ing 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 pro­blems.

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 costs a bit more than a simp­le .de domain, but it’s real­ly nif­ty…
  • 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 whiche­ver other domain you want to ser­ve.
  • 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 direc­t­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 inst­ruc­tions sug­gest to install a small DNS ser­ver on the mail ser­ver. Just fol­low that inst­ruc­tions and you’­re done.

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 examp­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­lute­ly cru­ci­al regar­ding the name ser­vice set­up of the mail ser­ver:

  1. The DNS and rever­se DNS ent­ries for the mail exchan­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 rea­son 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 examp­le. The who­le mail ser­ver is main­ly known in DNS by its mail domain name.

Setup of mail clients

As I alrea­dy exp­lai­ned, the mail domains which are hosted 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 ent­e­red in the data sto­rage for post­fix and dovecot (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 alrea­dy exp­lai­ned, set IMAP and SMTP ser­ver name to the name of the mail ser­ver, e.g. mx0.beispiel.de, not to anything 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 warnings as the SSL cer­ti­fi­ca­tes do not con­tain the mail domains, but only the domain of the mail ser­ver.

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 cove­r­ed in the next arti­cle of this series. Stay tun­ed.

Schreibe einen Kommentar

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