Um diese Anleitung befolgen zu können brauchst du:

• einen Server mit Debian 10
• eine Domain für deinen Server

Um Emails von deinem Server verschicken und auf ihm empfangen zu können, brauchst du einen Mail Transfer Agent (MTA). In dieser Anleitung benutzen wir Exim. Exim ist auf Debian normalerweise vorinstalliert. Andernfalls kann es mit dem folgenden Befehl installiert werden.

# apt install exim

Debian kann über debconf automatisch angepasste Konfigurationsdateien für Exim erstellen. Dies passiert entweder bei der Installation des Pakets oder nachträglich mit:

# dpkg-reconfigure exim4-config

Da wir einen eigenen Mailserver erstellen wollen, der mit allen anderen Mailservern im Internet über SMTP kommunizieren kann, müssen wir auf der Seite zur Art des Email-Servers die folgende Option wählen:

General type of mail configuration: internet site; mail is sent and received directly using SMTP.

Auf der nächsten Seite geben wir den Mail-Namen an. Dieser entspricht dem hinteren Teil der Email-Adressen, die auf unserem Server Emails verschicken können sollen. Für die Email-Adresse user@anarcode.berlin wäre der richtige Mail-Name also anarcode.berlin.

System mail name: anarcode.berlin

Als nächstes sollen wir angeben, von welchen IP-Adressen unser Server Emails annehmen soll. Wenn Emails beispielsweise nur innerhalb eines Netzwerks benutzt werden sollen, kann man hier die IP-Adressen des Netzwerks angeben. In den meisten Fällen dürfte das Feld aber leer bleiben, damit Emails von überall empfangen werden können.

IP-addresses to listen on for incomming SMTP connections: // leer lassen

Im nächsten Schritt soll angegeben werden, für welche Domains sich unser Server als Empfänger entsteht. Wenn unsere Nutzer*innen also Email-Adressen wie user@anarcode.berlin haben, dann wäre hier der richtige Wert anarcode.berlin. Sollte unser Server dann eine Email bekommen, deren Empfänger bspw. user@gmail.com ist, dann wird unser Server diese Email als falsch zurückweisen, weil gmail.com eben keine akzeptierte Domain ist.

Other destinations for which mail is accepted: anarcode.berlin

Die nächsten beiden Schritte interessieren uns nur, wenn wir unseren Server als SMTP-Relay-Server benutzen wollen. Wenn du diese Anleitung liest, willst du das wahrscheinlich nicht und du solltest beide Felder leer lassen.

Domains to relay mail for: // leer lassen
Machines to relay mail for: // leer lassen

Die nächste Option ist nur für Schmalband-Internetzugänge relevant. Also für das Internet aus den 90ern, als man sich noch über eine Telefon-Einwahlleitung mit dem Internet verbunden hat. Wir lassen diese Einstellung daher deaktiviert.

Keep number of DNS-queries minimal (Dial-on-Demand)?: No

Als nächstes geht es darum, in welchem Format die empfangenen Emails auf dem Server abgespeichert werden sollen. Maildir ist das neuere Format und hat einen Haufen an Verbesserungen gegenüber mbox.

Delivery method for local mail: Maildir format in home directory

Danach ist die Frage, ob die Konfigurationsdatei in mehrere kleine Konfigurationsdateien aufgesplittert werden soll. Das beantworten wir hier mit nein.

Split configuration into small files?: No

Nun ist dein Mail Transfer Agent fertig eingerichtet. Nur werden die meisten deiner darüber verschickten Emails in Spam-Ordnern landen oder gar nicht erst ankommen. Damit das nicht passiert, musst du folgendes tun:

1. Bei deinem Domain-Anbieter legst du einen A-Record an, der für deine Domain auf deinen Email-Server zeigt. In unserem Beispiel könnte einfach anarcode.berlin auf die IP-Adresse unseres Email-Servers zeigen. Falls diese Domain schon auf die Adresse eines anderen Servers zeigt, können wir stattdessen bspw. mail.anarcode.berlin benutzen.
2. Für die in Schritt 1 benutzte Domain legst du zusätzlich einen MX Resource Record an. Dieser signalisiert, dass die Domain tatsächlich für Email zuständig ist.
3. Beim Internetanbieter deines Servers lässt du für die IP-Adresse deines Email-Servers Reverse DNS zu der in Schritt 1 und 2 benutzten Domain einrichten. Wenn du einen Server online mietest (den Internetanbieter also nicht selber kennst), schreib dazu dem Anbieter deines Servers. Unter Umständen kannst du die Einstellung auf der Webseite des Server-Anbieters sogar selber vornehmen.

