Mailserver für das LAN in einer VM auf einer DS+

[thc]

Hallo zusammen,
in https://www.synology-forum.de/threads/nextcloudpi-mit-vmm.132460 habe ich beschrieben, wie ich NextCloud in einer VM an den Start gebracht habe.
Weil das so gut geklappt hat, ist jetzt das Thema Mailserver dran.
Der läuft zur Zeit noch zusammen mit Samba und dem VDR auf einem Debian-11-PC.
Da die DS aber sowieso immer an ist, kann sie zukünftig auch gerne den Mailserver beherbergen.
Ja: Ich habe gelesen, dass Synology ein eigenes Paket dafür anbietet.
Ich habe aber gerne die volle Kontrolle über so einen Server.
Ich teile die einzelnen Schritte in eigene Beiträge auf, weil das Ganze doch etwas länger wird und imho so leichter zu refenrenzieren und bei Bedarf zu ändern ist.
Am Anfang steht immer ein Link zu einer Webseite, wenn ich diese für das Thema selbst nützlich gefunden habe.

Bitte erst antworten, wenn ein Moderator alle Teilbeiträge freigeschaltet hat - dann ist das Ganze erst komplett.

 

[thc]

Thema: VM installieren

Wirklich wichtig finde ich die RAM-Ausstattung, weshalb sich dafür eigentlich nur eine DS mit + am Ende eignet, weil man die aufrüsten kann.
Die Einrichtung ist ansonsten recht trivial.
1 Kern
erstmal 4 GB RAM
20 GB HDD - eigentlich viel zu viel, aber der Platz ist ja reichlich da
VirtIO
Debian-iso zuweisen
VM starten und Basis-Installation durchführen.
Dabei kann ein sparsamer Desktop ausgewählt werden, muss aber nicht.
Ich richte sowieso nahezu alles mit PuTTY und WinSCP ein.
Nach dem abschließenden Reboot qemu-guest-agent nachinstallieren.
Herunterfahren und einen ersten Snapshot machen.

 

[thc]

Thema: Erste Anpassungen

1. ssh-Zugriff für root mit PubKey ermöglichen
Modern ist sudo - ich bin so alt, dass ich mich daran nicht mehr gewöhnen möchte.
Dazu also mit z.B. PuTTY und WinSCP als Benutzer aus der Basis-Installation anmelden und die Konfiguration an eine Stelle umkopieren, wo man sie ändern darf:
cp -av /etc/ssh/sshd_config /tmp
Mit WinSCP anpassen, damit sich root mit PubKey (und erstmal auch mit Kennwort) anmelden darf.
Eine (hoffentlich schon existierende) authorized_keys ebenfalls nach /tmp kopieren.
In der Shell zu root wechseln und die Dateien übernehmen:
sudo -s /bin/bash
cd /root/.ssh
cp -av /tmp/authorized_keys .
chown root:root authorized_keys
chmod 600 authorized_keys
cd /etc/ssh
cp -av sshd_config sshd_config.del
cp -av /tmp/sshd_config .
chown root:root sshd_config
chmod 644 sshd_config
systemctl restart ssh.service
Danach das Anmelden mit PubKey testen.
Wenn das klappt, mit PasswordAuthentication no selbige abschalten.
Wenn nicht, mit Kennwort anmelden und Fehler suchen.

2. Danach ist es Zeit, die ~/.bashrc nach den eigenen Vorlieben anzupassen
Farben, bash-History und geliebte alias-Einstellungen anpassen, z.B.
alias ll='ls -al'
alias p1='ping -c 1'
alias histgrep='history|grep -i $1'
Testen

3. auf anderen Servern bereits vorhandene Skripte importieren und anpassen, wenn vorhanden
Bei mir ist das einiges in /usr/local/sbin, z.B. zum Anlegen von Benutzern für Mail und Samba.
VM herunterfahren und nächsten Snapshot anlegen.

 

[thc]

Thema: Mail-Server einrichten

