Kürzlich habe ich einen gebrauchten und betagten Acer Aspire E774 Laptop als Spende für den Computertruhe e.V. fertiggemacht. Selbstverständlich gehört dazu auch das überschreiben der Festplatten mit zufälligen Daten, sodass sich keine alten Daten mehr rekonstruieren lassen. Denn “gelöscht” ist nicht gleich “sicher gelöscht”. Zum sicheren Löschen habe ich das Tool shred in einer Fedora Live Umgebung genutzt. Mit beliebigen anderen Linux-Distributionen funktioniert das aber genauso gut.
Da ein Ubuntu auf dem Laptop nicht auf Anhieb lauffähig bzw. zumutbar war, weil das Touchpad nicht funktionierte und es beim Boot immer wieder merkwürdige Probleme gab, habe ich mich dazu entschlossen, nach meiner Löschaktion einfach wieder ein Windows 10 zu installieren. Ganz so, wie es zuletzt auf dem Laptop einwandfrei lief.
Ziel dieser für Debian 9 “Stretch” aktualisierten Anleitung ist ein fertig installierter und konfigurierter Mailserver auf einem eigens dafür bereitgestellten Host. Der Beitrag basiert im wesentlichen auf dem zuvor für Ubuntu 16.04 vorgestellten Setup. In dieser aktualisierten Version wird statt eines Amavis-Spamassassin-Razor Stacks und OpenDKIM allerdings Rspamd genutzt, um die Komplexität und Fehleranfälligkeit des Setups zu reduzieren und gleichzeitig von der hervorragenden Funktion des Rspam Daemons zu profitieren. Außerdem wurden in diese Anleitung einige kleine Verbesserungen eingebracht, die mir von Lesern in den letzten Monaten vorgeschlagen wurden.
Wie auch in den letzten Versionen ist mir wichtig, die Funktionsweise und das Zusammenspiel der Mailserver-Komponenten so zu erklären, dass das Mailsystem als solches in den Grundzügen verstanden werden kann. Ich setze dabei grundlegende Kenntnisse im Bereich Linux-Server voraus; trotzdem ist dieser Guide auch für Anfänger geeignet, die Interesse und Zeit mitbringen.
VirtualBox nutze ich wegen der relativ guten Grafikperformance gerne für meine Windows-VM unter Fedora 24. Bei ersten Start schlug mir eine Fehlermeldung entgegen: Das notwendige “vboxdrv”-Kernelmodul sei noch nicht geladen, daher könne die VM nicht gestartet werden. Gut - das lässt sich ja lösen:
sudo modprobe vbxdrv
… doch damit war es nicht getan: Das Modul ließ sich nicht in den Kernel einbinden, weil es für das aktive SecureBoot nicht mit einem passenden MOK (Machine Owner Key) signiert worden war. Andere geladene Kernelmodule sind bereits von Fedora signiert - bei den VirtualBox Modulen war das nicht der Fall. Warum das so ist, konnte ich noch nicht herausfinden. (=>siehe Notiz unten)