Mit dem folgenden Shell-Skript können ausgehende Emails getestet werden. Dafür kannst du es auf dem Server einfach als testmail.sh abspeichern und mit chmod +x testmail.sh sicher stellen, dass die Datei ausführbar ist.

testmail.sh

#!/bin/sh
 
read -p "Betreff: " subject
read -p "Empfänger*inadresse: " to_address
read -p "Absender*inadresse: " from_address
date=$(date +'%a, %-d %b %Y %H:%M:%S %z')
 
/usr/sbin/sendmail $to_address <<MAIL_END
Subject: $subject
To: $to_address
From: $from_address
Date: $date
 
Dies ist eine Testnachricht
.
MAIL_END

Anschließend kannst du das Skript mit ./testmail.sh ausführen (du musst das als Root-Nutzer*in tun). Das Skript fragt dich dann nach Betreff, Empfänger*in- und Absender*inadresse. Wenn du alles eingegeben hast, wird die Test-Email verschickt. Wenn alles gut gelaufen ist, sollte sie bei der angegebenen Empfänger*inadresse ankommen.

Du kannst testen, ob dein Server Emails empfangen kann, indem du einfach eine Email an eine Nutzer*in auf deinem Debian-System verschickst. Wenn du zum Beispiel in Debian die Nutzer*in user hast und die im MTA eingerichtete Domain anarcode.berlin ist, dann kannst du eine Test-Email an user@anarcode.berlin verschicken. Diese sollte dann im Home-Ordner der Nutzer*in im Ordner Maildir landen (also in der Regel /home/user/Maildir). Einlesen kannst du das Maildir mit dem Programm mutt.

# apt install mutt
# mutt -f /home/user/Maildir

In mutt kannst du dann alle Emails lesen, die an die entsprechende Nutzer*in geschickt wurden.

Bisher kann sich mit unserem MTA über SMTP nur unverschlüsselt verbunden werden. Um das zu ändern, können wir uns ein TLS-Zertifikat von Let's Encrypt holen:

# apt install certbot
# certbot certonly --standalone -d anarcode.berlin

Statt anarcode.berlin solltest du hier die Domain angeben, die du als MX Resource Record bei deinem Domain-Anbieter hinterlegt hast. Das generierte Zertifikat und den privaten Schlüssel müssen wir anschließend noch an die richtige Stelle für Exim kopieren und die korrekten Dateizugriffsrechte setzen. Das muss auch immer wiederholt werden, wenn das Zertifikat abgelaufen ist und in /etc/letsencrypt/live/anarcode.berlin/ die neuen Zertifikate liegen (anarcode.berlin ist hier wieder mit der Domain aus dem MX Resource Record zu ersetzen).

# cp /etc/letsencrypt/live/anarcode.berlin/fullchain.pem /etc/exim4/exim.crt
# cp /etc/letsencrypt/live/anarcode.berlin/privkey.pem /etc/exim4/exim.key
# chown root:Debian-exim /etc/exim4/exim.crt /etc/exim4/exim.key

Anschließend muss in der Exim-Konfiguration noch die Benutzung von TLS aktiviert werden und die Konfiguration neu geladen werden.

/etc/defaut/exim4

...
SMTPLISTENEROPTIONS='-oX 25:587:10025 -oP /run/exim4/exim.pid'

# echo "MAIN_TLS_ENABLE = yes" >> /etc/exim4/exim4.conf.localmacros
# update-exim4.conf
# systemctl restart exim4.service

Der Port 587 für SMTPS muss nun noch geöffnet werden. Wenn du die Uncomplitated Firewall (ufw) installiert hast, geht das mit.

# ufw allow 587/tcp

Bisher funktionieren Emails einwandfrei, solange wir sie direkt von unserem Server verschicken und direkt auf ihm lesen. So werden Emails aber üblicherweise nicht benutzt. Ein Message Store kümmert sich darum, dass Nutzer*innen von ihrem Computer auf die auf dem Server gespeicherten Emails zugreifen können. In dieser Anleitung verwenden wir Dovecot als Message Store. Als Protokoll zum Zugriff auf das Postfach benutzen wir IMAP.

# apt install dovecot-core dovecot-imapd