Ich habe seit vielen Jahren die Kombination aus fetchmail, postfix und courier-imap am Start.
courier-imap legt allerdings seine eigenen Dateien direkt bei den Mails ab.
Da diese in einem NFS-Share auf dem NAS angesiedelt werden sollen, probiere ich es hier statt dessen mal mit Dovecot.
Das soll Probleme mit NFS vermeiden und die ganzen Mail-Dateien sind in einem späteren produktiven Betrieb bestimmt auch besser in /volume2 auf einem SSD-RAID-1 aufgehoben als in der VM.
Während der ganzen Aktion habe ich es als hilfreich empfunden, die Logs nicht an syslog zu übergeben, sondern nach /var/log/mail.log schreiben zu lassen.
Und diese Datei in einem eigenen PuTTY-Fenster mit einem tail -f zu beobachten.

1. NFS
https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nfs-mount-on-debian-11
Also auf dem NAS ein Share dafür einrichten - bei mir VM-Mail mit no_squash, damit UID und GID erhalten bleiben.
Darin ein Ordner VM-Mail_home_vmail.sync, der dann mit NFS in der VM als /home/vmail eingebunden wird.
Ausblick: Dieser Ordner soll später mal mit Resilio Sync auf einen anderen Host synchronisiert werden, der seinerseits einen Papierkorb hat und automatisch Snapshots anlegt = Backup und Schutz vor Ransomware.
Das kann man in der /etc/fstab in der VM schon mal vorbereiten, bei mir:
#nas-ds224:/volume1/VM-Mail/VM-Mail_home_vmail.sync /home/vmail nfs rw,defaults,rsize=8192,wsize=8192,nfsvers=3 0 0
Das wird aber erst scharf geschaltet, wenn das Mail-Setup soweit funktioniert.
Zum Testen:
mount -o rw,vers=3 nas-ds224:/volume1/VM-Mail/VM-Mail_home_vmail.sync /home/vmail

2. fetchmail
Ich habe ja bereits eine funktionierende Konfiguration.
Deshalb war das mit einem apt install fetchmail und Kopieren der existierenden /etc/fetchmailrc schnell erledigt.
Vorerst habe ich in der /etc/default/fetchmail START_DAEMON=no eingetragen.
Das wird erst ganz am Ende scharf geschaltet, wenn alles funktioniert und die Mails auch umgezogen sind.
BTW: Die Mails werden mit fetchmail von verschiedenen Relayhost abgeholt und mit postfix über diese versendet.

3. Postfix
https://www.admin-magazin.de/Das-Heft/2012/02/Eigener-Mailserver-mit-Postfix-und-Dovecot
Die Abweichung zum existierenden Server ist die Umstellung auf virtuelle Benutzer.
Damit gehören alle Mails dem User vmail und die wirklichen Benuzer müssen keine Kennung samt Kennwort auf dem Linux-System haben.
Damit man auf beiden Systemen identische uid und gid hat, erst auf dem NAS vmail anlegen und ermitteln:
grep vmail /etc/passwd für die uid, bei mir 1030
grep vmail /etc/groups für die gid, bei mir 65537
Danach mit den ermittelten uid und gid Benutzer und Gruppe vmail in der VM anlegen.
VM herunterfahren und nächsten Snapshot machen.

 

[thc]

Thema: IMAP

https://doc.dovecot.org/configuration_manual/virtual_users/
https://doc.dovecot.org/configuration_manual/howto/simple_virtual_install/
Damit bekommt man dovecot schon mal grundsätzlich an den Start

1. Indizes
https://forum-raspberrypi.de/forum/...k-auslagern-weitere-optimierungen-bezgl-logs/
https://github.com/clathi06/var2tmpfs
Die Indices sind nicht wirklich gut direkt bei den Mails aufgehoben, deshalb habe ich in der /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:/home/vmail/%n:INDEX=/var/vmail/%n/indexes
Die Idee dazu ist, /var/vmail irgendwo hin zu packen, wo es flott zu geht - am Besten also ins RAM.
Dazu gibt es für den RaspberryPi das Skript varlog, das genau so etwas veranstaltet, um die MicroSD zu schonen.
Aber zuerst mal mit NFS direkt aufs NAS:
mkdir /var/vmail.save
chown vmail:vmail /var/vmail.save
systemctl stop dovecot.service
cd /var/vmail.save
cp -av /var/vmail/* .
mount -o rw,vers=3 nas-ds224:/volume1/VM-Mail/VM-Mail_var_vmail /var/vmail (das Verzeichnis muss es natürlich geben)
cd /var/vmail
cp -av /var/vmail.save/* .
systemctl start dovecot.service
Damit sind die Indizes schon mal an einer Stelle, wo sie sich beliebig ummounten lassen.
Das Umziehen auf tmpfs erledigt dann das angepasste Skript aus meinem GitHub.
Wenn das funktioniert, können die mounts natürlich auch direkt in die /etc/fstab eingetragen und scharf geschaltet werden.

2. Benutzer
Ich habe dazu eine /etc/dovecot/passwd, in der die Benutzer mit ihren Kennworten eingetragen sind.
Am Anfang wie gelesen brav verschlüsselt mit doveadm pw -u <user> -p <passwd>
Dann habe ich mich aber gefragt, was die verschlüsselte Ablage eigentlich an Sicherheit bringt.
Die fetchmailrc wird schon immer nur durch die Zugriffsrechte gesichert und das scheint bisher ja auch zu genügen.
Wer root-Zugriff auf den Server hat, kommt sowieso an alles dran.
Und wer das LAN belauschen kann auch - dazu im nächsten Punkt mehr.
Im Ergebnis reicht mir persönlich deshalb erstmal ein chown dovecot:root und chmod 600 als Schutz aus.

3. Verschlüsselung
https://dokuwiki.tachtler.net/doku.php?id=tachtler:dovecot_ssl_tls
Nun ist es hier so, dass Thunderbird als Mail-Client genutzt wird.
Und die Mozilla Foundation hält wohl sehr viel von verschlüsselter Kommunikation, aber sehr wenig von eigenen Zertifikaten.
Beim Firefox kann man diese wenigstens noch nach einer Warnung abnicken - wäre sonst wohl auch schlecht beim Zugriff auf die ganzen Fritz!Boxen dieser Welt mit eigenem Zertifikat.
Beim Tunderbird geht das aber nicht - zumindest habe ich nichts dazu gefunden, wie man diese Abfrage wieder einschalten könnte.
Thunderbird verweigert schlicht die Kommunikation mit dovecot bei aktiviertem SSL/TLS/STARTTLS und einem selbst generierten Zertifikat.
Dazu wiederum gibt es jede Menge Treffer bei einer Suche, aber als Lösungen nur: auf Verschlüsselung verzichten oder ein Zertifikat kaufen oder letsencrypt verwenden.
Letzteres stelle ich mir allerdings bei einem Server schwierig vor, dessen FQDN auf .internal endet, weil er eben gar nicht im Internet auftauchen soll.
Also erstmal keine Verschlüsselung und imap auf Port 143 wie bisher...

4. Mails migrieren
https://imapsync.lamiral.info/
https://github.com/imapsync/imapsync/blob/master/README
Das habe ich schon mehrfach mit imapsync gemacht, so auch hier.

 

[thc]

Thema: Nacharbeiten

Der Vorteil eines Systems ohne virtuelle Benutzer ist ja, dass die /etc/passwd ausreicht.
Mit virtuellen Benutzern waren bei mir am Anfang noch mindestens zwei Dateien erforderlich:
Für Postfix die virtual_alias_maps, um die von fetchmail angelieferten internen Benutzernamen (is "user" here) in welche mit @domain.internal umzusetzen.
Ohne mag Postfix nicht - zumindest habe ich keinen Weg gefunden, ohne die Domäne auszukommen oder diese wenigstens mit regex einfach an alle reinen Benutzernamen anzuhängen.
Und die /etc/dovecot/passwd, um diese Benutzer sowohl für Postfix als auch für die IMAP-Clients zu authorisieren.
Ich habe deshalb die Benutzernamen für fetchmail und Thunderbird um die Domäne angereichert - damit fällt die virtual_alias_maps für Postfix weg.

Wenn alles sauber läuft, kann das Logging wieder auf syslog umgestellt und danach die /var/log/mail.log geleert werden:
cat "" > /var/log/mail.log

Die zweite Baustelle ist dann irgendwann mal die verschlüsselte Kommunikation
Dazu werde ich mal versuchen, eine eigene CA aufzusetzen, diese dem Thunderbird als vertrauenswürdig bekannt zu machen und damit dann das Zertifikat zu signieren:
https://medium.com/@martin.hodges/introduction-to-creating-a-ca-on-debian-11-094bde1c676a

Gruß
Claus