thomas-leister.de

Mailserver mit Dovecot, Postfix, MySQL und Rspamd unter Debian Trixie

thomas.leister@mailbox.org (Thomas Leister) — Sat, 07 Feb 2026 22:43:33 +0100

Es geht weiter in der Serie meiner Mailserver-Tutorials. Nachdem meine letzte Anleitung zu Debian Bullseye schon einige Jahre alt ist, ist es an der Zeit, sich dem Thema nochmal zu widmen - in Hinblick auf das nun aktuelle Debian Trixie.

Für alle, die schon den Mailserveranleitungen aus den letzten Jahren gefolgt sind: Euer Mailserver lässt sich mit wenig Aufwand gut auf den Stand aus dieser Anleitung aktualisieren. Das Datenbank-Layout hat sich (mit Ausnahme der entfernten tlspolicies Tabelle) nicht geändert und auch sonst sind alle Datenstrukturen aus den Verzeichnissen gleich geblieben - einzig der Funktionsumfang hat sich leicht geändert und die Konfigurationen wurden auf den aktuellen Stand der Technik angepasst. Außerdem wurde die Anleitung umformuliert und an einigen Stellen aus Gründen der Übersichtlichkeit gekürzt. Alle Änderungen seit der letzten Version meiner Anleitung könnt ihr im Changelog am Ende des Beitrags einsehen.

Was und für wen?

Mithilfe dieser Anleitung werdet ihr in der Lage sein, einen einfachen Open Source basierten Mailserver unter Debian Trixie aufzusetzen. Der Server wird euch ermöglichen, eure E-Mails unter einer eigenen Domain selbst zu hosten. Was der Featureset angeht, bekommt ihr eine solide Grundausstattung, die sich bei Bedarf problemlos um weitere Features erweitern lässt.

Was ihr bekommt:

Senden und Empfang von E-Mails über einen E-Mail Client (z.B. Thunderbird, Evolution, Outlook, … K9 Mail, etc)
Moderne Spamabwehr inkl. Spam Learning
DKIM-Signierung ausgehender E-Mails für bessere Akzeptanz bei fremden Mailsystemen und Fälschungssicherheit
Filterregeln / Autoresponder bei Urlaub / …
E-Mail Weiterleitungen (Aliase)
Verwaltung aller Mailaccounts und Weiterleitungen / Aliase über eine MySQL-Datenbank.
Sichere Verschlüsselung der Kommunikation zwischen E-Mail Servern, falls verfügbar
Größenbeschränkung von Postfächern
“Send-only” Account, die nur zum Senden, aber nicht zum Empfangen vorgesehen sind (z.B. für Nextcloud, Forensoftware, …)

Was ihr mit dieser Anleitung nicht bekommt:

Eine vollständige E-Mail Suite mit Webmail, Office, Kalender, Kontakte …
Einen Server zum massenhaften Senden von E-Mails (Newsletter etc.)

Zielgruppe dieser Anleitung sind professionelle Linux-Systemadministratoren und Hobbyisten, die verstehen wollen, wie ihr Mailsetup funktioniert und einen sicheren E-Mail Server ohne Schnickschnack aufsetzen wollen.

Für all diejenigen, die eigentlich lieber “nur kurz etwas installieren” würden und sich eher ein Rundumpaket wünschen, das die Komplexität eines E-Mail Servers versteckt, ist möglicherweise ein Docker-basierter Mailcow-Server besser geeignet.

Voraussetzungen für den Betrieb eines E-Mail Servers

Je nach Anzahl der Nutzer ein passender vServer oder physischer Server. Für eine zweistellige Nutzeranzahl reicht ein Quadcore-Server mit 4 GB RAM bereits völlig aus. Für eine kleine bis mittlere zweistellige Nutzerzahl reicht auch ein Raspberry Pi schon aus. Passende Hoster sind z.B. Hetzner, OVH, Scaleway.
Eine vernünftige Internetanbindung mit statischer IP-Adresse und der Möglichkeit, einen Reverse-DNS (PTR) Record für diese Adresse zu setzen (idR. trifft das auf Privatkundenanschlüsse bei denen gängigen ISPs nicht zu!)
Eine Domain, für die beliebige DNS-Records gesetzt werden können
Vorinstalliertes Debian 13 “Trixie”. Die “minimal” bzw. Server-Version reicht aus - eine grafische Oberfläche wird nicht genutzt. Am besten eine frische Installation ohne Vorbelastung.

Annahmen und Bezeichnungen

Um der Anleitung besser folgen zu können, treffe ich einige Annahmen zum Setup.

Primäre Domain, die für den Mailserver genutzt wird: mysystems.tld
(Optionale) weitere Domains, für die ebenfalls Postfächer betrieben werden sollen: domain2.tld, domain3.tld
Hostname des Mailservers: mail.mysystems.tld (ich empfehle, mail als Subdomain zu nutzen!)
Öffentliche IPv4-Adresse: 203.0.113.1
Öffentliche IPv6-Adresse: 2001:db8::1

All diese Domains und IP-Adressen sind selbstverständlich auf die eigenen Gegebenheiten anzupassen. Achtet also im Laufe der Anleitung darauf, diese immer durch eure eigenen Domains oder Adresse zu ersetzen!

Mailserverkomponenten und ihre Aufgaben

Dovecot

Dovecot ist ein weit verbreiteter MDA (Mail Delivery Agent) und IMAP-Server. Er sortiert ankommende E-Mails in die Postfächer des jeweiligen Empfängers ein und stellt eine Schnittstelle zum Abrufen der Mailbox bereit (IMAP). Außerdem wird Dovecot in diesem Setup von Postfix als sog. SASL-Authentifizierungsserver genutzt: Postfix fragt Dovecot, ob ein bestimmter Benutzer berechtigt ist, sich am System anzumelden.

Postfix

Postfix wird oft zusammen mit Dovecot eingesetzt. Der populäre MTA (Mail Transfer Agent) kümmert sich um alles, was mit dem Transport der E-Mail zu tun hat: Vom E-Mail Client zum eigenen Mailserver, und von dort aus zum jeweiligen Zielserver. Außerdem nimmt Postfix E-Mails von fremden Servern an und leitet sie an den MDA Dovecot weiter. Antispam-Software wird i.d.R. direkt in Postfix integriert, um eintreffende Spammails erst gar nicht in die Mailbox des Nutzers gelangen zu lassen.

MariaDB (MySQL-Datenbank)

Dovecot und Postfix werden so konfiguriert, dass sie eine MySQL-Datenbank als Backend (Datenbasis) nutzen. In der Datenbank werden zu nutzende Domains, Benutzer, Aliase und weitere Daten gespeichert. Durch einfaches Hinzufügen oder Entfernen von Datensätzen in oder aus Datenbanktabellen können neue Benutzer oder Aliase angelegt oder gelöscht werden. Der Vorteil eines Datenbank-Backends ist, dass sich der Mailserver damit sehr einfach verwalten lässt: So ließe sich zur Benutzerverwaltung beispielsweise eine Weboberfläche in PHP entwickeln, die die MySQL-Datenbank verändert. Die Serverkonfiguration muss dann nicht manuell geändert werden.

Rspamd

Rspamd ist ein Filtersystem, das in Postfix integriert wird und eingehende E-Mails überprüft. Spammails werden von Rspamd erkannt und nicht an den Benutzer zugestellt bzw. aussortiert. Außerdem fügt Rspamd bei ausgehenden E-Mails eine DKIM-Signatur hinzu, sodass fremde Mailserver eigene Mails nicht als verdächtig einstufen.

Nginx

Nginx ist ein weit verbreiteter und schlanker Webserver / Webproxy. In diesem Setup hat er mehrere Aufgaben: Zum einen kann er als Endpunkt für den Ausstellungsprozess von Let’s Encrypt-Zertifikaten dienen, zum anderen als Proxy für die Rspamd-Weboberfläche.

Redis

Redis ist ein hochperformanter In-memory Key-Value-Store, also eine sehr einfache, schnelle Datenbank, welche Schlüssel-Wert-Paare effizient im Speicher ablegen kann. Rspamd nutzt Redis, um einige Daten zwischenzuspeichern (wie z.B. Statistiken, “gelernte” Spammails, …).

Vorbereitungen

Bevor es mit dem Setup der einzelnen Mailserverkomponenten losgeht, muss das System noch ein Stück weit vorkonfiguriert werden. Wie oben bereits erwähnt, empfiehlt sich die Installation auf einem frischen Debian Trixie System, d.h. ohne Vorbelastungen, ohne einen parallel Betriebenen Webserver oder ähnliches. So kann am besten sichergestellt werden, dass die Schritte aus dieser Anleitung zum Ziel führen.

Loggt euch über SSH auf eurem Debian System ein. Falls ihr euch nicht eh schon direkt als User root einloggt, sorgt dafür, dass ihr eine Root-Shell bekommt:

sudo su

Aktualisierung des Systems

Das System soll nicht direkt nach Fertigstellung schon veraltet und Sicherheitslücken ausgeliefert sein, richtig? Aktualisiert euer Debian auf den aktuellen Stand:

apt update && apt upgrade

Hostnamen und Server-FQDN setzen

Damit der Mailserver Mails der eigenen Nutzer vernünftig erkennen kann, muss das Betriebssystem wissen, wie es heißen soll. Dazu wird der Hostname mail.mysystems.tld gesetzt:

hostnamectl hostname --static mail

In der Hosts-Datei /etc/hosts sollten FQDN und lokaler Hostname hinterlegt sein. Die Datei kann beispielsweise so aussehen:

127.0.0.1 localhost
127.0.1.1 mail.mysystems.tld mail
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Die Ausgaben der Kommandos hostname und hostname --fqdn sollten nach den Änderungen wie folgt aussehen:

root@mail:~# hostname
mail
root@mail:~# hostname --fqdn
mail.mysystems.tld

Der FQDN (in diesem Beispiel “mail.mysystems.tld”) wird außerdem nach /etc/mailname geschrieben:

echo $(hostname -f) > /etc/mailname

(Der Hostname im Shell-Prompt z.B. root@meinhost: passt sich erst nach einem erneuten Login an.)

Unbound DNS Resolver installieren

Das Mailsystem benötigt einen funktionierenden DNS-Server (Resolver), sodass die Herkunft von E-Mails überprüft werden kann. Auch der Rspamd-Spamfilter verlässt sich bei der Bewertung von Spammails auf DNS-Dienste. Eine schnelle Namensauflösung bringt also Performancevorteile für das ganze Mailsystem. Für den Zugriff auf Spamhaus-Blocklists kann es sogar notwendig sein, seinen eigenen DNS-Resolver zu nutzen, weil z.B. Zugriffe über das Google DNS blockiert werden. Deshalb (und um die Sicherheit im Bezug auf Abhängigkeiten zu fremden Systemen zu verbessern) empfehle ich die Nutzung eines eigenen, lokalen DNS-Resolvers.

Unbound installieren:

apt install unbound

Für die nächsten Kommandos muss müssen die Pakete dnsutils und resolvconf installiert sein. Wenn bei der Installation von Debian die “Standard-Systemwerkzeuge” ausgewählt wurden, sind die dnsutils schon installiert.

Ein dig @::1 denic.de +short +dnssec sollte eine ähnliche Ausgabe wie folgt erzeugen:

# dig @::1 denic.de +short +dnssec
A 8 2 3600 20170814090000 20170731090000 26155 denic.de. Jo90qnkLkZ6gI4qNHj19BMguFuGof9hCPhdeSh/fSePSQ/WXlWMmfjW1 sNDJ/bcITRMyz8DQdDzmWPDIeSJ/qPyfoZ+BjUZxtaXcs0BAl4KX8q7h R05TGmAbgPhrYBoUKJkU/q8T+jWKHAJRUeWbCd8QOJsJbneGcUKxRAPe i6Rq51/OL/id6zUCtalhclah2TfLLaqku9PmKwjbGdZm11BXSr8b56LB WX/rdLIrKWNpE+jHGAUMmDsZL84Kx3Oo

Wenn der dig-Befehl funktioniert hat, kann der lokale Resolver als primärer Resolver gesetzt werden:

apt install resolvconf
echo "nameserver ::1" >> /etc/resolvconf/resolv.conf.d/head

ein nslookup denic.de | grep Server sollte nun

Server: ::1

zurückliefern. Damit ist der lokale DNS-Resolver als Haupt-Resolver einsatzbereit.

Einrichtung des DNS

Zu Beginn dieser Anleitung wurde für den Mailserver der FQDN “mail.mysystems.tld” festgelegt. Für diesen Domain-Namen werden nun A-Records im DNS-Zonefile der Domain “mysystems.tld” erstellt. Loggt euch bei eurem Domain-Provider ein und legt die folgenden Einträge an – der erste für die IPv4-IP-Adresse des Mailservers, die zweite für die IPv6-Adresse. (Beispiel!):

Achtet im Folgenden vor allem auf den abschließenden Punkt in den Domainnamen!

mail.mysystems.tld. 86400 IN A 203.0.113.1
mail.mysystems.tld. 86400 IN AAAA 2001:db8::1

“mail.mysystems.tld” ist damit im DNS bekannt. Wenn keine IPv6-Adresse genutzt wird, kann der zweite Record entfallen. Bleiben noch “imap.mysystems.tld” und “smtp.mysystems.tld”, die als Alias-Domains für “mail.mysystems.tld” angelegt werden. Sie sind nicht unbedingt notwendig, werden von vielen Mailclients bei der Einrichtung eines neuen Accounts aber gesucht und erleichtern ggf. die Autokonfiguration:

imap.mysystems.tld. 86400 IN CNAME mail.mysystems.tld.
smtp.mysystems.tld. 86400 IN CNAME mail.mysystems.tld.

Mailclients können sich damit schon über imap.mysystems.tld und smtp.mysystems.tld zum Mailserver verbinden. Andere Mailserver suchen bei der E-Mail-Übermittlung allerdings nicht nach A- oder CNAME-Records, sondern nach MX-Records. Ein MX-Record zeigt, welcher Mailserver für die E-Mails zu einer Domain zuständig ist. In meinem Beispiel soll sich unser Mailserver neben den E-Mails für mysystems.tld auch um die Mails für domain2.tld und domain3.tld kümmern.

Im Zonefile der Domain “mysystems.tld” wird dazu dieser Record angelegt:

mysystems.tld. 86400 IN MX 0 mail.mysystems.tld.

In die Zonefiles der anderen Domains werden entsprechend die Records

domain2.tld. 86400 IN MX 0 mail.mysystems.tld.

und

domain3.tld. 86400 IN MX 0 mail.mysystems.tld.

angelegt. Wichtig ist hier wieder der abschließende Punkt nach den Hostnamen!

Reverse DNS

Ein DNS-Eintrag löst einen Hostnamen zu einer IP-Adresse auf. Nun geht es um den umgekehrten Weg: Das Auflösen einer IP-Adresse zu einem Hostnamen. Das ist wichtig, weil andere Mailserver idR. ermitteln, ob unser Mailserver tatsächlich der ist, der er vorgibt zu sein. Dazu wird die IP-Adresse unseres Servers zu einem Hostnamen aufgelöst und dann mit dem Hostnamen verglichen, den unser Server bei der Kontaktaufnahme präsentiert wird.

Der Reverse DNS-Eintrag ist also unverzichtbar und sollte für alle IP-Adressen, mit denen unser System nach außen kommuniziert, gesetzt sein. Vergesst also nicht, auch für eure ggf. vorhandene IPv6-Adresse einen passenden Eintrag anzulegen.

Üblicherweise könnt ihr das Reverse DNS über die Verwaltungsoberfläche eures Serveranbieters pflegen oder über den Support bei eurem Netzbetreiber. Ist hier nicht der korrekte Hostname mail.mysystems.tld für alle öffentlich genutzten IP-Adressen eingetragen, schlägt der Versand zu den meisten anderen Mailsystemen fehl! Hier ist also besondere Vorsicht geboten.

SPF-Records

Im Kampf gegen Spam und Phishing wurde das sog. Sender Policy Framework entwickelt (Siehe auch Beitrag: “Voraussetzungen für den Versand zu großen E-Mail Providern”). Obwohl es sich nur als eingeschränkt brauchbar erwiesen hat, erwarten die meisten Mailprovider gültige SPF-Records für andere Mailserver und prüfen diese. SPF-Einträge werden im Zonefile aller Domains erstellt, für die ein Mailserver E-Mails verschickt, und geben an, welche Server für eine Domain sendeberechtigt sind. Für unsere Domain mysystems.tld wird der folgende Record im Zonefile von mysystems.tld angelegt:

mysystems.tld. 3600 IN TXT v=spf1 a:mail.mysystems.tld mx ?all

Hiermit erhält nur der im A-Record “mail.msystems.tld” genannte Server für mysystems.tld eine Sendeberechtigung. Die Neutral-Einstellung “?all” sorgt dafür, dass E-Mails von anderen Servern trotzdem angenommen werden sollen. Damit gehen wir Problemen beim Mail-Forwarding aus dem Weg. Wir erstellen den SPF-Record also eigentlich nur, damit andere Mailserver unseren Server wegen des existierenden Records positiv bewerten – nicht, weil er seinen Nutzen entfalten soll.

Falls vorhanden, wird in den Zonefiles der beiden Domains “domain2.tld” und “domain3.tld” jeweils dieser Record angelegt:

domain2.tld. 3600 IN TXT v=spf1 include:mysystems.tld ?all

Über das “include” wird der Original DNS Record der Domain mysystems.tld eingebunden.

DMARC Records

DMARC-Einträge bestimmen, was ein fremder Mailserver tun soll, wenn eine von ihm empfangene Mail nach SPF- und DKIM-Checks offenbar nicht vom korrekten Mailserver stammt (wenn der Absender also gefälscht wurde). Es ist vernünftig, andere Mailserver anzuweisen, solche E-Mails nicht zu akzeptieren:

_dmarc.mysystems.tld. 3600 IN TXT v=DMARC1; p=reject;

Der Record wird entsprechend auch für die anderen Domains gesetzt:

_dmarc.domain2.tld. 3600 IN TXT v=DMARC1; p=reject;

Einen DMARC-Record mit einer abweichenden Policy könnt ihr euch unter https://elasticemail.com/dmarc/ selbst generieren lassen.

Erstkonfiguration Nginx Webserver

Wie bereits angemerkt, übernimmt Nginx in diesem Setup verschiedene Aufgaben. Für’s erste dient er aber nur als HTTP-Endpunkt, um Let’s Encrypt Zertifikate zu beantragen. Das ist zwar prinzipiell auch ohne Nginx im standalone-Modus möglich, macht uns aber das Leben einfacher, wenn wir ihn sowieso in Betrieb haben (=> belegte Ports durch Nginx, ACME client …).

Dazu wird Nginx installiert …

apt install nginx

… und unter /etc/nginx/sites-available/mail.mysystems.tld eine neue Konfiguration mit diesem Inhalt angelegt:

server {
listen 80;
listen [::]:80;
# listen 443 ssl;
# listen [::]:443 ssl;
server_name mail.mysystems.tld imap.mysystems.tld smtp.mysystems.tld;
# http2 on;
# ssl_certificate /etc/acme.sh/mail.mysystems.tld/fullchain.pem;
# ssl_certificate_key /etc/acme.sh/mail.mysystems.tld/privkey.pem;
# add_header Strict-Transport-Security max-age=15768000;
# if ($ssl_protocol = "") {
# return 301 https://$server_name$request_uri;
# }
}

Einige Zeilen sind zu diesem Zeitpunkt bewusst auskommentiert und werden später wieder aktiviert, sobald TLS-Zertifikate verfügbar sind.

Der neue vHost kann nun aktiviert werden:

ln -s /etc/nginx/sites-available/mail.mysystems.tld /etc/nginx/sites-enabled/mail.mysystems.tld
systemctl reload nginx

Beantragung der TLS-Zertifikate (via Let’s Encrypt)

Gültige TLS-Zertifikate von anerkannten Zertifizierungsstellen (CAs) sind heute für jeden Mailserver ein “muss”. Immer mehr Mailsysteme verweigern zurecht den Empfang über ungesicherte Verbindungen. Was früher (vor allem für den privaten Einsatz) noch ein bedeutender Kostenfaktor war, bekommt man heute Dank Let’s Encrypt kostenlos und sehr unkompliziert. Im folgenden beziehe ich mich daher auf die Generierung von Let’s Encrypt-Zertifikaten. Selbstverständlich können stattdessen auch Zertifikate anderer CAs genutzt werden.

Für Postfix und Dovecot benötigen wir Zertifikate zu folgenden Domains:

mail.mysystems.tld
imap.mysystems.tld
smtp.mysystems.tld

Um die Zertifikate von der Let’s Encrypt Zertifizierungsstelle abholen, nutze ich das schlanke acme.sh Script. Dieses verfügt über einen “Nginx-Mode”, in dem das Script den Nginx Webserver automatisch so konfiguriert, dass die Domains von LE verifiziert werden können.

acme.sh installieren:

curl https://get.acme.sh | sh

Der Hinweis, welcher besagt, dass socat installiert werden solle, kann ignoriert werden. Socat wird in unserem Fall nicht benötigt.

Nach der Installation muss das Shell-Profil neu geladen werden, damit das “acme.sh” Kommando verfügbar gemacht wird:

source ~/.profile

Zertifikate beantragen und herunterladen:

acme.sh --issue --server letsencrypt --nginx \
-d mail.mysystems.tld \
-d imap.mysystems.tld \
-d smtp.mysystems.tld

Zertifikate installieren:

mkdir -p /etc/acme.sh/mail.mysystems.tld
acme.sh --install-cert -d mail.mysystems.tld \
--key-file /etc/acme.sh/mail.mysystems.tld/privkey.pem \
--fullchain-file /etc/acme.sh/mail.mysystems.tld/fullchain.pem \
--reloadcmd "systemctl reload nginx; systemctl reload dovecot; systemctl reload postfix;"

Infolge unseres Reload-Commands wird acme.sh versuchen, Dovecot und Postfix neu zu laden. Da beide Softwarepakete noch nicht installiert sind, werden euch Fehler angezeigt. Ihr könnt diese zum gegenwärtigen Zeitpunkt aber ignorieren.

Die vorher im Nginx auskommentierten Zeilen in /etc/nginx/sites-available/mail.mysystems.tld können durch Entfernen der Hashzeichen nun aktiviert und Nginx mittels

nginx -t
systemctl reload nginx

getestet und neu gestartet werden.

Damit die automatische Zertifikatserneuerung funktioniert, wird noch der Cronjob für acme.sh aktiviert:

acme.sh --install-cronjob

MySQL Datenbank einrichten

Informationen über zu verwaltende Domains, Benutzer, Weiterleitungen und sonstige Einstellungen soll der Mailserver aus einer MySQL-Datenbank ziehen. Das hat den Vorteil, dass der Server im laufenden Betrieb flexibel angepasst werden kann, ohne die Konfigurationsdateien ändern zu müssen. Die Datenbank ermöglicht uns außerdem ein virtualisiertes Mailserver-Setup: Die Benutzer auf den Mailservern müssen nicht mehr als reale Linux-Benutzer im System registriert sein, sondern nur noch in der Datenbank eingetragen werden.

Als DBMS wird die neue Debian Standard-MySQL-Datenbank “MariaDB” installiert:

apt install mariadb-server

Nach der Installation sollte MariaDB bereits gestartet sein. Den Status könnt ihr mittels systemctl status mariadb überprüfen. Falls das nicht der Fall ist, startet den Datenbankserver: systemctl start mariadb.

Standardmäßig kann sich nur der root-Systemuser am Datenbankserver anmelden. Authentifiziert wird er dabei automatisch via PAM, sodass keine zusätzliche Passworteingabe notwendig ist. Die einfache Eingabe von

mysql

bringt euch in eine MySQL Root Shell. Über diese werden nun ein paar SQL-Befehle ausgeführt.

Ein SQL-Kommando endet immer mit einem Semikolon ;. Mehrzeilige Befehle könnt ihr ohne weiteres einfach mit ENTER umbrechen, so wie sie im Folgenden dargestellt werden. Achtet auf den Unterschied zwischen “Tick” (') und “Backtick” (`) – der Backtick wird mit Shift + 2x Accent-Taste erzeugt. Kopiert die SQL-Statements am besten direkt in eure Zwischenanlage, statt sie mühsam abzutippen.

Im ersten Schritt wird eine neue Datenbank “vmail” angelegt.

CREATE DATABASE vmail
CHARACTER SET 'utf8'
COLLATE utf8_unicode_ci;

Ein neuer DB-User vmail mit dem Passwort vmaildbpass bekommt Zugriff auf diese neue Datenbank (Wählt ein eigenes Passwort statt “vmaildbpass”!):

Nutzt für vmaildbpass nur die Zeichen 0-9 a-z und A-z. Einigen Berichten nach können Sonderzeichen zu Problemen führen.

GRANT SELECT ON vmail.* TO 'vmail'@'localhost' IDENTIFIED BY 'vmaildbpass';

Alle weiteren Kommandos zu Erstellung der Datenbank-Tabellen sollen sich auf die eben erzeugte Datenbank beziehen:

use vmail;

Das Mail-Setup soll 3 verschiedene Tabellen nutzen. Kopiert die SQL-Statements einzeln und nacheinander in die MySQL-Kommandozeile und bestätigt jedes mal mit [Enter]. Anpassungen sind nicht notwendig.

Domain-Tabelle

Die Domain-Tabelle enthält alle Domains, die mit dem Mailserver genutzt werden sollen.

CREATE TABLE `domains` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`domain` varchar(255) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY (`domain`)
);

Account-Tabelle

CREATE TABLE `accounts` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`username` varchar(64) NOT NULL,
`domain` varchar(255) NOT NULL,
`password` varchar(255) NOT NULL,
`quota` int unsigned DEFAULT '0',
`enabled` boolean DEFAULT '0',
`sendonly` boolean DEFAULT '0',
PRIMARY KEY (id),
UNIQUE KEY (`username`, `domain`),
FOREIGN KEY (`domain`) REFERENCES `domains` (`domain`)
);

Die Account-Tabelle enthält alle Mailserver-Accounts. Das Feld “quota” enthält die Volumenbegrenzung für die Mailbox in MB (Megabyte). Im Feld “enabled” wird über einen bool’schen Wert festgelegt, ob ein Account aktiv ist, oder nicht. So können einzelne User temporär deaktiviert werden, ohne gelöscht werden zu müssen. “sendonly” wird auf “true” gesetzt, wenn der Account nur zum Senden von E-Mails genutzt werden soll – nicht aber zum Empfang. Das kann beispielsweise für Foren- oder Blogsoftware sinnvoll sein, die mit ihrem Account nur E-Mails verschicken soll.

Alias-Tabelle

CREATE TABLE `aliases` (
`id` int unsigned NOT NULL AUTO_INCREMENT,
`source_username` varchar(64),
`source_domain` varchar(255) NOT NULL,
`destination_username` varchar(64) NOT NULL,
`destination_domain` varchar(255) NOT NULL,
`enabled` boolean DEFAULT '0',
PRIMARY KEY (`id`),
UNIQUE KEY (`source_username`, `source_domain`, `destination_username`, `destination_domain`),
FOREIGN KEY (`source_domain`) REFERENCES `domains` (`domain`)
);

Die Alias-Tabelle enthält alle Weiterleitungen / Aliase und ist eigentlich selbsterklärend. Zur temporären Deaktivierung von Weiterleitungsadressen gibt es wieder ein “enabled”-Feld.

Die Datenbank wird mit Datensätzen befüllt, sobald die Server fertig konfiguriert sind. Bis dahin könnt ihr die MySQL-Kommandozeile mit quit; verlassen.

vmail-Benutzer und -Verzeichnis einrichten

Alle Mailboxen werden direkt im Dateisystem des Debian Servers abgelegt. Für die Zugriffe auf die Mailbox-Verzeichnisse wird ein eigener Benutzer “vmail” (“Virtual Mail”) erstellt, unter dem die Zugriffe von Dovecot und anderen Komponenten des Mailservers geschehen sollen. Einerseits wird so verhindert, dass Mailserver-Komponenten auf sensible Systemverzeichnisse Zugriff bekommen, andererseits können wir so die Mailboxen vor dem Zugriff von außen schützen. Nur vmail (und root) dürfen auf die Mailboxen zugreifen.

Das Verzeichnis /var/vmail/ soll alle Mailserver-relevanten Dateien (also Mailboxen und Filterscripts) enthalten und wird für den vmail-User als Home Directory festgelegt.

vmail-Benutzer erstellen:

useradd --create-home --home-dir /var/vmail --user-group --shell /usr/sbin/nologin vmail

vmail Unterverzeichnisse erstellen:

mkdir /var/vmail/mailboxes
mkdir -p /var/vmail/sieve/global

Verzeichnis /var/vmail rekursiv an vmail-User übereignen und Verzeichnisrechte passend setzen:

chown -R vmail /var/vmail
chgrp -R vmail /var/vmail
chmod -R 770 /var/vmail

Dovecot installieren und konfigurieren

Nachdem die Datenbank und der vmail-User angelegt wurden, widmen wir uns nun dem Dovecot-Server. Wie bereits erwähnt, verwaltet dieser Server die Mailboxen und bekommt daher (in der Gestalt des vmail-Users) exklusiv Zugriff auf /var/vmail/. Zuerst müssen jedoch alle Serverkomponenten installiert werden:

apt install dovecot-core dovecot-imapd dovecot-lmtpd dovecot-mysql dovecot-sieve dovecot-managesieved

dovecot-core: Dovecot-Kern
dovecot-imapd: Fügt IMAP-Funktionalität hinzu
dovecot-lmtp: Fügt LMTP (Local Mail Transfer Protocol)-Funktionalität hinzu; LMTP wird als MTP-Protokoll zwischen Postfix und Dovecot genutzt
dovecot-mysql: Lässt Dovecot mit der MySQL-Datenbank zusammenarbeiten
dovecot-sieve: Fügt Filterfunktionalität hinzu
dovecot-managesieved: Stellt eine Schnittstelle zur Einrichtung der Filter via Mailclient bereit

Nach der Installation wird Dovecot automatisch gestartet. Beendet Dovecot, solange wir keine fertige Konfiguration haben:

systemctl stop dovecot

Nun geht es an die Konfiguration. Die Dovecot-Konfigurationsdateien liegen im Verzeichnis /etc/dovecot/. Dort könnt ihr schon einige Konfigurationen sehen, die bei der Installation angelegt wurden. Wir werden die Konfiguration von Grund auf neu aufsetzen - deshalb wird zuerst einmal die gesamte Dovecot-Konfiguration gelöscht:

rm -r /etc/dovecot/*
cd /etc/dovecot

Für Dovecot reicht die Konfigurationsdatei /etc/dovecot/dovecot.conf aus. Gebt ihr über einen Editor eurer Wahl folgenden Inhalt:

# Dovecot config and storage versions
dovecot_config_version = 2.4.0
dovecot_storage_version = 2.4.0
###
### Protocol settings
#############################
protocols {
lmtp = yes
imap = yes
sieve = yes
}
protocol imap {
mail_plugins {
imap_quota = yes
imap_sieve = yes
}
imap_idle_notify_interval = 29 mins
}
protocol lmtp {
mail_plugins {
sieve = yes
notify = yes
push_notification = yes
}
postmaster_address = postmaster@mydomain.tld
}
##
## TLS Config
## Quelle: https://ssl-config.mozilla.org/#server=dovecot&version=2.3.9&config=intermediate&openssl=1.1.1d&guideline=5.4
##
ssl = required
ssl_server_cert_file = /etc/acme.sh/mydomain.tld/fullchain.pem
ssl_server_key_file = /etc/acme.sh/mydomain.tld/privkey.pem
ssl_server_dh_file = /etc/dovecot/dh4096.pem
ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
###
### Dovecot services
################################
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
mode = 0600
group = postfix
user = postfix
}
}
service auth {
### Auth socket für Postfix
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
}
###
### SQL settings
###
sql_driver = mysql
mysql /var/run/mysqld/mysqld.sock {
user = vmail
password = mypassword
dbname = vmail
}
###
### Client authentication
#############################
auth_mechanisms = plain login
auth_username_format = %{user | lower }
passdb sql {
query = SELECT username AS user, domain, password FROM accounts WHERE username = '%{user | username | lower }' AND domain = '%{user | domain | lower}' and enabled = true;
default_password_scheme = ARGON2ID
}
userdb sql {
query = SELECT concat(quota, 'M') AS quota_storage_size FROM accounts WHERE username = '%{user | username | lower }' AND domain = '%{user | domain | lower}' AND sendonly = false;
iterate_query = SELECT username, domain FROM accounts where sendonly = false;
}
##
### Address tagging
###
recipient_delimiter = +
###
### Mail location
#######################
mail_uid = vmail
mail_gid = vmail
mail_privileged_group = vmail
mail_home = /var/vmail/mailboxes/%{user | domain }/%{user | username }
mail_driver = maildir
mail_path = ~/mail
mailbox_list_layout = fs
###
### Mailbox configuration
########################################
namespace inbox {
inbox = yes
mailbox Spam {
auto = subscribe
special_use = \Junk
}
mailbox Trash {
auto = subscribe
special_use = \Trash
quota_storage_extra = 10M
}
mailbox Drafts {
auto = subscribe
special_use = \Drafts
}
mailbox Sent {
auto = subscribe
special_use = \Sent
}
}
###
### Mail plugins
############################
mail_plugins {
quota = yes
}
sieve_plugins {
sieve_imapsieve = yes
sieve_extprograms = yes
}
sieve_script spam-global {
type = before
path = /var/vmail/sieve/global/spam-global.sieve
}
sieve_script personal {
type = personal
path = /var/vmail/sieve/%{user | domain }/%{user | username }/scripts
active_path = /var/vmail/sieve/%{user | domain }/%{user | username }/active-script.sieve
}
# From Mailbox to Spam
mailbox Spam {
sieve_script spam {
type = before
cause = copy
path = /var/vmail/sieve/global/learn-spam.sieve
}
}
# From Spam to another folder (learn HAM)
imapsieve_from Spam {
sieve_script ham {
type = before
cause = copy
path = /var/vmail/sieve/global/learn-ham.sieve
}
}
# Sieve extensions only allowed in global context
sieve_global_extensions {
vnd.dovecot.pipe = yes
}
sieve_pipe_bin_dir = /usr/bin
###
### IMAP Quota
###########################
quota "User quota" {
driver = count
}

Anzupassende Stellen:

postmaster_address: Domain anpassen
ssl_server_cert_file: Pfad zur Zertifikatsdatei
ssl_server_key_file: Pfad zur Zertifikatsdatei
password = mypassword in mysql Block

Nach dem Speichern ist es wichtig, nur dem root-User das Lesen der Datei zu erlauben, weil das MySQL-Passwort darin in Klartext abgelegt ist:

chmod 600 /etc/dovecot/dovecot.conf

Diffie-Hellman Parameter für Dovecot generieren

In neueren Versionen generiert Dovecot die Diffie-Hellman-Parameter für TLS-Verbindungen nicht mehr selbst. Also müssen wir selbst Hand anlegen und die Parameter mittels OpenSSL-Tool generieren lassen:

openssl dhparam -out /etc/dovecot/dh4096.pem 4096

Das kann je nach Auslastung des Mailservers durchaus eine viertel Stunde oder länger dauern. Um den Vorhang zu beschleunigen, kann ein sog. Entropy Harvester wie z.B. haveged installiert werden (apt install haveged).

Globales Sieve-Filterscript für Spam

Unter /var/vmail/sieve/global/ wird das Sieve-Filterscript spam-global.sieve erstellt, das erkannte Spammails in den Unterordner “Spam” jeder Mailbox einsortiert. Rspamd markiert erkannte E-Mails mit einem speziellen Spam-Header, den das Script erkennt. Inhalt von spam-global.sieve:

require "fileinto";
if header :contains "X-Spam-Flag" "YES" {
fileinto "Spam";
}
if header :is "X-Spam" "Yes" {
fileinto "Spam";
}

Spam Learning mit Rspamd

Beim Verschieben von Spammails in den Spam-Ordner bzw. dem Zurückschieben falsch einsortierter Mails in den Posteingang soll ein Lernprozess von Rspamd ausgelöst werden, sodass der Filter aus False Negatives und False Positives lernt und so mit der Zeit immer besser wird.

Dazu werden zwei Sieve-Scripts in /var/vmail/sieve/global/ angelegt:

learn-spam.sieve

require ["vnd.dovecot.pipe", "copy", "imapsieve"];
pipe :copy "rspamc" ["learn_spam"];

learn-ham.sieve

require ["vnd.dovecot.pipe", "copy", "imapsieve", "environment", "variables"];
if environment :matches "imap.mailbox" "*" {
set "mailbox" "${1}";
}
if string "${mailbox}" "Trash" {
stop;
}
pipe :copy "rspamc" ["learn_ham"];

Das learn-ham.sieve Script besitzt noch einen Check, der überprüft, ob eine E-Mail aus dem Spam in den Papierkorb verschoben wurde. In diesem Fall sollen die betroffenen Mails ja nicht wieder als “Ham” markiert werden, daher wird in so einem Fall die Ausführung des Lernvorgangs verhindert.

Postfix installieren und konfigurieren

Für unseren Postfix-Server benötigen wir nur zwei Pakete: Das Kernpaket postfix und die Komponente postfix-mysql, die Postfix mit der MySQL-Datenbank kommunizieren lässt.

apt install postfix postfix-mysql

Während der Installation werdet ihr nach der “Allgemeinen Art der Konfiguration” gefragt. Wählt an dieser Stelle “Keine Konfiguration” und beendet den Postfix-Server wieder:

systemctl stop postfix

Im Postfix-Konfigurationsverzeichnis /etc/postfix befinden sich trotz unserer Wahl “Keine Konfiguration” ein paar Konfigurationsdateien, die zunächst entfernt werden:

cd /etc/postfix
rm -r sasl
rm master.cf main.cf.proto master.cf.proto

Legt dann folgende Dateien im Verzeichnis /etc/postfix an:

`/etc/postfix/main.cf`

##
## Netzwerkeinstellungen
##
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
inet_interfaces = 127.0.0.1, ::1, 203.0.113.1, 2001:db8::1
myhostname = mail.mysystems.tld
##
## Mail-Queue Einstellungen
##
maximal_queue_lifetime = 1h
bounce_queue_lifetime = 1h
maximal_backoff_time = 15m
minimal_backoff_time = 5m
queue_run_delay = 5m
##
## TLS Einstellungen
## Quelle: https://ssl-config.mozilla.org/#server=postfix&version=3.4.8&config=intermediate&openssl=1.1.1d&guideline=5.4
##
### Allgemein
tls_preempt_cipherlist = no
tls_ssl_options = NO_COMPRESSION
tls_medium_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
### Ausgehende SMTP-Verbindungen (Postfix als Sender)
smtp_tls_security_level = dane
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_protocols = >=TLSv1.2
smtp_dns_support_level = dnssec
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtp_tls_ciphers = medium
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
### Eingehende SMTP-Verbindungen
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_ciphers = medium
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_protocols = >=TLSv1.2
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_tls_cert_file=/etc/acme.sh/mail.mysystems.tld/fullchain.pem
smtpd_tls_key_file=/etc/acme.sh/mail.mysystems.tld/privkey.pem
##
## Lokale Mailzustellung an Dovecot
##
virtual_transport = lmtp:unix:private/dovecot-lmtp
##
## Spamfilter und DKIM-Signaturen via Rspamd
##
smtpd_milters = inet:localhost:11332
non_smtpd_milters = inet:localhost:11332
milter_default_action = accept
##
## Server Restrictions für Clients, Empfänger und Relaying
## (im Bezug auf S2S-Verbindungen. Mailclient-Verbindungen werden in master.cf im Submission-Bereich konfiguriert)
##
### Bedingungen, damit Postfix als Relay arbeitet (für Clients)
smtpd_relay_restrictions = reject_non_fqdn_recipient
reject_unknown_recipient_domain
permit_mynetworks
reject_unauth_destination
### Bedingungen, damit Postfix ankommende E-Mails als Empfängerserver entgegennimmt (zusätzlich zu relay-Bedingungen)
### check_recipient_access prüft, ob ein account sendonly ist
smtpd_recipient_restrictions = check_recipient_access proxy:mysql:/etc/postfix/sql/recipient-access.cf
### Bedingungen, die SMTP-Clients erfüllen müssen (sendende Server)
smtpd_client_restrictions = permit_mynetworks
check_client_access hash:/etc/postfix/without_ptr
reject_unknown_client_hostname
### Wenn fremde Server eine Verbindung herstellen, müssen sie einen gültigen Hostnamen im HELO haben.
smtpd_helo_required = yes
smtpd_helo_restrictions = permit_mynetworks
reject_invalid_helo_hostname
reject_non_fqdn_helo_hostname
reject_unknown_helo_hostname
# Clients blockieren, wenn sie versuchen zu früh zu senden
smtpd_data_restrictions = reject_unauth_pipelining
##
## Restrictions für MUAs (Mail user agents)
##
mua_relay_restrictions = reject_non_fqdn_recipient,reject_unknown_recipient_domain,permit_mynetworks,permit_sasl_authenticated,reject
mua_sender_restrictions = permit_mynetworks,reject_non_fqdn_sender,reject_sender_login_mismatch,permit_sasl_authenticated,reject
mua_client_restrictions = permit_mynetworks,permit_sasl_authenticated,reject
##
## MySQL Abfragen
##
proxy_read_maps = proxy:mysql:/etc/postfix/sql/aliases.cf
proxy:mysql:/etc/postfix/sql/accounts.cf
proxy:mysql:/etc/postfix/sql/domains.cf
proxy:mysql:/etc/postfix/sql/recipient-access.cf
proxy:mysql:/etc/postfix/sql/sender-login-maps.cf
virtual_alias_maps = proxy:mysql:/etc/postfix/sql/aliases.cf
virtual_mailbox_maps = proxy:mysql:/etc/postfix/sql/accounts.cf
virtual_mailbox_domains = proxy:mysql:/etc/postfix/sql/domains.cf
local_recipient_maps = $virtual_mailbox_maps
##
## Sonstiges
##
### Maximale Größe der gesamten Mailbox (soll von Dovecot festgelegt werden, 0 = unbegrenzt)
mailbox_size_limit = 0
### Maximale Größe eingehender E-Mails in Bytes (50 MB)
message_size_limit = 52428800
### Keine System-Benachrichtigung für Benutzer bei neuer E-Mail
biff = no
### Nutzer müssen immer volle E-Mail Adresse angeben - nicht nur Hostname
append_dot_mydomain = no
### Trenn-Zeichen für "Address Tagging"
recipient_delimiter = +
### Keine Rückschlüsse auf benutzte Mailadressen zulassen
disable_vrfy_command = yes

Anzupassen:

inet_interfaces: IP-Adressen 203.0.113.1, 2001:db8::1 müssen durch eigene IPv4- (und optional IPv6)-Adresse ersetzt werden.
myhostname: Ersetzen durch eigenen Hostnamen
smtpd_tls_cert_file: Pfad zur Zertifikatsdatei
smtpd_tls_key_file: Pfad zur Zertifikatsschlüsseldatei

Wenn der Mailserver (entgegen meiner Empfehlung) nicht einen mail.domain.tld Hostnamen hat, sondern unter dem Domainnamen läuft (domain.tld), muss zur Konfiguration eine Zeile mit

mydestination =

(ohne Inhalt nach dem “=”) hinzugefügt werden, sonst werden E-Mails an der falschen Stelle gespeichert.

`/etc/postfix/master.cf`

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (no) (never) (100)
# ==========================================================================
###
### SMTP-Serverbindungen aus dem Internet
### Authentifizuerung hier nicht erlaubt (Anmeldung nur via smtps/submission!)
smtp inet n - y - - smtpd
-o smtpd_sasl_auth_enable=no
###
### SMTPS Service (Submission mit implizitem TLS - ohne STARTTLS) - Port 465
### Für Mailclients gelten andere Regeln, als für andere Mailserver (siehe smtpd_ in main.cf)
###
smtps inet n - y - - smtpd
-o syslog_name=postfix/smtps
-o smtpd_tls_wrappermode=yes
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_sasl_security_options=noanonymous
-o smtpd_client_restrictions=$mua_client_restrictions
-o smtpd_sender_restrictions=$mua_sender_restrictions
-o smtpd_relay_restrictions=$mua_relay_restrictions
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_sender_login_maps=proxy:mysql:/etc/postfix/sql/sender-login-maps.cf
-o smtpd_helo_required=no
-o smtpd_helo_restrictions=
###
### Submission-Zugang für Clients (mit STARTTLS - für Rückwärtskompatibilität) - Port 587
###
submission inet n - y - - smtpd
-o syslog_name=postfix/submission
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
-o smtpd_sasl_type=dovecot
-o smtpd_sasl_path=private/auth
-o smtpd_sasl_security_options=noanonymous
-o smtpd_client_restrictions=$mua_client_restrictions
-o smtpd_sender_restrictions=$mua_sender_restrictions
-o smtpd_relay_restrictions=$mua_relay_restrictions
-o milter_macro_daemon_name=ORIGINATING
-o smtpd_sender_login_maps=proxy:mysql:/etc/postfix/sql/sender-login-maps.cf
-o smtpd_helo_required=no
-o smtpd_helo_restrictions=
###
### Weitere wichtige Dienste für den Serverbetrieb
###
pickup unix n - y 60 1 pickup
cleanup unix n - y - 0 cleanup
qmgr unix n - n 300 1 qmgr
tlsmgr unix - - y 1000? 1 tlsmgr
rewrite unix - - y - - trivial-rewrite
bounce unix - - y - 0 bounce
defer unix - - y - 0 bounce
trace unix - - y - 0 bounce
verify unix - - y - 1 verify
flush unix n - y 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - y - - smtp
relay unix - - y - - smtp
showq unix n - y - - showq
error unix - - y - - error
retry unix - - y - - error
discard unix - - y - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - y - - lmtp
anvil unix - - y - 1 anvil
scache unix - - y - 1 scache

SQL-Konfiguration

Neben der Haupt-Konfiguration main.cf und der Service-Konfiguration master.cf werden noch ein paar Konfigurationsdateien innerhalb des Unterverzeichnisses sql/ angelegt, die die SQL-Queries für die Datenabfragen an die Datenbank enthalten:

mkdir /etc/postfix/sql && cd $_

Erstellt dann die folgenden Konfigurationsdateien mit dem zugehörigen Inhalt:

accounts.cf

user = vmail
password = vmaildbpass
hosts = unix:/run/mysqld/mysqld.sock
dbname = vmail
query = select 1 as found from accounts where username = '%u' and domain = '%d' and enabled = true LIMIT 1;

aliases.cf

user = vmail
password = vmaildbpass
hosts = unix:/run/mysqld/mysqld.sock
dbname = vmail
query = SELECT DISTINCT concat(destination_username, '@', destination_domain) AS destinations FROM aliases
WHERE (source_username = '%u' OR source_username IS NULL) AND source_domain = '%d'
AND enabled = true
AND NOT EXISTS (SELECT id FROM accounts WHERE username = '%u' and domain = '%d');

domains.cf

user = vmail
password = vmaildbpass
hosts = unix:/run/mysqld/mysqld.sock
dbname = vmail
query = SELECT domain FROM domains WHERE domain='%s';

recipient-access.cf

user = vmail
password = vmaildbpass
hosts = unix:/run/mysqld/mysqld.sock
dbname = vmail
query = select if(sendonly = true, 'REJECT', 'OK') AS access from accounts where username = '%u' and domain = '%d' and enabled = true LIMIT 1;

sender-login-maps.cf

user = vmail
password = vmaildbpass
hosts = unix:/run/mysqld/mysqld.sock
dbname = vmail
query = select concat(username, '@', domain) as 'owns' from accounts where username = '%u' AND domain = '%d' and enabled = true union select
concat(destination_username, '@', destination_domain) AS 'owns' from aliases
where source_username = '%u' and source_domain = '%d' and enabled = true;

Vergesst nicht, vmaildbpass in jeder der Dateien durch euer eigenes Passwort zu ersetzen!

Alle SQL-Konfgurationsdateien in /etc/postfix/sql werden vor dem Zugriff durch unberechtigte User geschützt:

chown -R root:postfix /etc/postfix/sql
chmod g+x /etc/postfix/sql

Zusätzliche Konfigurationsdatei without_ptr

Außerdem gibt es noch eine weitere Datei /etc/postfix/without_ptr, die zunächst leer bleiben kann:

touch /etc/postfix/without_ptr

Die Datei kann später einmal Einträge wie den folgenden beinhalten:

[2001:db8::beef] OK

Der Server mit der IP 2001:db8::beef muss dann keinen gültigen PTR-Record (Reverse DNS) mehr besitzen und wird trotzdem akzeptiert. Die without_ptr-Datei muss dann nach jeder Änderung in eine Datenbankdatei umgewandelt und Postfix neu geladen werden:

postmap /etc/postfix/without_ptr
systemctl reload postfix

Im Moment reicht es aber aus, einfach nur eine leere Datenbankdatei zu generieren:

postmap /etc/postfix/without_ptr

Zum Schluss wird einmal

newaliases

ausgeführt, um die Alias-Datei /etc/aliases.db zu generieren, die Postfix standardmäßig erwartet.

Rspamd

Da die Rspamd-Pakete für Debian nicht besonders aktuell sind und offiziell davon abgeraten wird, diese zu nutzen, nutzen wir an dieser Stelle das Debian-Repository des Rspamd-Projekts:

# Add Rspamd repository GPG key (modern method)
curl -fsSL https://rspamd.com/apt-stable/gpg.key | \
sudo gpg --dearmor -o /usr/share/keyrings/rspamd.gpg
# Add Rspamd repository
echo "deb [signed-by=/usr/share/keyrings/rspamd.gpg] https://rspamd.com/apt-stable/ $(lsb_release -cs) main" | \
sudo tee /etc/apt/sources.list.d/rspamd.list
# Update package list
sudo apt update
# Install Rspamd and Redis
sudo apt install rspamd redis-server

Neben Rspamd wird auch Redis installiert, damit Rspamd seine Daten ablegen kann (Key-Value Datenbank).

Rspamd stoppen:

systemctl stop rspamd

Grundkonfiguration

Die Konfiguration von Rspamd wird im Verzeichnis /etc/rspamd/local.d/ abgelegt. Die folgenden Konfigurationsdateien werden darin erstellt:

/etc/rspamd/local.d/worker-proxy.inc:

# Enable milter mode for Postfix integration
milter = yes;
timeout = 120s;
upstream "local" {
default = yes;
self_scan = yes; # Scan messages directly
}

/etc/rspamd/local.d/worker-controller.inc: Einstellung des Worker controllers: Passwort für den Zugriff via Weboberfläche, z.B.:

password = "$2$qecacwgrz13owkag4gqcy5y7yeqh7yh4$y6i6gn5q3538tzsn19ojchuudoauw3rzdj1z74h5us4gd3jj5e8y";

Der Passworthash ($2$qecacwg...) wird via

rspamadm pw

generiert und in die Datei eingefügt. Vergesst nicht das abschließende ";!

/etc/rspamd/local.d/logging.inc: Error logging

type = "syslog";
level = "warning";

Milter Headers /etc/rspamd/local.d/milter_headers.conf

use = ["x-spam-status", "authentication-results"];
authenticated_headers = ["authentication-results"];
routines {
x-spam-status {
header = "X-Spam-Status";
remove = 0;
}
}

…und in /etc/rspamd/local.d/redis.conf:

# Redis connection for statistics and caching
servers = "127.0.0.1:6379";

Für den Bayes’schen Filter (Textanalyse) wird “Auto-Learning” aktiviert:

/etc/rspamd/local.d/classifier-bayes.conf:

# Configure Bayes classifier to use Redis
servers = "127.0.0.1:6379";
backend = "redis";
# Auto-learning thresholds
autolearn = true;
min_learns = 200; # Minimum learned messages before classification

Wird eine E-Mail bereits beim Empfang abgelehnt, weil sie ausgrund der Metadaten offensichtlich von einem Spammer kommt, nutzt Rspamd die Gelegenheit und lernt, dass der Text in dieser E-Mail als Spam einzustufen ist. So wird die Erkennungsrate mit jeder Spammail besser. (https://rspamd.com/doc/configuration/statistic.html)

Manuell gepflegte Black-/Whitelists

Über das Multimap-Modul kann das Verhalten von Rspamd für bestimmte E-Mail-Merkmale personalisiert gesteuert werden. Merkmale können zum Beispiel die Absender-IP-Adresse oder die Absendermailadresse sein. Für beide registrieren wir in /etc/rspamd/local.d/multimap.conf jeweils eine Black- und eine Whitelist:

WHITELIST_IP {
type = "ip";
map = "$CONFDIR/local.d/whitelist_ip.map";
description = "Local ip whitelist";
action = "accept";
}
WHITELIST_FROM {
type = "from";
map = "$CONFDIR/local.d/whitelist_from.map";
description = "Local from whitelist";
action = "accept";
}
BLACKLIST_IP {
type = "ip";
map = "$CONFDIR/local.d/blacklist_ip.map";
description = "Local ip blacklist";
action = "reject";
}
BLACKLIST_FROM {
type = "from";
map = "$CONFDIR/local.d/blacklist_from.map";
description = "Local from blacklist";
action = "reject";
}

Für alle vier Listen werden nun Listendateien erstellt:

cd /etc/rspamd/local.d
touch whitelist_ip.map
touch whitelist_from.map
touch blacklist_ip.map
touch blacklist_from.map
cd -

“IP”-Listen können IPv6- und IPv4-Adressen bzw. Adressbereiche enthalten - in jeder Zeile ein Eintrag. “From”-Listen enthalten vollständige Absendermailadressen. Die Listen können zunächst leer bleiben. Sie eignen sich gut, wenn man später einmal für einzelne Absender oder Server Ausnahmen einstellen möchte.

Damit die Listendateien (.map-Dateien) auch vom Rspamd Webinterface aus bearbeitbar sind, bekommen sie nun noch die passenden Berechtigungen:

chown -R _rspamd:_rspamd /etc/rspamd/local.d/*.map

DKIM Signing

Rspamd übernimmt auch das Signieren von ausgehenden E-Mails. Damit signiert werden kann, muss zunächst ein Signing Key generiert werden. Der Parameter -s 2026 gibt den sogenannten Selektor an - einen Namen für den Key (hier das Erstellungsjahr).

mkdir /var/lib/rspamd/dkim/
rspamadm dkim_keygen -b 2048 -s 2026 -k /var/lib/rspamd/dkim/2026.key > /var/lib/rspamd/dkim/2026.txt
chown -R _rspamd:_rspamd /var/lib/rspamd/dkim
chmod 440 /var/lib/rspamd/dkim/*

Zum Signing Key (/var/lib/rspamd/dkim/2026.key) gehört ein dazu passender Public Key, welcher in Form eines vorbereiteten DNS-Records in der Datei /var/lib/rspamd/dkim/2026.txt liegt.

DKIM Record ausgeben lassen:

cat /var/lib/rspamd/dkim/2026.txt

Die Ausgabe sieht z.B. so aus:

2026._domainkey IN TXT ( "v=DKIM1; k=rsa; "
"p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2/al5HqXUpe+HUazCr6t9lv2VOZLR369PPB4t+dgljZQvgUsIKoYzfS/w9NagS32xZYxi1dtlDWuRfTU/ahHO2MYzE0zHE4lMfwb6VkNCG+pM6bAkCwc5cFvyRygwxAPEiHAtmtU5b0i9LY25Z/ZWgyBxEWZ0Wf+hLjYHvnvMqewPsduUqKVjDOdUqeBb1VAu3WFErOAGVUYfKqFX"
"+yfz36Alb7/OMAort8A5Vo5t5k0vxTHzkYYg5KB6tLS8jngrNucGjyNL5+k0ijPs3yT7WpTGL3U3SEa8cX8WvOO1fIpWQz4yyZJJ1Mm62+FskSc7BHjdiMHE64Id/UBDDVjxwIDAQAB"
) ;

Der Werte-Abschnitt des Records (beginnend mit v=DKIM1 bis zum Ende der Zeichenkolonne - hier AQAB) muss in einen neuen DNS-Record gepflanzt werden. Dabei werden Zeilenumbrüche und Anführungsstriche entfernt. Je nach DNS-Hoster muss ein neuer Eintrag geringfügig anders formatiert werden. Ich habe den Schritt im Screenshot beispielhaft für den Hoster Core-Networks.de mit dem Selector “2026” und meiner Beispieldomain “mysystems.tld” durchgeführt:

Wichtig: Der Selektor “2026” wird im DNS-Record zusammen mit ._domainkey als Name verwendet! Der DKIM-Record muss für jede verwendete Domain (domain2.tld, domain2.tld) im jeweiligen Zonefile erstellt werden!

Sollte der Record vom DNS-Hoster nicht akzeptiert werden, hilft es in einigen Fällen, die Schlüssellänge von 2048 Bit auf 1024 Bit zu reduzieren. Dazu das rspamadm dkim_keygen Kommando nochmals mit -b 1024 statt mit -b 2048 ausführen.

Der erzeugte DKIM-Key und der verwendete Selektor werden in der Konfigurationsdatei /etc/rspamd/local.d/dkim_signing.conf angegeben:

path = "/var/lib/rspamd/dkim/$selector.key";
selector = "2026";
### Enable DKIM signing for alias sender addresses
allow_username_mismatch = true;

Diese Konfiguration wird in die Datei /etc/rspamd/local.d/arc.conf kopiert, sodass das ARC-Modul korrekt arbeiten kann. Es greift auf dieselben Einstellungen zurück:

cp -R /etc/rspamd/local.d/dkim_signing.conf /etc/rspamd/local.d/arc.conf

Rspamd starten

Rspamd und Redis können nun gestartet werden:

systemctl enable --now redis-server
systemctl enable rspamd
systemctl start rspamd

Nginx Proxy für Rspamd Weboberfläche

Für den bequemen und sicheren Zugriff auf die Rspamd-Weboberfläche kann dieser ein Nginx HTTP-Proxy vorgeschaltet werden. Nginx kümmert sich dann um die Absicherung der Verbindung via HTTPS. Wer nur selten auf die Rspamd-Weboberfläche zugreift, kann auf diesen Schritt verzichten und stattdessen auch über einen SSH-Tunnel auf das Interface zugreifen (siehe unten).

Für den Rspamd-Webproxy wird in /etc/nginx/sites-enabled/mail.mysystems.tld ein location Block wie folgt hinzugefügt:

server {
listen 80;
listen [::]:80;
listen 443 ssl;
listen [::]:443 ssl;
server_name mail.mysystems.tld imap.mysystems.tld smtp.mysystems.tld;
http2 on;
ssl_certificate /etc/acme.sh/mail.mysystems.tld/fullchain.pem;
ssl_certificate_key /etc/acme.sh/mail.mysystems.tld/privkey.pem;
add_header Strict-Transport-Security max-age=15768000;
location /rspamd/ {
proxy_pass http://localhost:11334/;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
if ($ssl_protocol = "") {
return 301 https://$server_name$request_uri;
}
}

Anzupassen:

ssl_certificate: Pfad zu Zertifikat
ssl_certificate_key: Pfad zu Zertifikatsschlüssel
server_name

Konfiguration testen und Nginx neu laden:

nginx -t
systemctl reload nginx

Weboberfläche aufrufen

Unter https://mail.mysystems.tld/rspamd/ ist die Rspamd-Weboberfläche nun erreichbar. Als Passwort wird das weiter oben erzeugte Passwort für die Weboberfläche verwendet.

Via SSH-Tunnel mit der Weboberfläche verbinden (Alternative)

Statt über Nginx kann man auch mithilfe eines SSH-Tunnels eine sichere Verbindung zur Rspamd-Weboberfläche aufbauen. Dazu benötigt man auf dem lokalen Rechner allerdings einen SSH-Client. Der SSH-Befehl

ssh -L 8080:localhost:11334 benutzer@mail.mysystems.tld -N

verknüpft den Port des Webinterfaces (11334) mit Port 8080 des lokalen Systems. Im lokalen Webbrowser kann die Oberfläche nun unter http://localhost:8080 erreicht werden. Mit STRG+C wird die Verbindung wieder getrennt.

Domains, Accounts und Aliase in Datenbank definieren

Bevor der Mailserver sinnvoll genutzt werden kann, müssen noch Domains und Benutzer im der MySQL-Datenbank registriert werden. Loggt euch wieder auf der MySQL-Kommandozeile ein:

mysql

… und wechselt in die vmail-Datenbank:

use vmail;

Neue Domain anlegen

Damit ein neuer Benutzeraccount oder ein neuer Alias angelegt werden kann, muss die zu nutzende Domain zuvor im Mailsystem bekannt gemacht werden. Postfix verarbeitet nur E-Mails an Domains, die in der “domains”-Tabelle eingetragen sind:

INSERT INTO domains (domain) VALUES ('mysystems.tld');

Neuen E-Mail-Account anlegen

Wenn die Benutzerdomain in der Domain-Tabelle angelegt ist, kann ein neuer Benutzeraccount für den Mailserver erstellt werden. Bevor das passende SQL-Kommando eingegeben und abgeschickt wird, wird jedoch zu nächst ein Passwort-Hash des gewünschten Passworts für den Account erzeugt. Mit

doveadm pw -s ARGON2ID

(in der Bash Shell! - Nicht in der MySQL Shell!) kann ein solcher Hash erzeugt werden. Beispiel für einen ausgegebenen Hash:

{ARGON2ID}$argon2id$v=19$m=65536,t=3,p=1$VmQU9clttB7MGvxZj+Ua8A$CULlB3rPd0GCof/tRyne6Tv4f9yvZcvm3B/AMxs91uE

Dieser Hash ist für jedes Passwort einzigartig und ändert sich sogar bei jeder Generierung. Legt den Hash (von vorne bis hinten, inkl. {ARGON2ID}!) am besten gleich in eurer Zwischenablage oder einem Textdokument ab - ihr benötigt ihn gleich!

Verwendet auch an dieser Stelle möglichst nur die Zeichen 0-9, a-z und A-z. Sonderzeichen können Probleme verursachen. Wenn eure Passwörter einigermaßen lang sind, reicht das völlig aus. Sonderzeichen bringen dann ohnehin keinen nennenswerten Sicherheitsgewinn.

Das SQL-Kommando zum Erzeugen eines neuen Accounts lautet beispielsweise:

INSERT INTO accounts (username, domain, password, quota, enabled, sendonly) VALUES ('user1', 'mysystems.tld', '{ARGON2ID}$argon2id$v=19$m=65536,t=3,p=1$VmQU9clttB7MGvxZj+Ua8A$CULlB3rPd0GCof/tRyne6Tv4f9yvZcvm3B/AMxs91uE', 2048, true, false);

Folgende Werte müssen / können dabei ersetzt werden:

{ARGON2ID}...: Der Passworthash von oben muss selbstverständlich durch den eigenen ersetzt werden.
20248: In diesem Beispiel erhält der Account 2 GiB Speicher (2048 MB).
true: Außerdem ist er aktiviert
false: … und ist kein “sendonly-Account” - er darf also auch E-Mails senden

Tipp: Legt am besten gleich den postmaster@mysystems.tld Account an. Er sollte auf jedem Mailserver vorhanden sein, um den Administrator bei technischen Problemen mit dem Server erreichen zu können.

Neuen Alias anlegen

INSERT INTO aliases (source_username, source_domain, destination_username, destination_domain, enabled) VALUES ('alias', 'mysystems.tld', 'user1', 'mysystems.tld', true);

… legt einen Alias für den Benutzer “user1@mysystems.tld” an. E-Mails an “alias@mysystems.tld” werden dann an die Mailbox dieses Users zugestellt.

Als Zieladressen können auch E-Mail-Konten auf fremden Servern angegeben werden. Postfix leitet diese E-Mails dann weiter. Dabei kann es allerdings zu Problemen mit SPF-Records kommen – schließlich schickt Postfix unter bestimmten Umständen E-Mails unter fremden Domains, für die er laut SPF-Record nicht zuständig ist. SRS (Sender Rewriting Scheme) ist eine Lösung für dieses Problem. Von Erweiterungen, die schwerwiegende Design-Fehler einer Technik wie SPF korrigieren, halte ich allerdings nicht besonders viel, sodass ich euch empfehle, den SPF-Record (wie oben) auf einem “?all” gestellt zu lassen und auf Weiterleitungen zu fremden Servern möglichst zu verzichten. Aliase von lokalen Adressen auf andere lokale Adressen sind kein Problem.

Wenn ein E-Mail-Verteiler eingerichtet werden soll, werden mehrere Datensätze mit derselben Quelladresse eingerichtet, also z.B. so:

team@domain.tld => user1@domain.tld
team@domain.tld => user2@domain.tld
team@domain.tld => user3@domain.tld

Ein Catch-All hingegen kann erreicht werden, indem der source_username auf null gesetzt wird, z.B. so:

insert into aliases (source_username, source_domain, destination_username, destination_domain, enabled) values (null, 'domain1.tld', 'catchall', 'mysystems.tld', true);

Ein Catch-All kann mit anderen Aliasen auf derselben Domain ko-existieren und “fängt” alle Benutzernamen auf der jeweiligen Domain auf, für die noch kein Alias gesetzt wurde. So kann man Mails zentral aufsammeln, welche an Mailboxen verschickt wurden, die auf dem Mailserver nicht existieren. Beachtet, dass dadurch das Spamaufkommen ggf. höher ist.

Optional: Firewall konfigurieren

Wer vor / auf dem Mailserver eine Firewall betreibt, die den Zugriff auf Ports beschränkt, sollte zuerst alle Mailserver-Ports freischalten:

IMAP: 143/tcp
IMAPS: 993/tcp
Submission: 587/tcp
SMTPS: 465/tcp
SMTP: 25/tcp
ManageSieve: 4190/tcp
Web HTTP: 80/tcp
Web HTTPS: 443/tcp

Denkt unbedingt daran, auch eure IPv6-Ports zu öffnen! - Euer Mailsetup spricht IPv6! :-) Die Ports 143 und 587 können geschlossen bleiben, wenn keine StartTLS-basierenden Verbindung genutzt werden sollen (siehe Hinweis weiter unten).

Start all the things!

Euer neuer Mailserver ist jetzt fertig konfiguriert. Zeit für einen ersten Start!

systemctl start dovecot
systemctl start postfix

(Redis und Rspamd wurden bereits gestartet)

Eine Verbindung zum Mailserver herstellen

Eine Verbindung könnt ihr über jeden IMAP-fähigen E-Mail-Client und den folgenden Verbindungsparametern herstellen:

IMAP(S)
- Host: imap.mysystems.tld
- Port: 993
- Verschlüsselung: TLS
- (dieser Server gilt auch für domain2 und domain3, falls vorhanden!)
SMTP(S)
- Host: smtp.mysystems.tld
- Port: 465
- Verschlüsselung: TLS
- (dieser Server gilt auch für domain2 und domain3, falls vorhanden!)
Managesieve (optional, zur Konfiguration der benutzerspezifischen Sieve-Filterregeln)
- Host: imap.mysystems.tld
- Port: 4190
- Verschlüsselung: StartTLS
Benutzername: Die vollständige E-Mail-Adresse, also @<domain.tld>

Sollten Verbindungen über die IMAPS (993) und SMTPS (465) Ports nicht möglich sein, kann auch auf die StartTLS-Ports zurückgegriffen werden:

IMAP-Server:
- Host: imap.mysystems.tld
- Port: 143
- Verschlüsselung: StartTLS
SMTP-Server:
- Host: snmtp.mysystems.tld
- Port: 587
- Verschlüsselung: StartTLS

Die IETF (Internet Engineering Task Force) empfiehlt seit 2018 allerdings, auf StartTLS Verbindungen zu verzichten und auf native TLS-Verbindungen zu setzen: https://tools.ietf.org/html/rfc8314. Siehe auch: Golem.de: “Sicherheitsrisiko STARTTLS”

Debugging

Sollten Probleme auftreten, hilft ein Blick ins Log!

Das Rspamd Log kannst du z.B. so einsehen und live mitlesen:

journalctl -f -u rspamd

Postfix so:

journalctl -f -u postfix

… und Dovecot so:

journalctl -f -u dovecot

Falls du alle Mail-relevanten Logs einsehen willst, kannst du das Kommando auch so zusammenfassen:

journalctl -f -u rspamd -u postfix -u dovecot

Datensicherung / Backup

Folgende Verzeichnisse sollten ins Backup aufgenommen werden:

/etc/postfix (Postfix Konfiguration)
/etc/dovecot (Dovecot Konfiguration)
/etc/rspamd (Rspamd Konfiguration)
/var/vmail (E-Mail Daten, Benutzerkonteneinstellungen und Sieve-Filter)
/var/lib/rspamd/dkim (DKIM-Schlüssel)
/var/lib/redis/ (Rspamd-Daten)

Außerdem sollte unbedingt regelmäßig ein MySQL-Dump der vmail Datenbank generiert, in eine Datei geschrieben und ins Backup aufgenommen werden, z.B:

mysqldump vmail > /root/backups/vmail.sql

Das war’s auch schon! Hat dir diese Anleitung geholfen?

Wenn ich dir mit dieser Anleitung helfen konnte, deinen Mailserver aufzusetzen, ist dir das vielleicht ein paar Euro wert.

Wie du dir sicherlich vorstellen kannst, war es eine Menge Arbeit, diese Anleitung zu schreiben und zu erproben. Daher freue ich mich natürlich riesig über eine Motivationsstütze und finanzielle Hilfe, um Testserver und -Umgebungen bezahlen zu können, oder mir nach getaner Arbeit ein kühles Bier zu leisten.

Wie du mir etwas zukommen lassen kannst, erfährst du hier: Unterstützen

Herzlichen Dank!

Häufige Fehler

Wähle eine Fehlermeldung, um mögliche Lösungen zu öffnen.

Das neue E-Mail System kann keine E-Mails nach extern senden

Neben Fehlermeldungen in den Postfix-Logs sollte auch geprüft werden, ob womöglich der Serverhoster den Versand blockiert. So blockiert Hetzner beispielsweise die TCP Ports 25 und 465 ausgehend per default. Man kann diese Sperre für seinen VPS allerdings über einen Support-Request aufheben lassen. Dann funktioniert der Mailversand wieder wie gewohnt, siehe: “Hetzner FAQ: Warum kann ich keine Mails von meinem Server verschicken?”

“fatal: no SASL authentication mechanisms” / “SASL: Connect to private/auth failed: No such file or directory”

Das Problem: Postfix kann Benutzer nicht authentifizieren, weil in /var/spool/postfix/private kein “auth” Socket verfügbar ist. Eigentlich sollte Dovecot diesen Socket bereitstellen. Der Fehler ist also bei Dovecot zu suchen – nicht bei Postfix. Leider hat die Erfahrung gezeigt, dass ein Vertipper nicht zwingend in der Socket-Konfiguration

unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}

vorhanden sein muss. Es kommt immer wieder vor, dass der Fehler irgendwo anders in der Dovecot-Konfiguration liegt. Dovecot verschweigt einem dann den Fehler und erstellt den auth-Socket für Postfix nicht. Es lohnt sich in so einem Fall, noch einmal die ganze Dovecot-Konfiguration nach Fehlern abzusuchen.

“5.7.1 Service unavailable; client [1.3.3.7] blocked using zen.spamhaus.org”

Das Problem: Der Mailserver akzeptiert keine E-Mails vom Mailclient und gibt die oben genannte Fehlermeldung zurück.

Das Problem lässt sich sehr einfach lösen, indem statt SMTP-Port 25 der SMTS-Port 465 oder Submission-Port 587 für den Mailversand im Mailclient konfiguriert wird. Auf Port 25 ist eine Blacklist aktiv, welche viele IP-Adressen z.B. aus DSL-Adressbereichen enthält. Diese Einschränkung gilt für die beiden anderen Ports nicht. Mailclients sollten niemals Port 25 zum Versenden nutzen.

Mailclient verbindet sich nicht zum Server

Evtl. blockiert der Virenschutz die Verbindung?
Blockiert die Server-Firewall die Verbindung von außen?
Ist die richtige Serveradresse angegeben? (siehe Verbindungseinstellungen oben - möglicherweise hat dein E-Mail Client versucht, “schlau” zu sein und hat falsche Verbindungsdaten erraten.)
Werden die richtigen Ports genutzt und ist der Verschlüsselungstyp richtig eingestellt?
Wurde als Benutzernamen die vollständige E-Mail Adresse angegeben (und nicht nur der reine Benutzername)?

Changelog im Vergleich zur letzten Anleitung (“Mailserver unter Debian Bullseye v1.2”)

Dovecot:

Dovecot: Umstellung auf Version 2.4 - Änderungen siehe auch: https://thomas-leister.de/mailserver-migrate-config-to-dovecot-2.4-debian-trixie/
Dovecot / IMAP: mail_max_userip_connections entfernt, somit gilt default-Wert von 10 statt 50. Sollte für die meisten Setups genügen - verringert potential für Missbrauch bei geknackten Accounts.
Dovecot: quota_exceeded_message entfernt (Vereinfachung)
Dovecot: quota_storage_extra hinzugefügt für “Trash” Mailbox. Ermöglicht es, 10 MB mehr Speicher zu verwenden, wenn der Speicher eigentlich schon voll ist.
Dovecot: service lmtp: mode = 0600 statt mode = 0660
Dovecot: service imap-login und service managesieve-login entfernt
Dovecot: protocol lmtp: quota = yes gesetzt
Dovecot: service auth > auth-userdb gestrichen, wird nicht benötigt. Vereinfachung.
Dovecot: service imap-login gestrichen. Wird nicht benötigt. Vereinfachung.
Dovecot: service managesieve-login gestrichen. Wird nicht benötigt. Vereinfachung.
Dovecot: ARGON2ID als neuer Passworthash-Algorithmus. Auch als Default. SHA512-CRYPT wird noch genutzt wenn es so in der DB eingetragen ist.

Rspamd:

Rspamd/ DNS: DKIM Key auf “2026” (statt “2023”) aktualisiert
Rspamd: milter_headers.conf angepasst für x-spam-status für Mozilla Thunderbird hinzugefügt. x-spam-bar und x-spam-levels entfernt.
Rspamd: Korrekte Berechtigungen für .map Dateien in /etc/rspamd/local.d/
Rspamd: worker-proxy.inc eingeführt. Empfohlen von Rspamd Dokumentation.
Rspamd: /etc/rspamd/local.d/classifier-bayes.conf erweitert
Rspamd: /etc/rspamd/override.d/classifier-bayes.conf gelöscht

Postfix:

Postfix: smtpd_tls_dh1024_param_file aus main.cf entfernt und DH-Datei /etc/postfix/dh2048.pem entfernt. (obsolet)
Postfix: Parameter smtp_tls_mandatory_protocols, smtp_tls_protocols hinzugefügt und smtpd_tls_mandatory_protocols, smtpd_tls_protocols vereinfacht.
Postfix: Submission header cleanup entfernt. -o cleanup_service_name=submission-header-cleanup 2x in master.cf entfernt, Datei submission-header-cleanup entfernt (Vereinfachung)
Postfix: milter_protocol entfernt. Default ist okay. (Vereinfachung)
Postfix: milter_mail_macros entfernt (Vereinfachung)

Sonstiges:

acme.sh: Reload command angepasst. Bei Dovecot und Postfix “reload” statt “restart”
Thema “Autoconfig” entfernt (Vereinfachung)
TLS Policies entfernt (smtp_tls_policy_maps, proxy_read_maps, SQL Tabelle tlspolicies)
Nginx Webserver: “http2” aus “listen” Directive entfernt, stattdessen “http2 on;” gesetzt (neue Config-Syntax)
Postfix / Dovecot: Erklärungen zu Parametern entfernt (Vereinfachung)

Changelog zu diesem Beitrag

v1 (2026-02-07): Erster Release
v2 (2026-02-24):
- Abschnitt zur Generierung von /etc/postfix/dh2048.pem entfernt - obsolet.
- quota = yes aus Dovecot > protocol lmtp > mail_plugins entfernt: Redundant. Führt zu Warnung in Dovecot.

Mastodon Media Storage von Minio S3 zu SeaweedFS S3 migrieren

thomas.leister@mailbox.org (Thomas Leister) — Fri, 23 Jan 2026 15:03:21 +0100

Bisher habe ich gerne den Minio S3 Server zusammen mit meiner Mastodon Instanz metalhead.club genutzt, um dort Mediendateien abzulegen. Doch seit Sommer letzten Jahres nimmt das Minio-Projekt leider einen Verlauf, der mich dazu bewegt hat, mich nach Alternativen umzusehen: Zuerst wurde der interne Dateibrowser aus der Verwaltungsoberfläche gestrichen - kurz darauf wurde dann verkündet, dass Minio nicht mehr als Open Source Projekt weiter gepflegt würde. Außerdem wurde die Verteilung von Minio-Binaries eingestellt. Es gab also keine Updates mehr. Minio ist seitdem effektiv tot - zumindest, was die Community Version angeht.

Mit SeaweedFS habe ich allerdings eine tolle Alternative gefunden, auf die ich meine Mastodon Instanz kürzlich umgestellt habe. Hier beschreibe ich, in welche Probleme ich dabei gelaufen bin und wie ich diese gelöst habe.

SeaweedFS installieren

Die Installation gestaltet sich sehr einfach: SeaweedFS besteht nur aus einem einzelnen Binary, welches heruntergeladen und unter /usr/local/bin abgelegt wird:

curl -L https://github.com/seaweedfs/seaweedfs/releases/download/4.07/linux_amd64_full.tar.gz | tar xvz -C /usr/local/bin/

Anschließend wird ein neuer SeaweedFS Systembenutzer erstellt:

useradd --system seaweedfs

… und ein passender Systemd Service angelegt:

/etc/systemd/system/seaweedfs.ervice:

[Unit]
Description=SeaweedFS Server
After=network.target
[Service]
Type=simple
User=seaweedfs
Group=seaweedfs
ExecStart=/usr/local/bin/weed server -s3 -ip 127.0.0.1 -ip.bind=127.0.0.1 -volume.max=0 -dir /mnt/s3storage1/seaweedfs
WorkingDirectory=/usr/local/bin
SyslogIdentifier=seaweedfs
[Install]
WantedBy=multi-user.target

/usr/local/bin/weed server -s3 startet das SeaweedFS Binary weed - und damit die Komponenten master server, volume server, filer und das s3 Frontend.
-ip 127.0.0.1 -ip.bind=127.0.0.1: Interne Kommunikationsschnittstellen und auch die S3 API sollen localhost-intern bleiben, da wir SeaweedFS nicht in einem Cluster betreiben und auch die S3 Schnittstelle nur dem internen Nginx Proxy zugänglich gemacht werden soll.
-volume.max=0 sorgt dafür, dass die Anzahl der Storage-Volumes nicht begrenzt wird. Hier könnte man ansonsten einstellen, wie viel Speicher SeaweedFS maximal nutzen darf (default: 1 Volume = 30 GB). In meinem Fall soll der gesamte zur Verfügung stehende Speicher genutzt werden.
-dir /mnt/s3storage1/seaweedfs hier werden die Volumes in Form von Dateien abgelegt.

Service aktivieren und starten:

systemctl enable --now seaweedfs.service

Nach einigen Sekunden sollte SeaweedFS gestartet sein. Siehe auch:

systemctl status seaweedfs

Ein Bucket anlegen

Über die “weed shell” kann nun ein neues S3 Bucket angelegt und konfiguriert werden. In meinem Fall heißt das neue Bucket “metalheadclub-media”.

Shell öffnen:

weed shell

Bucket erstellen:

s3.bucket.create -name metalheadclub-media

Berechtigungen setzen (dynamisch, anstatt eines json config files):

s3.configure -access_key=ACCESS_KEY -secret_key=SECRET_KEY -buckets=metalheadclub-media -user=mastodon -actions=Read,Write,List -apply

Dabei wird zur Bestätigung folgendes ausgegeben:

{
"identities": [
{
"name": "mastodon",
"credentials": [
{
"accessKey": "ACCESS_KEY",
"secretKey": "SECRET_KEY",
"status": ""
}
],
"actions": [
"Read:metalheadclub-media",
"Write:metalheadclub-media",
"List:metalheadclub-media"
],
"account": null,
"disabled": false,
"serviceAccountIds": [],
"policyNames": []
}
],
"accounts": [],
"serviceAccounts": []
}

Anonyme (öffentliche) User bekommen nur Lesezugriff auf die Mediendateien:

s3.configure -buckets=metalheadclub-media -user=anonymous -actions=Read -apply

Ausgabe:

{
"identities": [
{
"name": "mastodon",
"credentials": [
{
"accessKey": "ACCESS_KEY",
"secretKey": "SECRET_KEY",
"status": ""
}
],
"actions": [
"Read:metalheadclub-media",
"Write:metalheadclub-media",
"List:metalheadclub-media"
],
"account": null,
"disabled": false,
"serviceAccountIds": [],
"policyNames": []
},
{
"name": "anonymous",
"credentials": [],
"actions": [
"Read:metalheadclub-media"
],
"account": null,
"disabled": false,
"serviceAccountIds": [],
"policyNames": []
}
],
"accounts": [],
"serviceAccounts": []
}

Anschließend kann die Shell mit “quit” wieder verlassen werden.

Migration der Daten von Minio zu SeaweedFS

Der SeaweedFS Server ist nun aktiv, das Bucket erstellt und mit den nötigen Berechtigungen ausgestattet - Zeit für die Migration der Daten von Minio zu SeaweedFS!

Für die Migration gab es zwei Dinge zu beachten:

Die Migration sollte so “lautlos” wie möglich passieren und für die Nutzer meiner Mastodon Instanz keinen Einfluss haben.
Da ich dieselbe virtuelle Maschine mit demselben Speicher für SeaweedFS nutzen wollte und der Speicher begrenzt war, sollten die Daten von Minio zu SeaweedFS verschoben werden - nicht kopiert!

Die Strategie lautete - wie bei vorherigen Migrationen auch schon - wie folgt:

Neues Backend in Betrieb nehmen
Frontend-Proxy mit beiden Backends konfigurieren => Frontend fragt zuerst neues Backend an, im Fehlerfall Fallback auf altes Backend
Mastodon-Instanz umkonfigurieren: Speichert neue Medien in neues Backend, während alte Medien aus dem alten Backend zugreifbar bleiben
Medien werden von altem Storage im Hintergrund langsam zu neuem Storage verschoben
… bis alter Storage schließlich leer ist und entfernt werden kann
Fertig!

Zwei S3 Backends für einen glatten Übergang

Konfiguration für die Datenmigration habe ich hier visualisiert:

Grafik zeigt die Abhängigkeiten zwischen den Nginx Proxies und den S3 Servern. Den Start bildet ein media.metalhead.club Server, der das Frontend bildet. Dahinter führt ein Pfad direkt zu Minio - ein anderer Pfad über einen weiteren Proxy s3.650thz.de zum SeaweedFS Backend.

Die obere Reihe (media.metalhead.club, Minio Server) existierte schon früher - neu hinzugekommen ist das SeaweedFS Backend und der s3.650thz.de Server. Der media.metalhead.club Nginx-Proxy sollte (ähnlich wie bei der Migration von Scaleway S3 zu Minio) wieder eine besondere Rolle einnehmen und während der Migration der Daten flexibel zwischen den beiden S3 Backends umschalten. Primär sollte das neue SeaweedFS Backend Anfragen beantworten. Für den Fall, dass das neue Backend die Daten nicht liefern konnte, wurde ein Fallback implementiert, dass dafür sorgte, dass die Anfrage dann vom alten Minio-Backend beantwortet werden konnte.

Der Schlüssel liegt in diesen Zeilen:

# During data migration: Forward request to @minio if @seaweedfs returns 404 or 403 (access denied)
proxy_intercept_errors on;
recursive_error_pages on;
error_page 404 403 = @minio;

Virtual Host style addressing für SeaweedFS S3

Ein wichtiger Unterschied in der Behandlung des SeaweedFS Backend im Vergleich zu Minio ist, dass SeaweedFS kein Virtual Host Addressing von S3-Buckets unterstützt! Mit Minio lässt sich ein Bucket auf zwei Arten adressieren:

bucket.s3server.tld oder
s3server.tld/bucket

Ersteres ist bei SeaweedFS also nicht möglich. Stattdessen schlägt das SeaweedFS Wiki vor, Adressen so in letztere Form umzuschreiben:

...
 server_name ~^(?:(?<bucket>[^.]+)\.)?s3\.yourdomain\.com;
 ...
 # If bucket subdomain is not empty,
 # rewrite request to backend.
 if ($bucket != "") {
 rewrite (.*) /$bucket$1 last;
 }
...

Diese Art der Konfiguration konnte ich in meinem media.metalhead.club VirtualHost allerdings nicht umsetzen, weil das zum einem Fehler führte:

[error] 1388933#1388933: *5700433 rewrite or internal redirection cycle while redirect to named location "@seaweedfs", client: xxx, server: media.metalhead.club, request: "GET /cache/custom_emojis/images/xxx.png HTTP/2.0", host: "media.metalhead.club"

Also habe ich diesen Mechanismus kurzerhand in einen weiteren vHost “s3.650thz.de” ausgelagert:

upstream seaweedfs {
 hash $arg_uploadId consistent;
 server 127.0.0.1:8333 fail_timeout=0;
 keepalive 20;
}

server {
 listen 80;
 listen [::]:80;
 listen 443 ssl;
 listen [::]:443 ssl;

 # Enable http2
 http2 on;

 server_name ~^(?<bucket>[^.]+)\.s3\.650thz\.de s3.650thz.de;

 ssl_certificate /etc/acme.sh/s3.650thz.de/fullchain.pem;
 ssl_certificate_key /etc/acme.sh/s3.650thz.de/privkey.pem;

 ignore_invalid_headers off;
 client_max_body_size 0;
 proxy_buffering off;
 proxy_request_buffering off;

 location / {
 proxy_set_header Host $http_host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;

 proxy_http_version 1.1;
 proxy_set_header Connection "";
 chunked_transfer_encoding off;

 if ($bucket != "") {
 rewrite ^/(.*)$ /$bucket/$1 break;
 }

 proxy_pass http://seaweedfs; # This uses the upstream directive definition to load balance
 }
}

Letztendlich dient der vHost also nur der Umwandlung von einem “virtual host style addressing” in das herkömmliche “path style addressing”.

(Das “vHost style addressing” im media.metalhead.club vHost für die proxy_pass Direktiven benötigt, da hier keine Pfade a la proxy_pass http://seaweedfs/bucket angegeben werden können.)

Meine media.metalhead.club für die Migrationsphase sieht nun so aus:

upstream minio {
 server 127.0.0.1:9000;
 keepalive 2;
}

server {
 listen 80;
 listen [::]:80;
 listen 443 ssl;
 listen [::]:443 ssl;

 server_name media.metalhead.club;

 # Enable http2
 http2 on;

 # SSL
 ssl_certificate /etc/acme.sh/media.metalhead.club/fullchain.pem;
 ssl_certificate_key /etc/acme.sh/media.metalhead.club/privkey.pem;

 client_max_body_size 100M;

 root /var/www/media.metalhead.club;

 location / {
 access_log off;
 try_files $uri @seaweedfs;
 }

 # Display index.html if user is browsing https://media.metalhead.club
 location = / {
 alias /var/www/media.metalhead.club/;
 }


 #
 # Own SeaweedFS S3 server (new)
 #

 location @seaweedfs {
 # Set headers
 proxy_set_header Host 'metalheadclub-media.s3.650thz.de';
 proxy_set_header Connection '';
 proxy_set_header Authorization '';

 # Hide headers
 proxy_hide_header Set-Cookie;
 proxy_hide_header 'Access-Control-Allow-Origin';
 proxy_hide_header 'Access-Control-Allow-Methods';
 proxy_hide_header 'Access-Control-Allow-Headers';
 # Hide amazon S3 headers, which are sent by Minio for compatibility
 proxy_hide_header x-amz-id-2;
 proxy_hide_header x-amz-request-id;
 proxy_hide_header x-amz-meta-server-side-encryption;
 proxy_hide_header x-amz-server-side-encryption;
 proxy_hide_header x-amz-bucket-region;
 proxy_hide_header x-amzn-requestid;
 proxy_hide_header x-amz-meta-mtime;

 # ignore headers
 proxy_ignore_headers Set-Cookie;

 # Pass headers
 proxy_pass_header Date;
 proxy_pass_header Last-Modified;
 proxy_pass_header ETag;
 proxy_pass_header Cache-Control;
 proxy_pass_header Expires;

 # Connection to backend server
 proxy_pass http://[::1];
 proxy_connect_timeout 1s;
 proxy_send_timeout 30s;
 proxy_read_timeout 30s;

 # Buffer settings
 proxy_request_buffering off;
 proxy_buffering on;
 proxy_buffers 16 64k;
 proxy_busy_buffers_size 128k;
 proxy_buffer_size 32k;

 # Migration Workaround: Forward request to @minio if @seaweedfs returns 404 or 403 (access denied)
 proxy_intercept_errors on;
 recursive_error_pages on;
 error_page 404 403 = @minio;

 add_header 'Access-Control-Allow-Origin' '*';
 add_header X-Cache-Status $upstream_cache_status;
 add_header Content-Security-Policy "default-src 'none'; form-action 'none'";
 add_header X-Served-By "s3.650thz.de SeaweedFS";
 }

 #
 # Own Minio S3 server (old)
 #
 location @minio {
 limit_except GET {
 deny all;
 }

 # Set headers
 proxy_set_header Host 'metalheadclub-media.s3.650thz.de';
 proxy_set_header Connection '';
 proxy_set_header Authorization '';

 # Hide headers
 proxy_hide_header Set-Cookie;
 proxy_hide_header 'Access-Control-Allow-Origin';
 proxy_hide_header 'Access-Control-Allow-Methods';
 proxy_hide_header 'Access-Control-Allow-Headers';
 # Hide amazon S3 headers, which are sent by Minio for compatibility
 proxy_hide_header x-amz-id-2;
 proxy_hide_header x-amz-request-id;
 proxy_hide_header x-amz-meta-server-side-encryption;
 proxy_hide_header x-amz-server-side-encryption;
 proxy_hide_header x-amz-bucket-region;
 proxy_hide_header x-amzn-requestid;
 proxy_hide_header x-amz-meta-mtime;

 # ignore headers
 proxy_ignore_headers Set-Cookie;

 # Pass headers
 proxy_pass_header Date;
 proxy_pass_header Last-Modified;
 proxy_pass_header ETag;
 proxy_pass_header Cache-Control;
 proxy_pass_header Expires;

 # Connection to backend server
 proxy_pass http://minio;
 proxy_connect_timeout 1s;
 proxy_send_timeout 30s;
 proxy_read_timeout 30s;

 # Buffer settings
 proxy_request_buffering off;
 proxy_buffering on;
 proxy_buffers 16 64k;
 proxy_busy_buffers_size 128k;
 proxy_buffer_size 32k;

 add_header 'Access-Control-Allow-Origin' '*';
 add_header X-Cache-Status $upstream_cache_status;
 add_header Content-Security-Policy "default-src 'none'; form-action 'none'";
 add_header X-Served-By "s3.650thz.de Minio";
 }
}

Über add_header X-Served-By "s3.650thz.de ..." lasse ich mir zudem in die HTTP-header schreiben, ob eine Datei von Minio oder von SeaweedFS ausgeliefert wurde. So kann ich später prüfen, ob die Datenmigration wie erhofft funktioniert hat.

Umstellung der Mastodon Instanz

Damit Mastodon die neuen Mediendateien in SeaweedFS ablegte, mussten noch die korrekten Parameter in der .env.production Konfiguration gesetzt werden:

S3_ENABLED=true
S3_BUCKET=metalheadclub-media
AWS_ACCESS_KEY_ID=ACCESS_KEY
AWS_SECRET_ACCESS_KEY=SECRET_KEY
S3_ALIAS_HOST=media.metalhead.club
S3_REGION=hyper2
S3_PROTOCOL=https
S3_HOSTNAME=media.metalhead.club
S3_ENDPOINT=https://s3.650thz.de
S3_SIGNATURE_VERSION=v4

Nach einem Neustart aller Mastodon Services war die Änderung aktiv:

cd /etc/systemd/system
systemctl restart mastodon*

Ob meine Änderung erfolgreich war, konnte ich einfach prüfen: Ich wartete in der globalen Mastodon Timeline neue Posts mit Bildern ab und öffnete die Grafik in einem neuen Tab. Über die Firefox Entwicklertools lassen sich dann auch die HTTP-Header zur Datei anzeigen. Wie erhofft, war der X-Served-By Header auf “SeaweedFS” gesetzt. :)

… und auch die alten Grafiken ließen sich nach wie vor abrufen. Sie wurden mit X-Served-By “Minio” ausgeliefert.

Datentransfer

Prima! Dann konnte es ja jetzt an die eigentliche Datenmigration gehen. Weg von Minio - hin zu SeaweedFS.

Eigentlich ist eine solche Migration keine hohe Kunst. Ich habe rclone mit beiden S3 Buckets konfiguriert:

[minio]
type = s3
provider = Minio
env_auth = false
access_key_id = ACCESS_KEY
secret_access_key = SECRET_KEY
region = hyper2
endpoint = http://127.0.0.1:9000
location_constraint = hyper2
acl = public-read
[seaweedfs]
type = s3
provider = SeaweedFS
access_key_id = ACCESS_KEY
secret_access_key = SECRET_KEY
endpoint = http://127.0.0.1:8333
acl = public-read

Den Zugriff auf beide Buckets habe ich mit einer einfachen Dateiauflistung getestet:

rclone lsd seaweedfs:metalheadclub-media
rclone lsd minio:metalheadclub-media

Daraufhin habe ich begonnen, testweise zunächst nur kleinere Verzeichnisse wie z.B. site_uploads von Minio zu SeaweedFS zu kopieren (statt zu verschieben!):

rclone sync minio:metalheadclub-media/site_uploads/ seaweedfs:metalheadclub-media/site_uploads/

Wieder habe ich über die Browser-Tools getestet, wie die betroffenen Grafiken (z.B. Banner-Grafik unter https://metalhead.club/about) ausgeliefert wurden. Während sie erst von Minio ausgeliefert wurden, wurden sie nach dem rclone sync von SeaweedFS ausgeliefert.

Nachdem auch dieser Test erfolgreich war, migrierte ich die Mastodon Mediendaten Stück für Stück zu SeaweedFS (diesmal durch verschieben mit move statt mit sync zu kopieren!)

Liste der zu verschiebenden Verzeichnisse:

root@s3 /root # rclone lsd minio:metalheadclub-media/
0 2026-01-16 14:01:17 -1 accounts
0 2026-01-16 14:01:17 -1 backups
0 2026-01-16 14:01:17 -1 cache
0 2026-01-16 14:01:17 -1 custom_emojis
0 2026-01-16 14:01:17 -1 imports
0 2026-01-16 14:01:17 -1 media_attachments
0 2026-01-16 14:01:17 -1 site_uploads

Meine Kommandos zu verschieben:

rclone move --delete-empty-src-dirs minio:metalheadclub-media/accounts seaweedfs:metalheadclub-media/accounts
rclone move --delete-empty-src-dirs minio:metalheadclub-media/backups seaweedfs:metalheadclub-media/backups
rclone move --delete-empty-src-dirs minio:metalheadclub-media/custom_emojis seaweedfs:metalheadclub-media/custom_emojis
rclone move --delete-empty-src-dirs minio:metalheadclub-media/imports seaweedfs:metalheadclub-media/imports
rclone move --delete-empty-src-dirs minio:metalheadclub-media/media_attachments seaweedfs:metalheadclub-media/media_attachments
rclone move --delete-empty-src-dirs minio:metalheadclub-media/site_uploads seaweedfs:metalheadclub-media/site_uploads

Wer gut aufpasst, wird bemerken, dass ich ein Verzeichnis ausgelassen habe: Das Mediencacheverzeichnis /cache! Dieses ist mit Abstand das Größte und bekommt eine Sonderbehandlung …

Ärger mit dem großen /cache Verzeichnis

Dieses Verzeichnis enthält alle Dateien, die nicht vom eigenen Mastodon-Server stammen. Also zwischengespeicherte Remote-Mediendaten und Vorschaubildchen. Je nach Cache-Vorhaltezeit kann das Verzeichnis sehr groß werden. Im Fall von metalhead.club hatte ich es hier mit etwa 700 GB und ca 3 Millionen kleinen Dateien zu tun. Tatsächlich ist nicht die Gesamtgröße das Problem, sondern die Anzahl der Dateien.

Natürlich habe ich auch versucht, dieses Verzeichnis auf den neuen Storage zu bewegen:

rclone move --delete-empty-src-dirs minio:metalheadclub-media/cache seaweedfs:metalheadclub-media/cache

… doch das scheitere nach wenigen Minuten an zu wenig RAM. Ich gab mehr RAM (ca 16 GB), doch erneut war das rclone Tool so RAM-hungrig, dass es vom OOM-Killer beendet wurde.

Also gut. Wenn ich schon nicht alle Daten aus dem Cache Verzeichnis verschieben konnte, konnte ich sie doch einfach im alten Minio Bucket liegen lassen, bis sie aufgelaufen waren! Denn im /cache Verzeichnis befinden sich ausschließlich Dateien, die für den Betrieb nicht sehr wichtig sind, und die normalerweise von Mastodon nach einer festgelegten Dauer sowieso aufgeräumt werden (Bei metalhead.club: Cache Retention 15 Tage).

“Einfach liegen lassen und warten” klingt nach einer verlockenden Strategie, aber so einfach ist es nicht. Denn durch die Umstellung der Mastodon-Software auf das neue Bucket funktionieren Mastodon-interne Löschroutinen nicht mehr. Das Bucket bleibt so voll, wie es zuletzt war. Und neue Dateien drängen auf das System. Das Ergebnis: Der Speicherverbrauch steigt.

Wer sehr viel freien Speicher hat, kann möglicherweise tatsächlich einfach warten, bis 15 Tage um sind, und kann das Bucket dann als gesamtes einfach löschen. Ich hatte allerdings nur ca 170 GB freien Speicher. Der würde durch neu hinzukommende Medien im neuen Bucket schon deutlich vor 15 Tagen aufgebraucht sein. Abwarten war also keine Option. Die alten Medien mussten unbedingt nach und nach gelöscht werden.

Zunächst habe ich es über rclone Kommandos versucht. Dieses Kommando löscht alle Dateien, die älter als 15 Tage sind:

rclone -v --min-age 15d delete --rmdirs minio:metalheadclub-media/cache

… - eigentlich. Erneut waren die Anforderungen an den RAM zu hoch (z.T. 15 GB Verbrauch nur durch rclone!)

Mit einigen Optimierungen kann man den Verbrauch deutlich drücken:

GOGC=20 rclone --list-cutoff 100000 --min-age 15d delete --rmdirs minio:metalheadclub-media/cache

Siehe auch: https://rclone.org/faq/#rclone-is-using-too-much-memory-or-appears-to-have-a-memory-leak

Als ich gerade glaubte, das Problem gelöst zu haben, kam nun ein anderer Fehler um die Ecke:

ERROR : Attempt 1/3 failed with 1 errors and: operation error S3: ListObjectsV2, exceeded maximum number of attempts, 10, https response error StatusCode: 0, RequestID: , HostID: , request send failed, Get "http://127.0.0.1:9000/metalheadclub-media?delimiter=&encoding-type=url&list-type=2&max-keys=1000&prefix=cache%2F": net/http: timeout awaiting response headers

Offenbar dauerte das Auflisten der Dateien so lange, dass der S3 Server selbst in ein Timeout lief (nach ca. 10 Minuten). Wie sollte ich das lösen? In dem Bucket waren einfach zu viele Dateien.

Auch mit dem Minio-eigenen Tool mc hatte ich kein Glück:

./mc rm --recursive --force --older-than 15d minio/metalheadclub-media/cache
mc: <ERROR> Failed to remove `minio/metalheadclub-media/cache` recursively. Get "http://localhost:9000/metalheadclub-media/?delimiter=&encoding-type=url&fetch-owner=true&list-type=2&prefix=cache": read tcp [::1]:53662->[::1]:9000: i/o timeout

Wie konnte ich 3 Mio. kleine Dateien loswerden? Wie sich herausstellte: Eigentlich sehr einfach …

Dateien löschen über S3 Lifecycle Rules

… denn ich hatte einen praktischen S3 Mechanismus total vergessen: Lifecycle Rules. Mit diesen Regeln lässt sich für Dateien festlegen, was mit ihnen während oder nach ihrem Lebenszyklus passieren soll. Ein Use Case ist: Automatisches Löschen. Genau, was ich brauchte! Und das beste daran: Diese Löschung findet Backend-intern statt und muss nicht durch Tools von außen gesteuert werden. Mein Timeout-Problem bei der Dateiauflistung konnte ich so geschickt umgehen.

Ich habe also das mc Tool genutzt, um alle Dateien in /cache nach 15 Tagen ablaufen zu lassen:

mc ilm add minio/metalheadclub-media/cache --expire-days 15

Fertig!

Der aktuelle Status lässt sich mit

mc admin scanner status minio/

einsehen. Damit der Minio-interne Dateiscanner schneller arbeitet und Dateien somit schneller löscht, wenn sie ihr Haltbarkeitsdatum überschritten haben, kann der Vorgang noch etwas beschleunigt werden:

mc admin config set minio/ scanner speed=fastest

Abschluss

Nach 15 Tagen waren alle alten Dateien gelöscht und ich konnte das Minio-Bucket löschen, Minio entfernen und das alte Bucket auch aus meinen Nginx-Konfigurationen entfernen. Die Zeilen

# Migration Workaround ...
proxy_intercept_errors on;
recursive_error_pages on;
error_page 404 403 = @minio;

und

location @minio {
 ...
}

wurden entfernt und Nginx neu geladen. Metalhead.club war nun vollständig zu SeaweedFS migriert.

Ein Dank geht übrigens an Stefano Marinelli (@stefano@bsd.cafe) für den SeaweedFS Artikel unter FreeBSD. Dieser hat mich letztendlich dazu bewegt, SeaweedFS eine Chance zu geben und die Umstellung anzupacken.

Alte Dovecot Konfiguration zu Dovecot 2.4 (Debian Trixie) migrieren

thomas.leister@mailbox.org (Thomas Leister) — Sat, 01 Nov 2025 10:10:33 +0100

Seit einigen Wochen ist die neue Debian-Version “Trixie” zum Upgrade von Debian “Bookworm” erhältlich - und damit haben sich auch einige meiner Leser zu einer Aktualisierung ihres Mailserver-Setups aus meiner “Mailserver mit Dovecot, Postfix, MySQL und Rspamd unter Debian 10 Buster [v1.0]” Mailserveranleitung entschieden. Das für Debian Buster beschriebene Setup funktioniere nämlich genauso gut auch für Debian Bookworm - aber mit Debian Trixie kommt der Bruch:

Die neueste Debian Version macht bei der mitgelieferte Dovecot-Version einen Sprung auf Dovecot 2.4. Damit sind alte Dovecot-Konfigurationen nicht mehr kompatibel!

Die Konfigurations-Syntax hat sich an einigen Punkten stark geändert und alte Konfigurationen aus vorherigen Dovecot-Versionen können nicht mehr eingelesen werden. Dieser Beitrag geht auf die Änderungen in der neuen Version 2.4 ein und erklärt die Migration anhand des Beispiels der oben erwähnten Mailserveranleitung. Alle Änderungen spielen sich in der Datei /etc/dovecot/dovecot.conf ab. Weitere Änderungen (z.B. an Datenbankschema o.Ä.) sind nicht notwendig.

Eine vollständige Konfigurationsdatei findet ihr am Ende dieses Beitrags.

Insgesamt hat sich verändert:

Die Art und Weise, wie Konfigurationsparameter geschachtelt werden können
Namen einzelner Parameter
Variablennamen und -Funktionen

Alle Änderungen sind in der Dovecot-Dokumentation beschrieben. Wer beim Setup seines Mailservers meiner Anleitung gefolgt ist, kann jedoch einfach weiterlesen und die beschriebenen Schritte ausführen, um zu einer funktionierenden Konfiguration zu kommen.

Schritt 1: Config-Versionsnummern hinzufügen

Dovecot 2.4 führt eine Versionierung der Konfigurationssyntax ein. Deshalb müssen am Anfang der Datei folgende Zeilen unbedingt eingefügt werden:

# Dovecot config and storage versions
dovecot_config_version = 2.4.0
dovecot_storage_version = 2.4.0

Das Versäumnis aus der Vergangenheit scheint man nun nachgeholt zu haben ;-). Zukünftige Änderungen an der Syntax können dann von Dovecot selbst abgefangen werden bzw. bei Änderungen gewarnt werden.

SSL-Einstellungen

Die SSL-Einstellungen werden wie folgt umbenannt bzw. verändert:

ssl_cert => ssl_server_cert_file (und spitze Klammer zu Beginn weglassen)
ssl_key => ssl_server_key_file (und spitze Klammer zu Beginn weglassen)
ssl_dh => ssl_server_dh_file (und spitze Klammer zu Beginn weglassen)
ssl_prefer_server_ciphers => ssl_server_prefer_ciphers. Werte nicht “yes” oder “no”, sondern “client” oder “server”. Default: Client. Einstellung kann entfernt werden.
ssl_min_protocol: kann weggelassen werden, default ist bereits TLSv1.2
disable_plaintext_auth=yes => auth_allow_cleartext=no. Ist default - kann weggelassen werden.

Insgesamt ergibt sich also:

ssl = required
ssl_server_cert_file = /etc/acme.sh/mydomain.tld/fullchain.pem
ssl_server_key_file = /etc/acme.sh/mydomain.tld/privkey.pem
ssl_server_dh_file = /etc/dovecot/dh4096.pem
ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384

PassDB / UserDB und auth_username_format

Die beiden PassDB und UserDB Abschnitte werden zu:

passdb sql {
query = SELECT username AS user, domain, password FROM accounts WHERE username = '%{user | username | lower }' AND domain = '%{user | domain | lower}' and enabled = true;
default_password_scheme = SHA512-CRYPT
}
userdb sql {
query = SELECT concat(quota, 'M') AS quota_storage_size FROM accounts WHERE username = '%{user | username | lower }' AND domain = '%{user | domain | lower}' AND sendonly = false;
iterate_query = SELECT username, domain FROM accounts where sendonly = false;
}

Achtet speziell auf die angepassten Variablen, z.B. %{user | username | lower }. Hinter dem concat(quota, 'M') AS quota_storage_size versteckt sich außerdem ein kleiner Bugfix, den ich hier direkt einbringen will. ;-)

Außerdem wird die Variable auch bei auth_username_format angepasst:

auth_mechanisms = plain login
auth_username_format = %{user | lower }

Damit die gerade definierten UserDB und PassDB Abschnitte überhaupt funktionieren, werden die Zugangsdaten zur MySQL-Datenbank in einem neuen SQL-Abschnitt definiert:

sql_driver = mysql
mysql /var/run/mysqld/mysqld.sock {
user = vmail
password = mypassword
dbname = vmail
}

mypassword muss selbstverständlich angepasst werden!

Die Datei /etc/dovecot/dovecot-sql.conf kann vollständig gelöscht werden - sie wird nicht mehr benötigt.

Mail location

Die Definition des Mailspeicherorts mail_location wird in mehrere Parameter aufgeteilt und hierdurch ersetzt:

mail_driver = maildir
mail_path = ~/mail
mailbox_list_layout = fs

Außerdem bekommt der mail_home Parameter neue Variablennamen:

mail_home = /var/vmail/mailboxes/%{user | domain }/%{user | username }

Protocols

Die protocols Einstellung und die beiden protocol imap und protocol lmtp Sections werden zu diesem Block:

protocols {
lmtp = yes
imap = yes
sieve = yes
}
protocol imap {
mail_plugins {
imap_quota = yes
imap_sieve = yes
}
mail_max_userip_connections = 50
imap_idle_notify_interval = 29 mins
}
protocol lmtp {
mail_plugins {
sieve = yes
notify = yes
push_notification = yes
}
postmaster_address = postmaster@mydomain.tld
}

Plugins Section

Das plugins Segment

plugins {
...
}

gibt es nicht mehr. Stattdessen wird der Inhalt direkt global.

Sieve Plugineinstellungen

sieve_plugins, sieve_before und sieve werden zu:

sieve_plugins {
sieve_imapsieve = yes
sieve_extprograms = yes
}
sieve_script spam-global {
type = before
path = /var/vmail/sieve/global/spam-global.sieve
}
sieve_script personal {
type = personal
path = /var/vmail/sieve/%{user | domain }/%{user | username }/scripts
active_path = /var/vmail/sieve/%{user | domain }/%{user | username }/active-script.sieve
}

Alle imapsieve* Parameter werden insgesamt zu:

# From Mailbox to Spam
mailbox Spam {
sieve_script spam {
type = before
cause = copy
path = /var/vmail/sieve/global/learn-spam.sieve
}
}
# From Spam to another folder (learn HAM)
imapsieve_from Spam {
sieve_script ham {
type = before
cause = copy
path = /var/vmail/sieve/global/learn-ham.sieve
}
}

sieve_global_extensions wird zu:

sieve_global_extensions {
vnd.dovecot.pipe = yes
}

Quota

quota und quota_exceeded_message werden zu:

quota "User quota" {
driver = count
}
quota_exceeded_message = Benutzer %{user} hat das Speichervolumen ueberschritten. / User %{user} has exhausted allowed storage space.

Der alte “fs” Treiber für Quota soll nicht mehr genutzt werden. Stattdessen wird nun count genutzt. quota_exceeded_message bekommt außerdem neue Variablennamen.

Im neuen mail_plugins Blog wird das Quota-Plugin aktiviert:

mail_plugins {
quota = yes
}

Im vorher bereits erwähnten protocol imap Block wurde außerdem noch imap_quota aktiviert.

Änderung der Zugriffsrechte

Da nun die MySQL-Zugangsdaten direkt in der Hauptkonfigurationsdatei liegen und nicht mehr in eine extra Datei ausgelagert sind, werden die Zugriffsrechte auf dovecot.conf weiter eingeschränkt. Außer root soll niemand mehr die Datei lesen können:

chmod 600 /etc/dovecot/dovecot.conf

Vollständige Beispielkonfiguration

Für den einfacheren Vergleich hier nochmal die vollständige Datei /etc/dovecot/dovecot.conf:

# Dovecot config and storage versions
dovecot_config_version = 2.4.0
dovecot_storage_version = 2.4.0
###
### Protocol settings
#############################
protocols {
lmtp = yes
imap = yes
sieve = yes
}
protocol imap {
mail_plugins {
imap_quota = yes
imap_sieve = yes
}
mail_max_userip_connections = 50
imap_idle_notify_interval = 29 mins
}
protocol lmtp {
mail_plugins {
sieve = yes
notify = yes
push_notification = yes
}
postmaster_address = postmaster@mydomain.tld
}
##
## TLS Config
## Quelle: https://ssl-config.mozilla.org/#server=dovecot&version=2.3.9&config=intermediate&openssl=1.1.1d&guideline=5.4
##
ssl = required
ssl_server_cert_file = /etc/acme.sh/mydomain.tld/fullchain.pem
ssl_server_key_file = /etc/acme.sh/mydomain.tld/privkey.pem
ssl_server_dh_file = /etc/dovecot/dh4096.pem
ssl_cipher_list = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
###
### Dovecot services
################################
service imap-login {
inet_listener imap {
port = 143
}
}
service managesieve-login {
inet_listener sieve {
port = 4190
}
}
service lmtp {
unix_listener /var/spool/postfix/private/dovecot-lmtp {
mode = 0660
group = postfix
user = postfix
}
}
service auth {
### Auth socket für Postfix
unix_listener /var/spool/postfix/private/auth {
mode = 0660
user = postfix
group = postfix
}
### Auth socket für LMTP-Dienst
unix_listener auth-userdb {
mode = 0660
user = vmail
group = vmail
}
}
###
### SQL settings
###
sql_driver = mysql
mysql /var/run/mysqld/mysqld.sock {
user = vmail
password = mypassword
dbname = vmail
}
###
### Client authentication
#############################
auth_mechanisms = plain login
auth_username_format = %{user | lower }
passdb sql {
query = SELECT username AS user, domain, password FROM accounts WHERE username = '%{user | username | lower }' AND domain = '%{user | domain | lower}' and enabled = true;
}
userdb sql {
query = SELECT concat(quota, 'M') AS quota_storage_size FROM accounts WHERE username = '%{user | username | lower }' AND domain = '%{user | domain | lower}' AND sendonly = false;
iterate_query = SELECT username, domain FROM accounts where sendonly = false;
}
##
### Address tagging
###
recipient_delimiter = +
###
### Mail location
#######################
mail_uid = vmail
mail_gid = vmail
mail_privileged_group = vmail
mail_home = /var/vmail/mailboxes/%{user | domain }/%{user | username }
mail_driver = maildir
mail_path = ~/mail
mailbox_list_layout = fs
###
### Mailbox configuration
########################################
namespace inbox {
inbox = yes
mailbox Spam {
auto = subscribe
special_use = \Junk
}
mailbox Trash {
auto = subscribe
special_use = \Trash
}
mailbox Drafts {
auto = subscribe
special_use = \Drafts
}
mailbox Sent {
auto = subscribe
special_use = \Sent
}
}
###
### Mail plugins
############################
mail_plugins {
quota = yes
}
sieve_plugins {
sieve_imapsieve = yes
sieve_extprograms = yes
}
sieve_script spam-global {
type = before
path = /var/vmail/sieve/global/spam-global.sieve
}
sieve_script personal {
type = personal
path = /var/vmail/sieve/%{user | domain }/%{user | username }/scripts
active_path = /var/vmail/sieve/%{user | domain }/%{user | username }/active-script.sieve
}
# From Mailbox to Spam
mailbox Spam {
sieve_script spam {
type = before
cause = copy
path = /var/vmail/sieve/global/learn-spam.sieve
}
}
# From Spam to another folder (learn HAM)
imapsieve_from Spam {
sieve_script ham {
type = before
cause = copy
path = /var/vmail/sieve/global/learn-ham.sieve
}
}
# Sieve extensions only allowed in global context
sieve_global_extensions {
vnd.dovecot.pipe = yes
}
sieve_pipe_bin_dir = /usr/bin
###
### IMAP Quota
###########################
quota_exceeded_message = Benutzer %{user} hat das Speichervolumen ueberschritten. / User %{user} has exhausted allowed storage space.
quota "User quota" {
driver = count
}

Updates

2026-02-06: default_password_scheme in passdb Abschnitt hinzugefügt. Abschnitt “Änderung der Zugriffsrechte” hinzugefügt.
2025-11-26: user = vmail aus service lmtp entfernt, um lmtp(1301): Error: conn unix:/run/dovecot/anvil: net_connect_unix(/run/dovecot/anvil) failed: Permission denied zu vermeiden.

Spamhaus blockiert Mailserver trotz eigenen Resolvers

thomas.leister@mailbox.org (Thomas Leister) — Sat, 01 Nov 2025 10:06:44 +0100

Kürzlich hatte ich einen kuriosen Zwischenfall bei einem meiner Kunden: Der Mailserver, der nach meiner Mailserver-Anleitung aufgesetzt wurde, lehnte seit einiger Zeit immer wieder einmal E-Mails von außen ab. Zunächst konnte ich den Fehler nicht nachstellen, doch nach einigen Testmails gelang es mir schließlich, dem Problem auf die Spur zu kommen …

Als Antwort auf meine Testmail bekam ich schließlich eine E-Mail von meinem Mailer Daemon zurück mit:

user@domain.tld: host mail.domain.tld[xx.xx.xx.xx] refused to talk to me: 521 5.7.1 Service unavailable; client [xx.xx.xx.xx] blocked using zen.spamhaus.org

Merkwürdig. War mein eigener Mailserver auf den Spamhaus Zen Blockliste gelandet? Ein schneller Check auf https://check.spamhaus.org zeige zum Glück das Gegenteil. Doch warum wurde die E-Mail dann abgelehnt? Ein Blick in das mail.log offenbarte mehr Details:

Oct 25 12:50:54 sisyphos postfix/dnsblog[12662]: addr xxxx:xxxx:xxxx::xxxx listed by domain zen.spamhaus.org as 127.255.255.254
[...]
Oct 25 12:50:54 sisyphos postfix/dnsblog[12662]: addr xx.xx.xx.xx listed by domain zen.spamhaus.org as 127.255.255.254

Hier kann man erkennen, wie das Mailsystem die beiden Zustellversuche meines Mailservers (einmal IPv4, einmal IPv6) bewertet: Spamhaus liefert für beide Versuche eine Antwort 127.255.255.254 zurück - laut der Tabelle unter “What do the 127...* return codes mean in DNSBL?” steht das für einen Fehler:

127.255.255.254 Query via public/open resolver

Der Fehler ist mir nicht ganz unbekannt, weil viele meiner Leser ihre Mailserver vor vielen Jahren aufgesetzt haben, als offene Resolver für Spamhaus noch kein Problem waren. Doch seit einiger Zeit sperrt Spamhaus Mailserver aus, die über einen offenen DNS-Resolver auf die DNS-Blocklisten (und damit die Nameserver von Spamhaus) zugreifen. Die Lösung dafür ist ganz einfach: Mit einem lokalen, eigenen Resolver, z.B. via unbound, umgeht man das Problem.

Mein Kunde setzte auf fraglichem Mailserver aber bereits einen lokalen Resolver ein. Das konnte also nicht das Problem sein.

Dennoch: Tests via dig zeigten immer wieder (aber nicht immer!) an, dass ein Code 127.255.255.254 zurückgegeben wurde:

root@mail /etc/postfix # dig @127.0.0.1 135.72.1.5.zen.spamhaus.org
; <<>> DiG 9.11.3-1ubuntu1.18-Ubuntu <<>> @127.0.0.1 135.72.1.5.zen.spamhaus.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26448
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;135.72.1.5.zen.spamhaus.org. IN A
;; ANSWER SECTION:
135.72.1.5.zen.spamhaus.org. 1588 IN A 127.255.255.254
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Oct 25 13:30:31 CEST 2025
;; MSG SIZE rcvd: 74

Eigentlich sollte in diesem Fall ein NXDOMAIN zurückgegeben werden.

Schritt 1: Symptome lindern

Die Ursache für das Verhalten von Spamhaus war noch unklar. Also bemühte ich mich, die negativen Auswirkungen auf meinen Kunden erst einmal einzudämmen - schließlich war er durch den Fehler nur sporadisch erreichbar. Die zurückgegebene IP-Adresse 127.255.255.254 wurde durch Postfix nämlich als “blockieren - Spam!” interpretiert. In der alten Anleitung, auf der der Mailserver basierte, hatte ich nämlich nicht genau spezifiziert, welche Return Codes als Spam gewertet werden sollten. Das habe ich nachgeholt. Die Konfiguration sieht nun so aus:

### DNS blocklists
postscreen_dnsbl_threshold = 2
postscreen_dnsbl_sites = zen.spamhaus.org=127.0.0.[2..11]*2
postscreen_dnsbl_action = drop

Nun werden nur IP-Adressen endend auf 2-11 als Spamalarm gewertet. Andere Adressen lassen Postscreen kalt. Damit führt auch der “Open Resolver” Code nicht mehr zur Ablehnung eingehender E-Mails. Allerdings funktioniert der Zugriff auf die Spamhaus Zen Blockliste noch immer nicht zuverlässig. Die Maßnahme verhindert nur die durch den Fehler verursachten False Positives.

Schritt 2: Hilfe bei Spamhaus anfordern

Eine Anfrage bei Spamhaus zu dem Problem half nur bedingt. Auf die Frage, ob Spamhaus eine Liste mit offenen Resolvern pflege und darin vielleicht fälschlicherweise der Kundenserver stehe, hieß es:

The IPs are not listed in our mirrors but I would recommend using the IPv4 for queries. We are seeing abuse of our mirrors from IPv6 space of Hetzner in millions so some IPv6 queries might fail.

Das hat mich dann eine Idee gebracht …

Schritt 3: Spamhaus nur via IPv4 ansprechen

Schnell kam der Verdacht auf, dass das zufällig erscheinende Verhalten evtl. mit einem Unterschied zwischen IPv4 und IPv6-basierten Anfragen zu tun haben könnte. Das bestätigte sich sofort, als ich den lokalen Unbound-Resolver auf “IPv4 only” Betrieb umgestellt hatte. Folgende Konfiguration in /etc/unbound/unbound.conf.d/ipv4-only.conf:

server:
do-ip4: yes
do-ip6: no

… führt dazu, dass Unbound bei der Kontaktaufnahme zu anderen Nameservern (z.B. den Servern von Spamhaus) kein IPv6 mehr verwendet. DNS-Antworten können trotzdem noch v6-Adressen enthalten - diese bleiben unberührt. Funktional bleibt der Mailserver also unverändert - aber die Spamhaus DNSBL funktionierte mit diesem Kniff wieder wunderbar.

War das schon alles?

Bei meiner Recherche bin ich außerdem auf einen zweiten Punkt gestoßen, der für das Problem gesorgt haben könnte. Denn DNS-Resolver, die mit Spamhaus genutzt werden, müssen laut diesem Artikel einen Reverse DNS Eintrag vorweisen können. Fehlt dieser, kann dies ebenfalls Probleme bei der Nutzung der Spamhaus Zen Blockliste verursachen. Es ist also darauf zu achten, dass sowohl die IPv4 Adresse als auch die IPv6 Adresse einen gültigen Reverse DNS Eintrag haben.

Alternative Lösung mit dem Spamhaus DQS

Statt des DNSBL hätte ich meinen Kunden auch auf den Spamhaus DQS Service umstellen können. Mit dem Service habe ich allerdings noch keine Erfahrung gesammelt. Zudem bedingt die Nutzung eine Registrierung. Die weitere Nutzung der öffentlichen DNSBL lag daher auf der Hand.

Incus Container zwischen Hosts kopieren oder verschieben

thomas.leister@mailbox.org (Thomas Leister) — Sun, 19 Oct 2025 14:27:54 +0200

Im folgenden erkläre ich kurz die Übertragung von Incus-Container zwischen zwei Incus-Hosts, die nicht in einem gemeinsamen Cluster hängen. Beide Hosts sind in meinem Fall mit ZFS-basiertem Containerstorage ausgerüstet. Siehe auch: Incus mit ZFS in einer VM betreiben und Container auf neuen Storagepool verschieben

API öffnen

Wenn ein Container zwischen zwei Hosts verschoben werden soll, muss zuerst ein Übertragungsweg zwischen den beiden Incus-Hosts geschaffen werden. Dazu wird auf dem Quellhost die API am Netzwerkinterface verfügbar gemacht:

incus config set core.https_address [2001:db8::1]:8443

Die IPv6-Adresse in eckigen Klammern muss selbstverständlich durch die IP-Adresse eures eigenen Interfaces ersetzt werden. Bei einer IPv4-Adresse wird auf die Klammern verzichtet.

Als nächstes wird ein Trust Token auf dem Quellserver erzeugt:

incus config trust add sourcehost

Auf dem Zielserver wird der Quellserver hinzugefügt:

incus remote add sourcehost 2001:db8::1

Dabei muss am Ende der Trust Token eingegeben werden, der zuvor vom Quellserver ausgegeben wurde. Sobald in der Konsole

Client certificate now trusted by server: sourcehost

erscheint, kann eine erste Übertragung des Containers vom Quellserver zum Zielserver stattfinden.

Daten übertragen

Das Root Filesystem des Containers kann auf zwei Arten und Weisen übertragen werden:

a) An einem Stück mit einer Downtime, die so lange dauert, wie die Datenübertragung. Empfohlen für kleine Container.
b) In mehreren Schritten über einen zweiten, inkrementellen Sync. Mit wenigen Sekunden bis Minuten Downtime. Empfohlen vor allem für größere Container mit 100+ GB. Funktioniert nur mit Dateisystemen wie ZFS, die Snapshots unterstützen.

a) Einfache Übertragung für kleinere Container

# (auf dem Quellserver)
incus stop mycontainer
# (auf dem Zielserver)
incus copy sourcehost:mycontainer mycontainer --stateless

Oder b): Inkrementelle Übertragung

Bei der inkrementellen Übertragung wird zuerst im Hintergrund der aktuelle Stand des Container übertragen. Die Anteile, die während der Übertragung verändert wurden (weil der Container noch in Betrieb war), werden in einem zweiten Schritt nachgeliefert. Dieser zweite Sync läuft dann aber wesentlich schneller, weil er nur ein Delta Überträgt und nicht alle Daten nochmal.

Snapshot auf dem Quellserver erstellen:

incus snapshot create mycontainer

(Der Container bleibt in Betrieb und wird noch nicht gestoppt)

Initiale Übertragung auf dem Zielserver starten:

incus copy sourcehost:mycontainer mycontainer --stateless

Nach der ersten Übertragung wird der Quellcontainer beendet und ein zweiter, finaler Sync angestoßen:

# (auf dem Quellserver)
incus stop mycontainer
incus snapshot create mycontainer
# (auf dem Zielserver)
incus copy sourcehost:mycontainer mycontainer --refresh

Schließlich wird der Container auf dem Zielserver gestartet:

incus config unset mycontainer volatile.apply_template
incus start mycontainer

API schließen

Zum Schluss kann die API auf dem Quellserver wieder dicht gemacht werden, falls sie nicht für andere Zwecke verwendet werden soll:

incus config unset core.https_address

Incus mit ZFS in einer VM betreiben und Container auf neuen Storagepool verschieben

thomas.leister@mailbox.org (Thomas Leister) — Sun, 19 Oct 2025 12:12:10 +0200

Seit vielen Jahren setze ich beim Hosting meiner Services auf das Virtualisierungs- und Containermanagement-Tool “Incus” (vorher “LXD”). Incus läuft dabei in einer virtuellen Maschine und hilft mir, eine Separierung auf Applikationsebene herzustellen. So gibt es beispielsweise einen Incus-Container für trashserver.net, einen weiteren für metalhead.club usw. Die Root-Dateisysteme der einzelnen Container befinden sich dabei in einem ZFS-Dateisystem. So kann ich platzsparende Snapshots von meinen Containern vor kritischen Wartungsaktionen anlegen, z.B. vor Updates oder Betriebssystemupgrades.

Da ich den zugrundeliegenden Speicher kürzlich erneuert habe, will ich hier mein Storage-Setup kurz vorstellen und für mich (aber auch euch ;-) ) dokumentieren, auf was ich geachtet habe und wie ich meine Container auf den neuen Storage umgezogen habe.

Auf Hypervisor-Level (also auf dem physischen Server) wird der Speicher für meine Container in Form von LVM Volumes bereitgestellt. Das erlaubt es mir, den großen Speicher in vielen einzelnen Volumes auch für andere VMs anzubieten und je nach Ressourcenbedarf zu dimensionieren.

Ein LVM Volume (Blockdevice) wird dann über libvirt/QEMU und den virtio-blk Treiber an die VM durchgereicht. Dabei nutze ich in libvirt die folgenden Parameter für den Speicher:

Treiber: virt-blk
Cache Modus: none (cache macht schon zfs)
io = native (meistens besser als io=threads)
discard = unmap (für Trim-Support)
serial = megastor

Besonders hervorheben will ich an dieser Stelle die serial Einstellung, die es erlaubt, für das durchgereichte Blockdevice eine Seriennummer / eine ID / einen eindeutigen Namen anzugeben. Bindet man mehrere Speichergeräte in seine VM an, lassen sich die einzelnen Speicher so wieder zweifelsfrei identifizieren. Ein megastor benanntes Gerät erscheint in der VM dann z.B. als /dev/disk/by-id/virtio-megastor. Das ist vor allem hilfreich, wenn …

… man nicht mehr sicher ist, was eigentlich zwischen /dev/vdb und /dev/vdd steckt und welcher Storage gleich nochmal welcher ist?
… oder man /dev/vdc entfernen will, aber man befürchten muss, dass dann beim nächsten Reboot /dev/vdd nachrückt und diesen Platz einnimmt. Dann wäre das Chaos perfekt.

Denn: Device-Namen für Storage-Devices sind unter Linux nicht “stabil”! Nur Partitions-UUIDs sind es (oder alternativ Disk-IDs!).

In der VM wiederum wird das Blockdevice genutzt, um damit einen einfachen ZFS-Pool zu erzeugen, z.B. via:

zpool create -o ashift=12 megastor /dev/disk/by-id/virtio-megastor

Der ZFS Pool wird auch in Incus registriert, damit er mit den Containern genutzt werden kann:

incus storage create megastor zfs source=megastor --description="megastor storage for containers"

Trim Support

Vor einiger Zeit unterstützte nur der virtio-scsi Treiber trim, um freie Speicherbereiche auch auf der SSD passend zu markieren und freizugeben. Regelmäßiges “trimmen” führt zu einer wesentlich besseren Performance. Seit einigen QEMU Versionen beherrscht aber auch der schlankere “virtio-blk” Treiber Trimming.

ZFS führt über das Paket zfsutils-linux übrigens regelmäßig selbst ein Trim-Cronjob (/etc/cron.d/zfsutils-linux) aus - es ist also nicht nötig, selbst ein fstrim auszuführen.

Allerdings ist darauf zu achten, dass - wie oben erwähnt - discard=unmap für das QEMU Speicherberät definiert ist. Und auch auf Hypervisor-Level muss in meinem Fall wegen der LUKS-Verschlüsselung in /etc/crypttab ein “discard” Parameter eingetragen sein. Sonst wird das Trimming nicht bis in die unseren Storage-Layer durchgereicht. Beispiel:

luks-d429b69b-1c1a-234a-8bcf-64232e83f156 UUID=d429b69b-1c1a-234a-8bcf-64232e83f156 /var/lib/megastor.key discard

Außerdem sollte auch LVM passend konfiguriert sein: vim /etc/lvm/lvm.conf:

issue_discards = 1

Bestehende Incus VMs auf neuen Storage verschieben

Da ich - wie zu Beginn erwähnt - neue SSDs in dem System verbaut und dementsprechend neue ZFS Pools eingerichtet habe, sollten nun auch die Incus Container in den neuen “megastor” Pool verschoben werden. Dafür gibt es mehrere Methoden …

Der einfache Weg mit einigen Minuten Downtime

Das geht mit Incus so:

incus stop mycontainer
incus move mycontainer --storage megastor

Vor der Übertragung wird der Container gestoppt, was je nach Größe des Containers und Performance des Storage eine gewisse Weile dauert und somit Downtime verursacht. Dafür ist die Methode weniger komplex. Sie lohnt sich bei eher kleinen Containern mit etwa 50 - 100 GB Größe.

Mit inkrementeller Übertragung - aber kurzer Downtime

Wer Downtime möglichst vermeiden will, kann anders vorgehen:

Snapshot vom Quellcontainer während des laufenden Betriebs erzeugen
Snapshot im Hintergrund zum Ziel kopieren
Quellcontainer stoppen (Beginn Downtime)
Differenz seit letzter Übertragung übertragen (idR. nur wenige MG bis GB)
Alten Container entfernen, neuen Container umbenennen
Neuen Container starten (Ende Downtime)

Die Downtime reduziert sich auf ein Minimum. Das grundsätzliche Vorgehen habe ich schon einmal in meinem Beitrag “Move a Mastodon instance with less than 3 minutes downtime (LXD/ZFS-based)” beschrieben und habe gewissermaßen um LXD herum gearbeitet. Dasselbe funktioniert aber auch mit Incus-Bordmitteln und kann auf die Übertragung eines Containers von einem Storage auf den anderen angewendet werden (nicht nur auf die Übertragung zwischen zwei Hosts!).

# 1. Snapshot im laufenden Betrieb erstellen
incus snapshot create mycontainer
# 2. Snapshot auf neuen Storage "megastor" übertragen
incus copy mycontainer new-mycontainer --storage megastor
# 3. Container stoppen und weiteren Snapshot erzeugen
incus stop mycontainer
incus snapshot create mycontainer
# 4. Änderungen seit Beginn der ersten Übertragung nun auch übertragen
incus copy mycontainer new-mycontainer --storage megastor --refresh
# 5. Alten Container löschen, neuen Container umbenennen
incus delete mycontainer
incus move new-mycontainer mycontainer
# 6. Neuen Container starten
incus config unset mycontainer volatile.apply_template
incus start mycontainer

Das incus config unset... sorgt dafür, dass der neue Container die alten MAC-Adressen, IPs etc behält und keine neuen Adressen zugeteilt bekommt.

Wer will, kann übrigens zwischen Schritt 2 und 3 auch weitere “snapshot - copy” Folgen zwischenschieben:

incus snapshot create mycontainer
incus copy mycontainer new-mycontainer --storage megastor --refresh

Das ist vor allem dann sinnvoll, wenn nach der ersten Übertragung viel Zeit vergangen ist. Hat sich während dieser Zeit viel im Container geändert, fällt auch der finale Sync bedeutend länger aus und sorgt für eine längere Downtime. Dem kann man entgegenwirken, indem man sich in mehreren “snapshot - copy” Schritten annähert. Wichtig ist nur, dass nach dem ersten copy Befehl das --refresh Flag nicht vergessen wird.

Hetzner S3 Bucket mit Restic und Rclone sichern

thomas.leister@mailbox.org (Thomas Leister) — Sun, 28 Sep 2025 15:39:33 +0200

Kürzlich habe ich für einen Kunden den S3-Storage für eine Mastodon Instanz von Minio S3 auf ein extern gehostetes Hetzner S3 umgestellt. Das bringt auch eine Änderung bei der Datensicherung mit sich: Statt einfach nur das lokale Minio-Dateisystem zu sichern, muss sich für das Hetzner S3 Bucket eine andere Lösung überlegt werden. Im Folgenden will ich meine Lösung dafür aufzeigen.

Ein S3 Bucket in die Restic-Sicherung einbinden? Nicht so einfach!

Die Sicherung des Minio-Dateisystems war einfach und bequem. Restic musste an dieser Stelle nicht anders eingestellt werden, als für die übliche Datensicherung auf dem Linux-Server. Da Minio nicht mit einer Datenbank arbeitet, sondern einzig und allein mit dem Dateisystem, muss bei der Datensicherung über Restic nichts besonderes beachtet werden.

Da die Medien für die fragliche Mastodon Instanz nun aber nicht mehr lokal gehostet, sondern über ein Hetzner S3 Bucket bereitgestellt werden, stellt sich die Frage, wie mit dem Restic-basierten Backupmechanismus damit umgegangen werden soll. Eine Lösung könnte sein, das Produktiv-Bucket einfach in einem readonly-Modus zu einem weiteren Bucket zu kopieren und diese Buckets beispielsweise täglich zu synchronisieren. Allerdings hätte man damit keine inkrementellen, täglichen Sicherungen und kann höchstens auf den Stand des vorherigen Tages zurückspringen. Zudem arbeitet diese Lösung an Restic vorbei - ich hätte gerne alle Daten an einem Ort.

Das S3 Bucket mit rclone als virtuelles Dateisystem einbinden

Eine zweite Lösung kann sein, das Hetzner S3 Bucket mit einem Tool wie z.B. rclone lokal als virtuelles Filesystem zu mounten und dieses dann von dort zu sichern. Das mag umständlich und nicht sehr schnell sein, sorgt aber dafür, dass ich sämtliche Mediendateien in den gewohnten Restic Vorhaltezeiten gesichert habe und entsprechend auch wieder einfach herstellen kann, wenn es nötig sein sollte.

Mein Backup-Script sieht nun in etwa so aus:

#!/bin/bash

### Restic Passwort und Speicherort einlesen
source /opt/backup/resticenv.sh

### Mount S3 bucket
rclone mount \
 --daemon \
 --read-only \
 --vfs-cache-mode full \
 --vfs-cache-max-size 20G \
 --vfs-cache-max-age 24h \
 --dir-cache-time 72h \
 --poll-interval 15s \
 --checkers 128 \
 --transfers 64 \
 --multi-thread-streams 4 \
 --timeout 1m \
 --retries 10 \
 --use-mmap \
 --s3-chunk-size 64M \
 hetzner-s3:mastodon-media /mnt/hetzner-s3/mastodon-media

### Restic ausführen
restic backup \
 --exclude-file /opt/backup/exclude.list \
 /home \
 /etc \
 /root \
 /mnt/hetzner-s3/mastodon-media/accounts \
 /mnt/hetzner-s3/mastodon-media/custom_emojis \
 /mnt/hetzner-s3/mastodon-media/media_attachments \
 /mnt/hetzner-s3/mastodon-media/site_uploads
# /mnt/hetzner-s3/mastodon-media/cache/accounts \
# /mnt/hetzner-s3/mastodon-media/cache/custom_emojis

restic forget --prune \
 --keep-last 7 \
 --keep-daily 14 \
 --keep-weekly 8 \
 --keep-monthly 4

restic check

# Unmount S3 bucket
fusermount -u /mnt/hetzner-s3/mastodon-media

Das rclone Kommando zu Beginn des Scripts mountet das S3 bucket als virtuelles Dateisystem unter /mnt/hetzner-s3/mastodon-media. Das restic backup Kommando kann sich in diesem Verzeichnis bedienen und die Inhalte sichern. Weitere Einstellungen:

--daemon sorgt dafür, dass rclone im Hintergrund läuft. Andernfalls würde das Script blockieren.
--read-only stellt sicher, dass das Mountpoint readonly ist, um das eingehängt S3 Bucket nicht zu verändern.
--vfs-cache-max-size 20G erlaubt rclone, bis zu 20 GB als Cache zu nutzen. Ich hoffe auf eine schnellere Ausführung.
--checkers 128 erlaubt rclone bis zu 128 “checker” Instanzen. Das sind die Teile von rclone, die das Bucket nach Dateien durchsuchen. Die Anpassung hat in meinem Fall dafür gesorgt, dass die Sicherung durch restic deutlich schneller funktioniert hat als vorher. Allerdings sollte geprüft werden, ob so nicht die maximale Anzahl von Anfragen / Verbindungen an das Bucket überschritten werden kann, wenn nebenher auch noch andere Prozesse auf die Daten zugreifen.

Die beiden letzten Pfade unter cache/ habe ich vorerst ausgeklammert. Dort speichert Mastodon gecachte Versionen von Medien fremder Instanzen. Diese sollten nach dem Einspielen eines Backups eigentlich von Mastodon selbst wieder bei den fremden Instanzen angefragt werden, wenn sie fehlen sollten. Ich sichere sie deshalb aktuell nicht mit. Allerdings bleibt das noch ein Punkt, der noch weiter untersucht werden muss - denn in der Vergangenheit hat das erneute Herunterladen schon einmal Schwierigkeiten gemacht und nicht wie gedacht funktioniert. Insbesondere fehlende Avatare unter cache/accounts/ wären ärgerlich. Auf der anderen Seite ist die Datenmenge besonders groß und es tummeln sich u.U. hunderttausende kleinste Dateien in diesem Verzeichnis. Das ist für den Backupprozess besonders belastend und führt dazu, dass Backups sehr sehr lange dauern können.

Mit fusermount wird das S3 Bucket nach dem Backup schließlich wieder ausgehängt.

Vorsicht mit alten Softwareversionen!

Ein Hinweis noch zu verwendeten Softwareversionen: Ich hatte anfangs während des Restic-Backups Fehlermeldungen wie

error: NodeFromFileInfo: xattr.list /mnt/hetzner-s3/7de24bcbedb9b634.jpg: input/output error

Die Lösung für meine Probleme bestand darin, sowohl Restic als auch Rclone auf aktuellere Versionen zu aktualisieren, welche von meiner Debian-Distribution noch nicht angeboten wurden. Siehe auch Thread im Restic Forum: “Creating a Restic backup of a S3 bucket”. Für restic Version 0.18.1 und Version 1.71.1 kann ich aber bestätigen, dass die Sicherungen auf die oben beschriebene Art und Weise funktionieren.

Seht meine Konfiguration als experimentell an - ich bin selbst noch nicht sicher, wo / ob sich hier u.U. noch etwas optimieren lässt. Das Backup funktioniert in einer akzeptablen Zeit - aber das Hereinnehmen von cache/ bringt den Mechanismus wegen der extrem vielen Dateien ans Limit. Es kann dann durchaus länger als 24 Stunden dauern, bis alle Dateien gesichert sind.

Mastodon S3 Storage von self-hosted Minio zu Hetzner S3 übertragen

thomas.leister@mailbox.org (Thomas Leister) — Wed, 24 Sep 2025 17:32:04 +0200

Im Auftrag eines Kunden hatte ich kürzlich die Aufgabe, ein S3 Bucket für eine Mastodon-Instanz von einer selbst gehosteten Minio-Instanz zu Hetzner S3 zu übertragen. Das Vorgehen und meine genutzten Konfigurationen will ich hier erklären.

Die Mastodon-Instanz des Kunden wurde bisher durch eine Minio-Instanz auf demselben Server mit Medien und Mediencache versorgt. Allerdings wuchs der Mediencache mit zunehmender Vernetzung der Mastodon-Instanz immer weiter an. Selbst durch eine Reduzierung der Cache-Haltedauer von wenigen Tagen waren die Kosten für den S3-Speicher zu hoch. Denn dieser befand sich auf einem leistungsstarken, aber verhältnismäßig teuren externen Volume eines Hetzner Cloudservers.

Ende 2024 führte Hetzner den Hetzner S3 Speicher in sein Produktportfolio ein - somit eröffnete sich eine attraktive Alternative zur Minio-Instanz. Eine Alternative, die vor allem durch geringe Kosten glänzen kann. Die Kosten für ein 300 GB Volume beliefen sich auf knapp 16 € / Monat. Nicht sehr viel für ein Business - aber sehr wohl für eine kleine, spendenfinanzierte Mastodon-Instanz. Der Preis für 1000 GB (!) Hetzner S3 Speicher liegt im Vergleich nur bei knapp 6 € / Monat. Die Umstellung war also schnell beschlossen.

Schritt 1: Parallelbetrieb zweier Buckets

Um den Umstieg auf den neuen Speicher für die Nutzer so angenehm wie möglich zu gestalten und die Downtime gering zu halten, entschloss ich mich dazu, beide Buckets für die Zeit der Datenmigration parallel laufen zu lassen.

Altes Bucket “minio”: Liefert die bisher gespeicherten Mediendateien aus (readonly)
Neues Bucket “hetzner-s3”: Nimmt neue Mediendateien entgegen, speichert diese und liefert diese aus

Der Vorgeschaltete Nginx-Proxy wurde so konfiguriert, dass bei einer Dateianfrage zuerst das neue Bucket befragt wurde. Konnte die angefragte Datei dort nicht gefunden werden, wurde das alte S3 Bucket befragt.

Proxykonfiguration vorher:

upstream minio {
 server 127.0.0.1:9000;
}

server {
 [...]

 location / {
 proxy_set_header Host 'mastodon-media.s3.domain.tld';
 proxy_set_header Connection '';
 proxy_set_header Authorization '';
 proxy_hide_header Set-Cookie;
 proxy_hide_header 'Access-Control-Allow-Origin';
 proxy_hide_header 'Access-Control-Allow-Methods';
 proxy_hide_header 'Access-Control-Allow-Headers';
 proxy_hide_header x-amz-id-2;
 proxy_hide_header x-amz-request-id;
 proxy_hide_header x-amz-meta-server-side-encryption;
 proxy_hide_header x-amz-server-side-encryption;
 proxy_hide_header x-amz-bucket-region;
 proxy_hide_header x-amzn-requestid;
 proxy_ignore_headers Set-Cookie;

 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;

 proxy_connect_timeout 300;
 proxy_http_version 1.1;
 proxy_set_header Connection "";
 chunked_transfer_encoding off;

 add_header 'Access-Control-Allow-Origin' '*';
 add_header X-Cache-Status $upstream_cache_status;
 add_header X-Content-Type-Options nosniff;
 add_header Content-Security-Policy "default-src 'none'; form-action 'none'";

 proxy_pass https://minio;
 }
}

Proxykonfiguration nachher - mit Parallelbetreib beider Buckets (Fallback auf altes Bucket):

upstream hetzner {
 server mastodon-media.nbg1.your-objectstorage.com;
}

upstream minio {
 server 127.0.0.1:9000;
}

server {
 [...]

 resolver 9.9.9.9;

 location / {
 proxy_set_header Host 'mastodon-media.nbg1.your-objectstorage.com';
 proxy_set_header Connection '';
 proxy_set_header Authorization '';
 proxy_hide_header Set-Cookie;
 proxy_hide_header 'Access-Control-Allow-Origin';
 proxy_hide_header 'Access-Control-Allow-Methods';
 proxy_hide_header 'Access-Control-Allow-Headers';
 proxy_hide_header x-amz-id-2;
 proxy_hide_header x-amz-request-id;
 proxy_hide_header x-amz-meta-server-side-encryption;
 proxy_hide_header x-amz-server-side-encryption;
 proxy_hide_header x-amz-bucket-region;
 proxy_hide_header x-amzn-requestid;
 proxy_ignore_headers Set-Cookie;

 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;

 proxy_connect_timeout 300;
 # Default is HTTP/1, keepalive is only enabled in HTTP/1.1
 proxy_http_version 1.1;
 proxy_set_header Connection "";
 chunked_transfer_encoding off;

 add_header 'Access-Control-Allow-Origin' '*';
 add_header X-Cache-Status $upstream_cache_status;
 add_header X-Content-Type-Options nosniff;
 add_header Content-Security-Policy "default-src 'none'; form-action 'none'";

 proxy_pass https://hetzner; # This uses the upstream directive definition to load balance

 # Fallback to oldbucket
 proxy_intercept_errors on;
 error_page 404 403 = @oldbucket;
 }

 location @oldbucket {
 proxy_set_header Host 'mastodon-media.s3.domain.tld';
 proxy_set_header Connection '';
 proxy_set_header Authorization '';
 proxy_hide_header Set-Cookie;
 proxy_hide_header 'Access-Control-Allow-Origin';
 proxy_hide_header 'Access-Control-Allow-Methods';
 proxy_hide_header 'Access-Control-Allow-Headers';
 proxy_hide_header x-amz-id-2;
 proxy_hide_header x-amz-request-id;
 proxy_hide_header x-amz-meta-server-side-encryption;
 proxy_hide_header x-amz-server-side-encryption;
 proxy_hide_header x-amz-bucket-region;
 proxy_hide_header x-amzn-requestid;
 proxy_ignore_headers Set-Cookie;

 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;

 proxy_connect_timeout 300;
 proxy_http_version 1.1;
 proxy_set_header Connection "";
 chunked_transfer_encoding off;

 add_header Cache-Control public;
 add_header 'Access-Control-Allow-Origin' '*';
 add_header X-Cache-Status $upstream_cache_status;
 add_header X-Content-Type-Options nosniff;
 add_header Content-Security-Policy "default-src 'none'; form-action 'none'";

 proxy_pass http://minio;
 }
}

Maßgeblich sind hier der neue “location” Block “@oldbucket” und der verweis darauf, falls Dateien um neuen Bucket nicht gefunden werden können:

# Fallback to oldbucket
proxy_intercept_errors on;
error_page 404 403 = @oldbucket;

Wichtig ist an der Stelle, nicht nur 404-Fehler abzufangen, sondern auch 403-Fehler (“forbidden”). Der Hetzner S3 Storage reagiert offenbar mit diesem Fehlercode, wenn eine Ressource angefragt wird, deren Elternverzeichnisse (noch) nicht existieren.

Schritt 2: Speichern neuer Medien in dem neuen Bucket

Bis hierher dürften die Nutzer der Mastodon-Instanz kaum etwas mitbekommen haben. Die Proxy-Änderung ist in Sekundenbruchteilen aktiv und ist für den User völlig transparent. Im Folgenden kommt es allerdings zu einer kurzen, mehrsekündigen Downtime, denn die Konfiguration von Mastodon wird angepasst und daraufhin müssen alle Mastodon Services neu gestartet werden.

Für das neue Bucket wurden beispielhaft folgende Einstellungen in der .env.production von Mastodon getroffen:

S3_ENABLED=true
S3_BUCKET=mastodon-media
AWS_ACCESS_KEY_ID=<myaccessid>
AWS_SECRET_ACCESS_KEY=<myaccesskey>
S3_ALIAS_HOST=media.domain.tld
S3_REGION=nbg1
S3_PROTOCOL=https
S3_HOSTNAME=media.domain.tld
S3_ENDPOINT=https://nbg1.your-objectstorage.com
S3_SIGNATURE_VERSION=v4

Durch einen Neustart der Mastodon-Dienste werden die Änderungen aktiv. Neu eintreffende Mediendateien werden nun nun an ausschließlich in dem neuen S3-Bucket abgelegt:

cd /etc/systemd/system
systemctl restart mastodon-*

Nach wenigen Sekunden steht Mastodon wieder bereit.

Schritt 3: Alte Daten zu neuem Bucket migrieren

Die Kuh ist vom Eis - der kritische Teil ist erledigt. Nun können ganz entspannt die alten Daten ebenfalls in das neue Bucket transportiert werden. Dazu nutze ich das Tool “rclone”, mit dem sich zwei S3-Buckets sehr einfach miteinander synchronisieren lassen. Dazu werden für die beiden S3-Provider zunächst Konfigurationen unter ~/.config/rclone/rclone.conf anlegegt. Hier wieder exemplarisch:

[hetzner-s3]
type = s3
provider = Other
access_key_id = <accessid>
secret_access_key = <accesskey>
endpoint = nbg1.your-objectstorage.com
acl = public-read
region = nbg1

[minio-s3]
type = s3
provider = Minio
access_key_id = <accessid>
secret_access_key = <accesskey>
endpoint = s3.domain.tld
acl = public-read
region = server1

Endpoint, Region und Access-ID sowie Access-Key müssen natürlich auf das jeweilige Bucket angepasst werden. Wichtig ist noch die Einstellung acl = public-read, die dafür sorgt, dass übertragene Dateien die korrekten Berechtigungen tragen. Wird die Einstellung nicht korrekt gesetzt, sind die Dateien u.U. nicht öffentlich lesbar und der Medienspeicher kann nicht im Sinne von Mastodon verwendet werden.

Nun folgt eine Reihe von rclone-Kommandos, mit denen die Mediendateien vom alten minio-s3 zum neuen hetzner-s3 Speicher umgezogen werden. Zu beachten ist, dass hier das copy Subcommand von rclone verwendet wird. Dieses synchronisiert keine Löschungen, sondern transportiert nur nicht-existierende Dateien von A nach B. Anders als sync! Dieses würde inzwischen neu eingetroffene Dateien im neuen Bucket löschen. Es ist also Vorsicht geboten. copy ist das richtige Kommando für unseren Zweck.

Die wichtigsten Dateien zuerst:

rclone copy --progress --transfers=8 minio-s3:mastodon-media/custom_emojis/ hetzner-s3:mastodon-media/custom_emojis/
rclone copy --progress --transfers=8 minio-s3:mastodon-media/accounts/ hetzner-s3:mastodon-media/accounts/
rclone copy --progress --transfers=8 minio-s3:mastodon-media/site_uploads/ hetzner-s3:mastodon-media/site_uploads/
rclone copy --progress --transfers=8 minio-s3:mastodon-media/media_attachments/ hetzner-s3:mastodon-media/media_attachments/
rclone copy --progress --transfers=8 minio-s3:mastodon-media/imports/ hetzner-s3:mastodon-media/imports/
rclone copy --progress --transfers=8 minio-s3:mastodon-media/cache/accounts/ hetzner-s3:mastodon-media/cache/accounts/
rclone copy --progress --transfers=8 minio-s3:mastodon-media/cache/custom_emojis/ hetzner-s3:mastodon-media/cache/custom_emojis/

Danach folgen die weniger wichtigen Mediendateien. Dabei handelt es sich nur um zwischengespeicherte Medien und Vorschaubilder für Webseiten. Wer Zeit und Traffic sparen will, kann diese auch weglassen (oder die Vorhaltezeit für diese Medien vorab in Mastodon auf wenige Tage reduzieren - dann fällt die zu übertragende Datenmenge deutlich kleiner aus!).

rclone copy --progress --transfers=8 minio-s3:mastodon-media/cache/preview_cards/ hetzner-s3:mastodon-media/cache/preview_cards/
rclone copy --progress --transfers=8 minio-s3:mastodon-media/cache/media_attachments/ hetzner-s3:mastodon-media/cache/media_attachments/

Dieser Vorgang kann durchaus einen halben Tag dauern - je nach Leistung der beteiligten Server und der Größe des Buckets.

Schritt 4: Altes Bucket abklemmen

Sobald alle Daten übertragen sind, empfiehlt es sich, das alte Bucket noch eine Weile zu behalten, falls Daten nicht korrekt übertragen wurden. Man kann das alte Bucket allerdings schon einmal testhalber vom Proxy abklemmen und prüfen, ob denn die Mastodon-Instanz korrekt ohne das alte Bucket läuft. Dazu wird der @oldbucket location-Block entfernt sowie die folgenden Zeilen auskommentiert (oder entfernt):

#upstream minio {
# server 127.0.0.1:9000;
#}

[...]

# Fallback to oldbucket
#proxy_intercept_errors on;
#error_page 404 403 = @oldbucket;

Nach einem systemctl reload nginx wird nur noch das neue Bucket genutzt und die Funktion der Website lässt sich überprüfen. Nicht vergessen: Für ernstzunehmende Testa auch einmal den Browsercache leeren!

Läuft auch nach ein paar Tagen noch alles prima, kann das alte Bucket gelöscht werden. Fertig!

Automatischer Dark Mode für Drawio Diagramme mittels CSS Filter

thomas.leister@mailbox.org (Thomas Leister) — Fri, 01 Aug 2025 06:05:59 +0200

In meinem neuesten Blogpost “Nginx HTTP/3 Proxyserver zeigt Inhalte vom falschen Virtual Host” habe ich ein Diagramm von Diagrams.net / Drawio eingebunden, das eine SVG-Datei ist.

Wenn man sein Diagramm aus Draw.io exportiert, kann man wählen, ob man für die exportierte Grafik ein helles oder ein dunkles Farbthema anwenden will. Ich wähle hier normalerweise das helle, damit sich das Diagramm gut in das helle Default-Theme von thomas-leister.de einfügt. Aber wie gehe ich damit in der dunklen Variante meines Blogs um? Benutzer sehen automatisch das dunkle Theme, wenn sie ihr Betriebssystem entsprechend eingestellt haben. Ich habe mich gefragt, ob es nicht einen einfachen Weg gibt, um die hellen SVG Grafiken bei Bedarf in dunkle Varianten umzuwandeln. Schließlich kennt CSS ja mittlerweile filter, oder?

Zum Glück habe ich ziemlich schnell eine einfache Lösung für das Problem finden können: “One line - Dark Mode using CSS”. Und das ist der Trick, den ich gefunden habe:

filter: invert(1) hue-rotate(180deg);

Diese CSS-Zeile invertiert zunächst alle Farben (also von hell nach dunkel und umgekehrt). Dabei wird schwarz in weiß umgewandelt (und umgekehrt), aber Farben werden auch umgekehrt. Das ist nicht beabsichtigt. Deshalb werden über ein hue-rotate Farbige Inhalte wieder zurückkonvertiert.

In meinem CSS Stylesheet meines Blogs habe ich folgendes implementiert:

@media (prefers-color-scheme: dark) {
 /*
 * Invert colors for SVG diagrams
 */
 figure.diagram img {
 filter: invert(1) hue-rotate(180deg);
 }
}

Von der Umwandlung sind nur Grafiken betroffen, die sich in einem <figure> HTML element der Klasse diagram befinden - und nur dann, wenn der Benutzer ein dunkles Theme in seinen Betriebssystemeinstellungen gewählt hat.

Wenn ich nun in einem Blogeintrag eine SVG-Zeichnung einbinden will, mache ich das über den folgenden Shortcode:

{{< figure src="images/my-drawing.drawio.svg" caption="My description" class="diagram" >}}

Und kann das Ergebnis aussehen (oben im Dark Mode - unten im Light Mode):

Nginx HTTP/3 Proxyserver zeigt Inhalte vom falschen Virtual Host

thomas.leister@mailbox.org (Thomas Leister) — Wed, 30 Jul 2025 17:38:27 +0200

Ende Mai 2025 habe ich den metalhead.club Song über eine Faircamp-Website unter music.metalhead.club veröffentlicht. Doch nicht alle Nutzer konnten meinen Links auf die Faircamp-Seite problemlos folgen. In wenigen Einzelfällen berichteten mir User von mindestens einem der folgenden Fehler:

Wenn Nutzer die Albumseite aufriefen: Fehler 404 - not found
Wenn Nutzer die Hauptseite aufriefen: Der watch.metalhead.club Globus wurde angezeigt

Nach einigen Versuchen konnte ich den Fehler sporadisch selbst reproduzieren. In den Access-Logs des Nginx-Proxys ist mir dabei aufgefallen, dass alle fehlerhaften Anfragen mit HTTP/3 gestellt wurden. Das war mein erster Anknüpfungspunkt.

Da der Anteil der HTTP/3-kompatiblen Webbrowser stetig steigt, hatte ich mich einige Monate zuvor nämlich entschlossen, auf dem Server eine sehr aktuelle Nginx-Version mit aktiviertem HTTP/3 zu nutzen. Doch: Für music.metalhead.club hatte ich HTTP/3 nicht aktiviert. Da stellt sich zuerst die Frage: …

Wieso wird eigentlich HTTP/3 genutzt?

Für meine Mastodon Instanz unter metalhead.club war als einzigen virtual Host auf dem Nginx-Server HTTP/3 aktiviert, um vor allem für weiter entfernte Benutzer den Verbindungsaufbau zu verringern und so Ladezeiten zu verkürzen. Für diesen virtual Host war auch der Alt-Svc Header passend auf “h3” (also HTTP/3) gesetzt. Doch diese Einstellung galt nicht für andere virtual Hosts wie z.B. music.metalhead.club - wieso also stellten verschiedene Webbrowser dennoch HTTP/3-basierte Anfragen an den nicht-HTTP/3 virtual Host music.metalhead.club ?

Um das Phänomen zu erklären, muss man wissen, dass HTTP/3 ebenso wie sein Vorgänger HTTP/2 eine Funktion namens “Connection Coalescing” kennt. Wenn …

IP-Adresse
Port und
SSL-Zertifikat

gleich sind, werden “alte” QUIC-Verbindungen wiederverwendet (siehe auch RFC 7540 “Connection reuse” - auch “Connection Coalescing genannt”). Obwohl also womöglich später ein anderer virtual Host auf dem Server angesprochen wird, wird eine bestehende QUIC-Verbindung zum Server verwendet, falls die drei Parameter übereinstimmen. Ob dieser “andere” virtual Host überhaupt HTTP/3 unterstützt, wird dabei nicht mehr überprüft. In meinem Fall ist offenbar folgendes passiert:

Ein Nutzer ruft zuerst metalhead.club auf. Der Browser erkennt den HTTP/3-Support über den “Alt-Svc” Header
Weitere Verbindungen zu metalhead.club werden nun mit HTTP/3 gestellt - dazu wird eine QUIC Verbindung aufgebaut
Der Benutzer surft nun weiter zu music.metalhead.club. Dieser andere virtual Host verwendet dieselbe IP / Port / SSL-Zertifikat-Kombination (weil Wildcard-Zertifikat). Der Browser erkennt dies und benutzt die bereits bestehende QUIC-Verbindung

So kommt es, dass der Webbrowser mit dem Webserver nun auch HTTP/3 spricht, wenn es um music.metalhead.club geht.

… doch music.metalhead.club spricht kein QUIC!

In der Nginx-Konfiguration für music.metalhead.club gibt es allerdings keinen QUIC Listener. Und hier kommt die zweite Stolperfalle ins Spiel: Für den Fall, dass über eine QUIC-Verbindung ein virtual Host angefordert wird, der gar keinen QUIC-Listener hat, sucht sich Nginx den “default” QUIC virtual Host heraus. Der “default” vHost ist jener, der explizit als solcher festgelegt wurde - bzw. jener, der (wie in meinem Fall) durch die Konfigurationsreihenfolge implizit von Nginx festgelegt wurde. In meinem Fall gab es nur einen vHost, der QUIC spricht: den vHost für metalhead.club.

Anfragen an music.metalhead.club wurden also letztendlich vom vHost für metalhead.club verarbeitet, weil es sonst keinen vHost mit eingeschaltetem QUIC gab.

Da dieser vHost nur ein Proxy ist, der auf eine weitere Nginx-Instanz (“Nginx app server”) zeigt, wird die Anfrage nochmal weitergeleitet. Die App-Server Nginx Instanz in meinem Setup bekommt nun schließlich die Anfrage bezüglich music.metalhead.club - kann damit aber nichts anfangen. Schließlich besitzt sie selbst keinen vHost, der für music.metalhead.club zuständig sein könnte (siehe Diagramm). Also wird wieder einmal ein “default” vHost ausgesucht. Und da watch.metalhead.club der erste vHost ist, der in der Konfiguration des zweiten Nginx vorkommt, wird die Anfrage an watch.metalhead.club weitergereicht und dort beantwortet: Der Nutzer sieht den Globus auf der Startseite… oder eine 404-Fehlerseite, weil die angeforderte Albumübersicht auf watch.metalhead.club natürlich nicht existiert.

Rot: Die fehlerhafte Route zwischen den beiden Nginx-Instanzen. Grün: Die Soll-Route. (1) Wegen des fehlenden QUIC-Listeners wird der metalhead.club vHost angesprochen. (2) Dieser wiederum zeigt nun auf den falschen Nginx App-Server.

Die Lösung

Rätsel gelöst! Doch wie lässt sich das Problem beheben? Das Kernproblem liegt darin, dass Webbrowser annehmen, dass QUIC Verbindungen auch für andere virtual Hosts wiederverwendet werden können, wenn IP-Adresse, Port und Zertifikat dieselben sind. Deshalb sollten wir die passenden Bedingungen dafür auf der Serverseite schaffen. Die Problemlösung liegt also darin, für alle virtual Hosts QUIC zu aktivieren, die sich eine IP-Adressen / Port / Zertifikats-Kombination teilen. In meinem Fall habe ich auf dem Proxy-Nginx QUIC also auch für music.metalhead.club (und watch.metalhead.club) aktiviert. Das Problem war damit gelöst.

Globale DNS-Auflösung durch Verzicht auf CNAMES beschleunigen

thomas.leister@mailbox.org (Thomas Leister) — Thu, 19 Jun 2025 10:27:52 +0200

Wie beispielsweise in meinem Artikel “Ein eigenes kleines CDN für meine Mastodon Instanz metalhead.club” gezeigt, nutze ich gerne CNAMEs, um meine DNS-Einträge zu organisieren. Üblicherweise lege ich für jeden Host einen DNS-Record an, der seinen Hostnamen auf die IP mappt. Dann verwende ich einen oder mehrere CNAME-Einträge, um gewisse (Sub-) Domains je nach Dienst und Verwendungszweck auf diese CNAMES zu verlinken. Das hilft bei der Übersicht und kann die Organisation erleichtern - vor allem, wenn einmal IP-Adressen für Hosts ausgetauscht werden müssen. Dank der Verkettung der Einträge muss nur das letzte Mapping von Server-Hostname zu IP angepasst werden, wenn die IP-Adresse des Zielhosts sich einmal ändern sollte.

Anhand des Beispiels aus dem vorher erwähnten Artikel kann eine CNAME-Kette beispielsweise so aussehen:

[thomas@thomas-nb]~% dig media.metalhead.club
;; ANSWER SECTION:
media.metalhead.club. 1800 IN CNAME metalheadclub-media.cdn.650thz.de.
metalheadclub-media.cdn.650thz.de. 21600 IN CNAME s3.650thz.de.
s3.650thz.de. 3600 IN A 5.1.72.141

Es wird also zunächst media.metalhead.club aufgelöst, dann metalheadclub-media.cdn.650thz.de und schließlich s3.650thz.de. Erst dann steht die IP-Adresse für den Zielhost fest. Das gefällt mir im Sinne der Ordnung, weil die Gliederung für mich im Kopf Sinn ergibt. Wie ich allerdings bei der Analyse meines kleinen CDNs für metalhead.club feststellen müsste, ist das für die Performance nicht besonders förderlich. Denn der Gebrauch von CNAMES hat aber auch einen bedeutenden Nachteil: Die Zeit für eine DNS-Auflösung verlängert sich mit jedem CNAME in der Kette bis zur IP-Adresse.

Allein die Auflösung der zweiten Zeile aus der “Answer Section” bedeutet beispielsweise: Erst .de auflösen (DNS-Rootserver befragen), dann .de Nameserver nach 650thz.de befragen, dann 650thz.de Nameserver nach cdn befragen, schließlich die cdn-Nameserver nach metalhead.club-media befragen. Erst dann steht fest: Es muss s3.650thz.de aufgelöst werden. Das Spiel beginnt erneut, bis am Ende schließlich die IP-Adresse feststeht.

Es dürfte klar sein, dass diese Kette aus zwei CNAME-Einträgen durchaus Zeit braucht, bis sie vom DNS-Resolver des Nutzers aufgelöst ist. Für regionale Nutzer, die sich in Reichweite dieser Nameserver befinden, fällt der Aufwand nicht so sehr ins Gewicht, da das Auflösen jedes Kettenglieds in der Regel nur einige zehntel Millisekunden braucht.

Anders sieht es aber für Nutzer aus, die (wie im Fall des metalhead.club) beispielsweise aus den USA oder aus Australien auf Nameserver in Europa zugreifen müssen. Denn:

Rootserver: Global
.de-Nameserver: Global
650thz.de: Regional, EU
cdn.650thz.de: Regional, EU

In meiner Kette sind 4 Zonen auf 4 (virtuellen) Nameservern involviert. Jeder muss einzeln befragt werden und nur zwei davon sind global aufgestellt, d.h. sie sind weltweit mit minimalen Latenzzeiten erreichbar. Alle regionalen Server sind für alle, die sich nicht in der EU aufhalten, nur mit deutlich erhöhten Laufzeiten erreichbar. Dass gleich 2x (aus ihrer Sicht “langsame”) regionale DNS-Nameserver im Fall eines US-Nutzers abgefragt werden müssen, sorgt dann dafür, dass sich die erhöhten Latenzen sehr schnell aufaddieren.

Aus Sicht eines US-Nutzers oder eines Nutzers aus Asien ist es also besonders wichtig, dass Auflösungsketten möglichst kurz gehalten werden. Besonders deutlich wird das Bild, wenn man ein Tool wie z.B. globalping.io nutzt und sich die globalen Auflösungszeiten im DNS-Modus einmal ansieht:

Während EU-Nutzer media.metalhead.club (im Screenshot media-old.metalhead.club) nach etwa 0,004 - 0,070 Sekunden aufgelöst bekommen, muss sich ein Japaner deutlich länger gedulden: Nämlich ca 1,5 Sekunden! Erst dann kann sein Browser anfangen, Kontakt zum endgültigen Zielserver aufzunehmen.

Das gilt selbstverständlich nur für die erste DNS-Anfrage nach Ablauf der TTL. Kurz darauf folgende Anfragen werden vom DNS-Resolver üblicherweise aus dem Cache beantwortet, sodass diese um Größenordnungen schneller beantwortet werden. Nach Ablauf der TTL dauert der erste Request allerdings wieder 1,5 Sekunden! Allerdings kann bei den wenigen Nutzern in einigen Regionen nicht angenommen werden, dass diese einen gemeinsamen DNS-Resolver nutzen. Daher ist es mir wichtig, dass auch ungecachte Requests zügig beantwortet werden.

Also habe ich mich entschieden, Auf CNAME-Ketten ganz zu verzichten. Und das ging so:

In der metalhead.club Zone habe ich die Subdomain media.metalhead.club direkt an den GeoIP-Nameserver von Scaleway delegiert
Der Scaleway-Nameserver löst dann direkt zu einer IP-Adresse auf, die zur Region des Nutzers passt

Es sind also keine CNAMEs mehr an der Auflösung beteiligt: Die gesamte Auflösung basiert nur noch auf Zonendelegation.

Das Ganze ließe sich durch folgende Maßnahmen nochmal verbessern:

Keine Trennung von “normalem” DNS-Nameserver (Core-Networks.de) und GeoIP Nameserver (Scaleway): Dann könnte auf die “media”-Zonendelegation verzichtet werden
Globale Erreichbarkeit aller Nameserver (ist allerdings ein nicht unbedeutender Kostenfaktor, außerdem neuer DNS-Anbieter erforderlich)

Aber auch ohne diese beiden Verbesserungen konnte ich alleine durch den Verzicht auf CNAMES auf Auflösungszeit deutlich verkürzen, wie dieser Screenshot zeigt:

Das ist doch schon viel besser: Nach der Optimierung durch Verzicht auf CNAMES dauert die Auflösung von media.metalhead.club in diesem Fall nur noch rund 0,7 Sekunden statt 1,9 Sekunden!

Übrigens: Die Hauptdomain metalhead.club löst technisch bedingt sowieso gleich auf IP-Adressen auf. Hier ist keine Optimierung nötig gewesen.

Ein eigenes kleines CDN für meine Mastodon-Instanz metalhead.club

thomas.leister@mailbox.org (Thomas Leister) — Thu, 19 Jun 2025 08:11:04 +0200

Seit der großen Twitter-Welle, die das Mastodon-Netzwerk bzw. das Fediverse im weiteren Sinne im Herbst und Winter 2022 geflutet hat, spielen internationale User für den metalhead.club eine größere Rolle. Der Service ist vollständig in Deutschland gehostet und das war bis vor kurzem auch noch so. Doch mit der steigenden Zahl von internationalen Mitgliedern kommen auch neue Herausforderungen: Beispielsweise die der zügigen Content-Auslieferung.

Solange sich die Nutzer hauptsächlich in Deutschland und Europa befinden, sind die Latenzzeiten zum “Full Metal Server” in Frankfurt gering. Anders sieht es aber beispielsweise für die Nutzer aus Kanada, aus den USA und aus Australien aus, von denen es eine nicht zu unterschätzende Zahl im metalhead.club gibt. Für diese Nutzer war die Nutzung von metalhead.club manchmal ein kleines Geduldsspiel, denn vor allem Videos und größere Bilder erschienen nur mit einer kleinen Verzögerung auf der Website. Ich kann die Situation nur im Browser simulieren, doch bereits ein Ping von mehr als 200 ms verdirbt einem an so mancher Stelle den Spaß am Durchscrollen der Timeline.

Vor kurzem hat mich ein US-Nutzer auf ein konkretes Problem beim Abspielen eines Videos innerhalb der USA aufmerksam gemacht. Das iFixit Video konnte von ihm nur mit ständigen Unterbrechungen gestreamt werden. Grund für mich, mir endlich einmal Gedanken zu einem CDN zu machen - einem Content Delivery Network.

Sinn und Zweck eines solchen Netzwerks ist, die Inhalte, die einem Nutzer einer Plattform oder Website zur Verfügung stehen, gewissermaßen näher an den Nutzer zu rücken. Das ist nicht nur metaphorisch gemeint, sondern tatsächlich auch eine physische Angelegenheit: Selbst wenn man annimmt, dass durch Internetknotenpunkte, Signalrepeater und sonstiges Equipment keine zusätzlichen Latenzen auf der Strecke von hier in die USA ins System eingebracht werden, ist das Licht in den Meereskabeln bekanntermaßen nicht unendlich schnell. Allein dieser Umstand führt dazu, dass man die Webinhalte tatsächlich (physisch) näher am Kunden anbieten muss. Ein CDN besteht also aus vielen Datacenter-Standorten bzw. Servern, die in der Nähe der Nutzer installiert werden - idealerweise in Ballungsräumen, wo man zusätzlich von einer gut ausgebauten Netzinfrastruktur profitieren kann. Je nach Use Case in gewissen Weltregionen oder sogar auf der ganzen Welt. Die Inhalte werden auf alle (oder einige) der Server gespiegelt - je nach Bedarf. Ein US-Nutzer wird beim Anfordern der Inhalte nicht an einen EU-Server weitergeleitet, sondern ruft die Inhalte automatisch von einem Server in seiner Nähe (einem US-Datacenter) ab. Dieser Vorgang bleibt vor dem Nutzer idR transparent. Um zu erkennen, von welchem Standort aus ein Inhalt abgerufen wird (und welcher der zuständige Server ist), gibt es zwei Verfahren, die sich etabliert haben:

Anycast-basierte CDNs
“GeoIP”-basierte CDNs

Anycast-basierte CDNs

Ersterer CDN-Typ ist der “Goldstandard” und ermöglicht ein sehr elegantes (und genaues) Routing: Im Prinzip wird mehreren weltweit verstreuten Servern dieselbe öffentliche IP-Adresse zugeordnet. Welcher Server dann bei einer Anfrage tatsächlich angesprochen wird, wird durch das Routingprotokoll BGP entschieden. Dieses legt gewissermaßen die Pfade fest, die ein IP-Paket nehmen muss, um ans Ziel zu gelangen. Meistens gibt es mehrere Wege, ans Ziel zu kommen. Welcher mit den geringsten Kosten (oder der geringsten Latenz!) verbunden ist, weiß das Routingsystem. Insofern gibt man die Arbeit an das Routingsystem ab und verlässt sich darauf, dass es den schnellsten Weg durch’s Internet findet. Denn dafür ist es da - dafür wurde es entwickelt. Der Weg muss nicht immer der geografisch kürzeste sein. Wenn die Latenz auf Strecke A zu Server A kleiner ist als Strecke B zu Server B, werden die IP-Pakete automatisch zu Server A geleitet. Dieser antwortet dann. Die übrigen Server, die unter derselben IP-Adresse erreichbar sind, bekommen von der Anfrage nichts mit. So ein Anycast steckt übrigens auch hinter allen global verfügbaren DNS-Resolvern wie z.B. Google DNS, Quad9 oder Cloudflare DNS. Die IP-Adresse ist immer dieselbe - doch im Hintergrund wird man zum nächstgelegenen Server weitergeleitet, ohne etwas davon mitzubekommen.

GeoIP-basierte CDNs

Hinter dem Begriff GeoIP versteckt sich eine große Datenbank - eine GeoIP-Datenbank, wie sie beispielsweise von Unternehmen wie MaxMind angeboten werden (und wie sie beispielsweise in meinem Projekt watch.metalhead.club zum Einsatz kommt). Die Datenbank wird aus öffentlich verfügbaren Routinginformationen gespeist und speichert, welche IP-Adressbereiche (und damit ASNs) welchem Unternehmen zugeordnet sind. Sobald die Inhaberschaft einer IP-Adresse klar ist, lassen sich über das zugeordnete Unternehmen Rückschlüsse auf das geografische Nutzungsgebiet ziehen. IPv6-Adressen, die dem 2003::/19 Netz kommen (also 2003:: bis 2003:1fff:ffff:ffff:ffff:ffff:ffff:ffff) gehören beispielsweise der Deutschen Telekom. Damit ist auch klar, woher ein Benutzer kommt, der so eine IP-Adresse hat und einen Inhalt damit anfragt: Aus Deutschland. GeoIP Datenbanken speichern diese Zusammenhänge, sodass man sie dann befragen kann: “Woher kommt ein Nutzer mit der IP-Adresse xxx?”. Die Datenbank liefert dann eine mehr oder weniger genaue Antwort.

Die Genauigkeit von GeoIP-basierten CDNs

Meine Erfahrung mit den kostenlosen Angeboten solcher Datenbanken hat mir gezeigt: Auf Länderebene funktioniert das noch ganz gut - aber bis auf die Stadt genau kann man Nutzer meistens nicht verorten. Und das ist vielleicht auch ganz gut so. Es gibt bessere und schlechtere Datenbanken. Die genauen Datenbanken befinden sich meistens hinter einem kostspieligen Abomodell. Denn: GeoIP-Datenbanken müssen gepflegt werden. IP-Adressen bzw. Subnetze werden vor allem in Zeiten von IPv4-Adressmangel gehandelt und verkauft und an andere Anbieter verkauft. Ein Adressbereich, der gerade noch einem afrikanischen Mobilfunkanbieter gehört hat, kann morgen schon einem kleinen asiatischen Unternehmen gehören. Werden die Datenbanken nicht regelmäßig gepflegt, sind die Informationen veraltet und wertlos.

Und genau hier liegt der große Nachteil von GeoIP. Während sich Anycast-basierte CDNs darauf stützen, dass Routingsysteme bereits die kürzesten Strecken (im Sinne von Latenz) kennen, verlässt man sich bei GeoIP auf weitere gesammelte Informationen. Die Zuordnung IP-Adresse <=> Besitzer ist nicht schwer zu ermitteln und öffentlich. Die Schwierigkeit dürfte viel eher darin liegen, Art der Verwendung und Verwendungsregion für einen Besitzer korrekt zu ermitteln. Es kann sich schließlich um ein kleines Unternehmen handeln, aber auch im einen ISP, der die Adressen nur an seine Kunden weiterverteilt. Wie so eine Verteilung stattfindet und wie groß das geografische Verwendungsgebiet ist, weiß dann nur der Besitzer bzw. ISP. Um diese Zuordnung akkurater zu gestalten, können zusätzliche Trackinginformationen verwendet werden. So könnten vor allem dank Smartphones beispielsweise GPS-Standpunkt und verwendete IP-Adresse von einem Onlinewerbeunternehmen kombiniert werden, um den Aufenthaltsort eines Nutzers genauer zu bestimmen. Werden diese GPS-Informationen dann an den GeoIP-Anbieter verkauft, kann dieser den Verwendungsort der IP-Adresse viel genauer bestimmen. Aber das ist eine andere Geschichte …

Wie läuft nun die Weiterleitung eines Nutzers an den richtigen Server ab, wenn kein Anycast genutzt wird? Ganz einfach: Über den Verzeichnisdienst des Internets - das DNS.

Will man ein GeoIP-basiertes CDN bauen, braucht man DNS-Server, der dem Nutzer die passende IP-Adresse für seine Regio zurückgibt. Bei jeder Anfrage an den DNS-Service wird die IP-Adresse ermittelt und im Hintergrund der passende Zielhost basierend auf einer GeoIP-Datenbank ermittelt. Ich schreibe bewusst “die IP-Adresse”, denn welche IP-Adresse genau untersucht wird, kommt darauf an …

Resolver-IP oder EDNS Client Subnet (ECS)?

Man könnte nun meinen, es würde die Adresse des anfragenden Nutzers untersucht, beispielsweise die öffentliche IP-Adresse des Smartphones oder des Laptops - dem ist aber nicht so. Denn: Der Nameserver, der für meine Domain z.B. metalhead.club zuständig ist, bekommt diesen Client (fast) nie zu Gesicht. Es sind nämlich die DNS-Resolver, die für den Client die korrekte IP für einen Service anfragen - nicht die Clients selbst. Alles, was der GeoIP-Nameserver also auswerten kann, ist die IP-Adresse des Resolvers.

In vielen Fällen hat man so zwar nicht den Nutzer selbst geortet, ist aber in der Lage, seinen DNS-Resolver zu identifizieren. In den meisten Fällen ist das bei Privatkunden der Standard-DNS-Resolver des Kunden-ISPs, also beispielsweise der Deutschen Telekom. Der Standort des DNS-Resolvers stimmt in den meisten Fällen also ungefähr mit dem Standort des Kunden überein - zumindest, wenn man die Sache auf Länderebene betrachtet. Sieht mein Nameserver also eine IP, die einem Deutsche Telekom Resolver zugeordnet werden kann, kann ich idR. davon ausgehen, dass der eigentlich anfragende Nutzer ebenfalls aus Deutschland kommt.

Dann gibt es da aber noch Sonderfälle: Nämlich global verfügbare und ISP-unabhängige, offene DNS-Resolver. Beispielsweise:

Cloudflare DNS
Google DNS
Quad9
DNS4EU

Diese lassen häufig keine Rückschlüsse auf ein bestimmtes Land zu. Damit man den eigentlich anfragenden Kunden hinter dem DNS-Request dennoch ungefähr orten kann, gibt es eine EDNS-Erweiterung namens “ECS” (EDNS Client Subnet), die es erlaubt, zusätzliche Informationen an meinen Nameserver zu schicken: Nämlich das Subnetz des ursprünglichen Nutzers. Der Resolver kennt diese Client-IP naturgemäß und leitet sie in anonymisierter Form (nur Subnetz statt genauer IP-Adresse) an meinen Nameserver weiter. Dieser kann nun das per ECS weitergeleitete Subnetz statt der Resolver-IP für seine GeoIP-Datenbank verwenden und erhält ein präziseres Ergebnis zum geografischen Ursprung der Anfrage.

ECS wird nicht von allen Public Resolvern unterstützt - von DNS4EU wird ECS beispielsweise noch nicht unterstützt - auch, wenn das Feature bei dem Betreiber auf der Todo-Liste steht:

DNS4EU currently does not support EDNS, but we want to add support for this feature. Unfortunately, we do not have a timeline on when this should be done. Please check the project page https://www.joindns4.eu/learn for updates.

Was also nutzen? CDN-Provider oder selbst hosten?

Anycast-Systeme sind teuer. Sehr teuer. Und für jemanden wie mich nicht umzusetzen. Denn dazu müsste man einen eigenen IP-Adressbereich besitzen, für den man selbst BGP Routen definieren kann. Somit war das Thema für mich schnell erledigt. Anycast? Betreibe ich nicht selbst. Nun gibt es da aber noch eine andere Möglichkeit: Schließlich kann man sich ja in bestehende Anycast-Systeme einmieten oder CDNs einfach mieten. Auch das mieten von Anycast-IPs ist kostspielig und wird von den Hostern, die ich nutze bzw. nutzen will, nicht in der Form angeboten.

Frei mietbare CDNs gibt es jedoch wie Sand am Meer: BunnyCDN, Akamai, Cloudflare, KeyCDN, … sie sind nur einige populäre Beispiele. Oftmals werden diese CDNs auch in Kombination mit DNS-Services, S3 Speicher oder DDoS-Schutz verkauft. Mit dabei sind auch einige Angebote, die man sich als kleiner Plattformbetreiber im Internet gut leisten kann. Mein Interesse galt vor allem BunnyCDN. Mit ca. 20-25 € im Monat könnte ich die etwa 2.5 TB an metalhead.club Medien im Monat weltweit ausspielen lassen. Doch es gibt zwei Haken, die mich derzeit noch daran stören:

Ich muss die TLS-Terminierung aus der Hand geben und die Medien fremd hosten lassen. Meine Nutzer verlassen sich allerdings darauf, dass ich alle Daten in meiner eigenen Hand habe
Das Ökostrom-Problem: Es ist einfacher geworden, Serverhoster zu finden, die mit reinem Ökostrom arbeiten. Bei CDN-Anbietern sieht es leider noch nicht so gut aus: Nur Cloudflare scheint 100 % Ökostrom einzusetzen.

Damit fällt also auch das Einmieten in einem bestehenden CDN (erst einmal?) weg.

Ein eigenes Geo-IP basiertes CDN basteln

Bleibt also nur: Selbst basteln!

Meine Ansprüche sind relativ niedrig. Mir ist natürlich bewusst, dass ein eigenes GeoIP-basiertes CDN schnell an seine Grenzen bzw. Effizienz, Genauigkeit und Performance kommt. Ganz besonders dann, wenn man - wie ich - vor hat, nur sehr wenig Geld dafür zu investieren. Mir geht es in erster Linie darum, die Nutzererfahrung für einige meiner metalhead.club Member besser zu machen. Die perfekte Lösung werde ich auf diese Art und Weise nicht erreichen.

Da die Versorgungssituation innerhalb Europas in Ordnung ist und Latenzmessungen über Online-Tools (dazu später mehr!) ein zufriedenstellendes Ergebnis geliefert haben, habe ich mich vor allem zwei Standorten gewidmet: Dem amerikanischen Kontinent und dem asiatischen. Damit wäre mit insgesamt 3 Medienservern für media.metalhead.club der ganze Globus grob abgedeckt.

Über das “Ping Simulation” Tool habe ich mir angesehen, mit welchen Latenzen ich global in etwas rechnen kann, wenn ich die Server so verteile, wie ich es mir vorgestellt habe. Nämlich so, wie es mir der Serverhoster Hetzner durch seine Cloud erlaubt. Einen Hetzner-Account habe ich bereits und kenne mich mit den Produkten aus - zudem erfüllen sie meine Anforderungen (Deutsches Unternehmen, DSGVO-konform, 100 % Ökostrom). Und auch, was die Standorte angeht, hat Hetzner genau das im Angebot was ich will. Denn es gibt neben europäischen Rechenzentren auch zwei in den USA und eines in Singapur.

Die Simulation ergab, dass ich weite Teile der Welt mit etwa 100 ms oder weniger erreichen kann. Natürlich auch immer abhängig vom lokalen Provider, aber das Gesamtbild war einigermaßen gleichmäßig und nur an wenigen Standorten waren die Paketlaufzeiten deutlich höher als 150 ms. Also habe ich bei Hetzner kurzerhand einen Cloudserver in Ashburn (VA, USA) und einen in Singapur gebucht.

Implementierung

Was die vServer angeht, habe ich zu den kleinsten und günstigsten Modellen gegriffen, die Hetzner anbietet. Ich wollte klein starten und das Ganze erst einmal ausprobieren. Wie sich gezeigt hat, reichen die CPX11 Cloudserver bisher völlig aus. Sie müssen nur statische Dateien cachen und ausliefern - mehr nicht.

Nginx Caching Proxy

Auf den Servern läuft nur eine Nginx-Instanz, die

… Anfragen an media.metalhead.club entgegennimmt
nachsieht, ob die angeforderten Inhalte schon lokal vorliegen
(falls nicht, werden diese vom original S3 Bucket angefragt und gecached)
an den Client zurückliefert

Meine Konfiguration für Nginx:

proxy_cache_path /tmp/nginx-cache-metalheadclub-media levels=1:2 keys_zone=s3_cache:10m max_size=30g
inactive=48h use_temp_path=off;
server {
listen 80;
listen [::]:80;
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name media.metalhead.club;
include snippets/tls-common.conf;
ssl_certificate /etc/acme.sh/media.metalhead.club/fullchain.pem;
ssl_certificate_key /etc/acme.sh/media.metalhead.club/privkey.pem;
client_max_body_size 100M;
# Register backend URLs
set $minio_backend 'https://metalheadclub-media.s3.650thz.de';
root /var/www/media.metalhead.club;
location / {
access_log off;
try_files $uri @minio;
}
#
# Own Minio S3 server (new)
#
location @minio {
limit_except GET {
deny all;
}
resolver 9.9.9.9;
proxy_set_header Host 'metalheadclub-media.s3.650thz.de';
proxy_set_header Connection '';
proxy_set_header Authorization '';
proxy_hide_header Set-Cookie;
proxy_hide_header 'Access-Control-Allow-Origin';
proxy_hide_header 'Access-Control-Allow-Methods';
proxy_hide_header 'Access-Control-Allow-Headers';
proxy_hide_header x-amz-id-2;
proxy_hide_header x-amz-request-id;
proxy_hide_header x-amz-meta-server-side-encryption;
proxy_hide_header x-amz-server-side-encryption;
proxy_hide_header x-amz-bucket-region;
proxy_hide_header x-amzn-requestid;
proxy_ignore_headers Set-Cookie;
proxy_pass $minio_backend$uri;
# Caching to avoid S3 access
proxy_cache s3_cache;
proxy_cache_valid 200 304 48h;
proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
proxy_cache_lock on;
proxy_cache_revalidate on;
expires 1y;
add_header Cache-Control public;
add_header 'Access-Control-Allow-Origin' '*';
add_header X-Cache-Status $upstream_cache_status;
add_header X-Content-Type-Options nosniff;
add_header Content-Security-Policy "default-src 'none'; form-action 'none'";
add_header X-Served-By "cdn-us.650thz.de";
}
}

Übrigens: Das Hinzufügen des X-Served-By Headers erleichtert das Debuggen bzw. Überprüfen der Funktion. Für jedes Bild, das von media.metalhead.club geladen wird, lässt sich so sehr einfach feststellen, welcher der drei Hosts die Datei denn tatsächlich übertragen hat. Einsehbar ist der Header beispielsweise in den Entwicklertools jedes Webbrowsers.

GeoIP-basierte DNS-Zonen

Fehlt nun noch der GeoIP-Anteil, damit die metalhead.club Member an den jeweils passenden Server weitergeleitet werden. An dieser Stelle hätte ich einen eigenen GeoIP-/GeoDNS-fähigen Nameserver konfigurieren können (wie ich es in einem eigenen Kundenprojekt schon getan habe), doch für mein Experiment wollte ich nicht zu viel Aufwand betreiben. Also habe ich mich etwas umgesehen und bei Scaleway ein sehr interessantes Angebot gefunden. Dort kann man nämlich Nameserver mieten, die zum einen das GeoIP Feature beherrschen und sich zum anderen auch mit externen Domains nutzen lassen (also Domains, die man nicht bei Scaleway gebucht hat). Je nach Nutzung kostet ein solcher Service nur wenige Cent bis niedrige einstellige Eurobeträge für meinen Fall. Genau kann ich es sagen, wenn mein CDN eine Weile gelaufen ist ;-)

Allerdings wollte ich Scaleway nicht meine 650thz.de Root Zone überlassen. Diese sollte nach wie vor von Core-Networks.de gehostet werden. Stattdessen habe ich eine eigene Zone “cdn.650thz.de” angelegt und die Scaleway-Nameserver als autoritative Nameserver festgelegt. Zuvor musste allerdings die Eigentümerschaft von cdn.650thz.de gegenüber Scaleway bewiesen werden. Die NS-Einträge habe ich also noch nicht gesetzt, sondern zuerst einen Verifizierungseintrag in der metalhead.club Zone angelegt:

_scaleway-challenge IN TXT 3600 "verifizierungs-string"

Nach ca. 30 Minuten war bestätigt, dass ich die Kontrolle über die Domain habe und ich konnte anfangen, die Scaleway-Nameserver für cdn.650thz.de in der 650thz.de Zone bei Core-Networks.de einzutragen:

cdn 86400 NS ns0.dom.scw.cloud.
cdn 86400 NS ns1.dom.scw.cloud.

(den _scaleway-challenge Eintrag habe ich wieder gelöscht)

Übrigens: Die 650thz.de Domain nutze ich für sämtliche Infrastruktur im Hintergrund, da metalhead.club zum 650thz.de Projekt gehört. Lasst euch davon nicht verwirren.

In der cdn.650thz.de Zone habe ich dann schließlich den GeoIP-Eintrag für metalheadclub-media.cdn.650thz.de hinzugefügt:

Der default-Eintrag zeigt auf s3.650thz.de - den bisherigen S3-Medienserver in Frankfurt. Sollte jedoch ein Clientstandort in Nord- oder Südamerika erkannt werden, wird stattdessen der CDN-Server cdn-us.650thz.de genutzt. Wird ein Standort in Asien oder im pazifischen Raum erkannt, wird auf den CDN-Server cdn-ap.650thz.de verwiesen.

Essentiell ist übrigens der abschließe Punkt hinter jedem der FQDNs in der Eingabemaske! Wird kein Punkt gesetzt, wird ein Eintrag in derselben Zone referenziert - das kann nicht funktionieren.

Die Verkettung von DNS-Records mittels CNAME hat sich im Nachhinein übrigens als ungünstig für weit entfernte Benutzer herausgestellt. Mehr dazu unter “Weitere Verbesserungen: DNS-Optimierung”

Umschaltung auf CDN-Betrieb

Um nun alle Anfragen an media.metalhead.club mit dem passenden Medienserver zu beantworten, war noch noch eine Änderung nötig: Der Eintrag für media.metalhead.club musste im metalhead.club Zonefile auf metalheadclub-media.cdn.650thz.de verweisen:

media IN CNAME 3600 metalheadclub-media.cdn.650thz.de.

(auch hier wieder auf den abschließenden Punkt achten!)

Um das CDN nach der DNS-Umstellung (und der zuvor eingetragenen TTL) zu testen, habe ich kurzerhand von jedem der Server aus einen nslookup auf media.metalhead.club gemacht:

Von s3.650thz.de aus: Gibt eigene IP zurück
Von cdn-us.650thz.de aus: Gibt eigene IP zurück
Von cdn-ap.650thz.de aus: Gibt eigene IP zurück

Die dynamische Zuteilung funktionierte also!

Wie gut funktioniert das?

Um nun noch ein breiteres Bild zu bekommen, habe ich noch weitere Tests durchgeführt, zum Beispiel mit folgenden Tools:

CDN HTTP Response Time Test: https://tools.keycdn.com/performance
CDN Test mit IPs: https://www.uptrends.com/tools/cdn-performance-check
BunnyCDN Ping Test: https://tools.bunny.net/latency-test
CDNPerf Test: https://www.cdnperf.com/tools/cdn-latency-benchmark

Auch metalhead.club User habe ich dazu befragt. Ein Nutzer aus Australien hatte zuvor diese Ping-Zeiten zu media.metalhead.club:

64 bytes from 5.1.72.141: icmp_seq=0 ttl=38 time=369.765 ms
64 bytes from 5.1.72.141: icmp_seq=1 ttl=38 time=350.830 ms
64 bytes from 5.1.72.141: icmp_seq=2 ttl=38 time=469.047 ms
64 bytes from 5.1.72.141: icmp_seq=3 ttl=38 time=379.882 ms
64 bytes from 5.1.72.141: icmp_seq=4 ttl=38 time=400.998 ms

(also im Mittel knapp 400 ms!)

Danach waren die Latenzen deutlich niedriger, weil er korrekterweise zu dem US-Server statt dem EU-Server weitergeleitet wurde:

64 bytes from 5.223.63.2: icmp_seq=0 ttl=50 time=150.384 ms
64 bytes from 5.223.63.2: icmp_seq=1 ttl=50 time=230.931 ms
64 bytes from 5.223.63.2: icmp_seq=2 ttl=50 time=360.083 ms
64 bytes from 5.223.63.2: icmp_seq=3 ttl=50 time=142.986 ms
64 bytes from 5.223.63.2: icmp_seq=4 ttl=50 time=138.416 ms
64 bytes from 5.223.63.2: icmp_seq=5 ttl=50 time=300.561 ms

(im Mittel 264 ms).

Nicht weltbewegend, aber dennoch bedeutend weniger. Dass dieser Benutzer trotzdem eine relativ hohe Latenz zum Medienspeicher hat, kommt daher, das die Strecke von Australien nach Singapur trotzdem nicht zu vernachlässigen ist. Hier zeigt mein kleines CDN gleich seine Schwäche: Durch nur 3 Standorte kann man keine Bestperformance erreichen - aber man kann immerhin eine kleine Verbesserung herbeiführen.

Für einen anderen australischen User hat sich die Latenz von durchschnittlich 346 ms auf 108 ms verbessert!

Und für den User aus den USA, den ich zu Beginn erwähnt habe? Der konnte nach der Umstellung das fragliche Video problemlos und flüssig abspielen.

Mit dem BunnyCDN Test habe ich einen Vorher-Nachher-Vergleich angestellt:

Vorher:

Nachher:

Ziel erreicht!

Für die meisten Standorte rund um die USA, Australien, Korea und Japan haben sich die Latenzzeiten deutlich verbessert. Europa ist wie erwartet unverändert. Es gibt aber auch einige unerwartete Ausreißer, die wohl einer falschen IP-Lokalisierung zum Opfer gefallen sind, beispielsweise in Singapur selbst (interessant!), in der Türkei, Indien, im US-Bundesstaat Texas und Chile.

Selbstverständlich hängen die Ergebnisse auch stark damit zusammen, mit welchen IPs getestet wurde und wie die Anbindung vor Ort aussieht. Womöglich wurde die Türkei schon als “Asiatischer Raum” gewertet und der Standort, von dem aus in Texas getestet wurde, wurde womöglich als europäisch erkannt.

Ich werde die Ergebnisse weiter beobachten. Da hier vor allem von Rechenzentren aus gemessen wurde (und nicht von Privathaushalten aus entsprechenden ISP-Bereichen), spiegeln die Ergebnisse womöglich nicht die ganze Wahrheit wider.

Man kann sich also zurecht fragen: …

Ist auf GeoIP Verlass?

Da ich bei der Prüfung meines CDNs mit den oben erwähnten Test-Websites festgestellt habe, dass der kontaktierte Server nicht immer korrekt dem Teststandort entsprach (siehe Ergebnis des Singapur-Standorts!), habe ich meine Nutzer befragt. Denn die Ergebnisse dieser Web-Tools sind vermutlich nicht besonders genau. Ich schätze, dass der Mechanismus für Endkunden-Adressbereiche viel besser funktionieren als für Datacenter-Adressbereiche. Schließlich können für Privatkunden-IPs sehr viel einfacher GPS- und andere Standortinformationen “hinfusioniert” werden.

Und tatsächlich: Die Nutzer bekamen in fast allen Fällen den korrekten Medienserver aufgrund ihrer Herkunft zugeteilt. Siehe: https://metalhead.club/@thomas/114676148254141233 (Den Post hätte ich wohl eher mit einer Umfrage-Option versehen sollen … )

Die letzte manuelle Zählung am 15.06.2025 hat ergeben:

Für 83 Benutzer (allerdings die meisten davon aus DE), hat die Zuteilung funktioniert
Für 4 Benutzer hat diese nicht funktioniert. 3 davon wurden in die USA weitergeleitet statt Frankfurt - ein Benutzer wurde sogar nach Singapur verbunden, obwohl er in Deutschland war.

Ich habe den Scaleway Support dazu befragt, welche GeoIP Datenbank genutzt wird und wie häufig diese aktualisiert wird. Folgende Antwort habe ich erhalten:

There can occasionally be discrepancies, such as the one you experienced with the Singapore data center being identified as European. It can take time for GeoIP databases to reflect changes like IP reallocation. Our GeoIP database provider involve frequent updates, often on a weekly or bi-weekly basis. While we don’t publicly disclose the specific third-party GeoIP database provider we use, we rely on a reputable industry-standard provider to ensure the highest possible accuracy for our customers. We understand that accurate GeoIP routing is crucial for latency-sensitive applications. If you encounter significant and persistent inaccuracies, we encourage you to report them to our support team so we can investigate further.

Außerdem habe ich nachgehakt, ob bei Scaleway GeoIP nur die Resolver-Adresse für die Ortung genutzt wird, oder auch eine Auswertung des EDNS ECS Felds erfolgt. Das würde die Genauigkeit verbessern:

Our product team has got back to us to indicate that you are right. First we use the EDNS/ECS feature and if it’s not available we use resolver’s IP address.

Wie geht’s weiter?

Mit einem Anycast-basiertem CDN könnte man sicherlich deutlich bessere Ergebnisse erzielen, aber das ist für mich aus den oben genannten Gründen ja erst einmal keine implementierbare Lösung. Da mein kleines GeoIP CDN zwar nicht in allen, aber in den meisten Fällen eine Verbesserung erreicht, werde ich das Experiment weiterlaufen lassen. Vielleicht gibt es noch die ein oder andere Stellschraube, mit der man die Lokalisierung verbessern kann.

Ansonsten spiele ich auch mit dem Gedanken, evtl. doch auf ein professionelleres, fremd gehostetes und AnyCast CDN umzusteigen. Dann wäre Cloudflare allerdings der einzige Anbieter, auf den ich mich stützen könnte. Denn das “100 % Green Energy” Label meiner Dienste bin ich nicht bereit für ein CDN aufzugeben.

Insgesamt kann man sagen, dass mein GeoIP-CDN hilft, den Zugriff für die meisten weit entfernten Benutzer zu verbessern. Es gibt aber auch Einschränkungen:

Nicht in allen Fällen wird der passende CDN-Server zugewiesen (Ungenauigkeit der GeoIP Datenbank)
Für einen Latenzvorteil muss ein bestimmter Inhalt bereits von einem anderen Benutzer aus der Region abgerufen worden sein (Inhalte werden (noch?) nicht über alle CDN-Server synchron vorgehalten => Mehr Speicherbedarf)
Nur Medieninhalte werden vom CDN vorgehalten. API-Services und Webfrontend werden nach wie vor nur in der EU gehostet.

Weitere Verbesserungen: DNS-Optimierung

Nachdem ich mein CDN ausgerollt habe, habe ich durch Performancetools festgestellt, dass die DNS-Namensauflösung vor allem für weit entfernte Benutzer einen großen Teil der gesamten Ladezeit einnimmt. Wie sich das verbessern lässt, habe ich in diesem Folgeartikel beschrieben: “Globale DNS-Auflösung durch Verzicht auf CNAMES beschleunigen”

Mastodon Media Storage: Woher kommt der Overhead im Minio S3 Speicher?

thomas.leister@mailbox.org (Thomas Leister) — Sat, 07 Jun 2025 10:27:30 +0200

Gestern habe ich mir ein kleines Tool geschrieben, das ermittelt, wie die Dateigrößenverteilung in meinem metalhead.club S3 Storage ist.

Wichtig: Das bezieht sich auf den Storage-Layer von meinem Minio-Server - nicht direkt auf die Dateien, wie sie hochgeladen wurden. Minio legt noch Metadateien dazu bzw. integriert kleinere Dateien in eigene Strukturen und legt diese dann im Dateisystem ab. Siehe: Working with Small Objects in AI/ML workloads

Ich wollte trotzdem mal sehen, wie viel Speicher durch Blocksize-Overhead verloren geht.

root@s3 /root # time ./filesize-analyzer /mnt/s3storage1/metalheadclub-media
Dateigrößenstatistik:
>= 1024K: 136138 Dateien
< 1K: 913982 Dateien
< 2K: 53357 Dateien
< 4K: 99581 Dateien
< 8K: 182476 Dateien
< 16K: 383095 Dateien
< 32K: 646094 Dateien
< 64K: 711153 Dateien
< 128K: 419150 Dateien
< 256K: 389334 Dateien
< 512K: 260465 Dateien
< 1024K: 134658 Dateien
Theoretische Gesamtgröße der Dateien kleiner als 4K: 766435063 Bytes
Tatsächliche Gesamtgröße der Dateien kleiner als 4K: 4370104320 Bytes
./filesize-analyzer /mnt/s3storage1/metalheadclub-media 100,41s user 1157,35s system 21% cpu 1:36:57,26 total

Das Ergebnis: 1.066.920 Dateien sind kleiner als die Dateisystem-Blocksize von 4K (ext4). Diese brauchen also beim Ablegen im Dateisystem mehr Speicher, als sie eigentlich groß sind. Das kommt daher, dass für jede Datei - auch wenn sie kleiner ist - im Dateisystem mindestens 4 KB (Kilobyte, 4 x 1024 bytes) reserviert werden. All diese Dateien erzeugen also einen Overhead.

Durch den Vergleich in den letzten beiden Zeilen wird klar, wie groß der Overhead ist: Eigentlich sind die betreffenden Dateien nur 766435063 Bytes (= 731 MB) groß, doch der Blocksize-Overhead im Dateisystem führt dazu, dass diese real 4370104320 Bytes (= 4167 MB) belegen. Das ist 570 % ihrer eigentlichen Größe.

Übrigens ist das nicht die ganze Geschichte: Mein Tool berücksichtigt im Moment noch keine Bruchstücke von Dateien, die größer oder gleich 4K sind. Eigentlich kommt nämlich auch bei den größeren Dateien noch Overhead durch die Blocksize dazu. Nämlich dann, wenn ihre Größe nicht genau ein vielfaches von 4K ist. Im Fall der größeren Dateien spielt der Overhead im Verhältnis zur abgespeicherten Datenmenge allerdings kaum mehr eine Rolle, daher habe ich ihn bei der Auswertung ignoriert. Besonders dramatisch Fällt der Overhead bei den ganz kleinen Dateien aus.

Wie ihr an der letzten Zeile der Ausgabe erkennen könnt, hat die Auswertung des metalhead.club Media Storage knapp über 1,5 Stunden gedauert. Das ist nicht besonders schnell - allerdings liegen im Storage auch etwa 4,3 Millionen Dateien, die einzeln auf ihre Größe untersucht wurden - dazu noch verschachtelt in relativ tiefen Verzeichnishierarchien.

Mein Tool zur Analyse ist bisher nur ein Proof of concept. Womöglich habe ich noch den ein oder anderen Bug in meinem Code. Die Berechnung sieht realistisch aus, doch ich hoffe, noch bessere Performance herauskitzeln zu können. Da gibt es sicherlich noch Verbesserungspotential. Daher habe ich es noch nicht veröffentlicht. Sollte ich aber einmal zufrieden damit sein, steht einer Veröffentlichung natürlich nichts im Wege. Interessanterweise konnte ich auf die Schnelle kein solches Tool finden, das einem eine kleine Statistik über die Dateigrößen in einem Verzeichnis liefert. Vielleicht habe ich auch nur nicht genau genug gesucht …

Auf das Thems bin ich übrigens gekommen, nachdem das Monitoring meines S3 Servers Alarm schlug, da nicht mehr besonders viel Speicher auf dem SSD-Speicher frei war. Ich war verwundert und habe (zu einem früheren Zeitpunkt) kurz die Größenangaben der verschiedenen Systeme verglichen.

Mastodon sagt: 603 GiB Medien gespeichert
Minio S3 sagt: 692 GiB Medien gespeichert
Filesystem sagt: 763 GiB Medien gespeichert

Da die Angaben zum Speicherverbrauch so stark abwichen, begab ich mich auf Spurensuche. Wie konnte es sein, dass Mastodon der Meinung war, dass es nur 603 GiB an Medien besaß, aber das Dateisystem mit 763 GiB deutlich mehr belegt war? Ich hoffte, darauf eine Antwort zu finden. Da Mastodon sehr viele sehr kleine Dateien abspeichert (Vorschaubilder, Avatare, …), lag mein Verdacht auf dem Blocksize-Overhead. Wie ihr seht, ist dieser im Verhältnis zur Originaldateigröße beträchtlich. Aber nicht bedeutend genug, als dass er zumindest die 763-692 GiB = 71 GiB Unterschied zwischen Minio und Filesystem erklären könnte. Denn bezogen auf meinen konkreten Fall bedeutet das nur, dass ich nur ca 3.4 GB mehr belege, als theoretisch nötig - nicht 71 GiB.

Und dann wäre da noch der Unterschied zwischen Mastodon und Minio. Der könnte evtl. an verwaisten Dateien liegen, die zwar noch im Minio S3 Speicher liegen, aber von denen Mastodon aus irgendeinem Grund nichts mehr weiß. Ich habe zwar ein tootctl media remove-orphans ausgeführt, das den Speicher um solch verwaiste Dateien eigentlich bereinigen sollte. Doch dabei sind auch nur 2.8 GB Speicher frei geworden.

Falls sich jemand tiefergehend in der Materie auskennt: Schreibt mich gerne an! Entweder auf Mastodon (thomas@metalhead.club) oder per E-Mail. Würde mich freuen, wenn ich mir die Unterschiede erklären könnte.

Faircamp als selbstgehostete Alternative zu Bandcamp

thomas.leister@mailbox.org (Thomas Leister) — Thu, 29 May 2025 16:41:57 +0200

Meine Mastodon-Instanz metalhead.club hat mittlerweile schon einige Unterprojekte hervorgebracht: T-Shirts, Patches, Flyer, Plakate, Sticker und sogar ein Bier. Alles mit dem metalhead.club-Branding.

Nun ist aber ein ganz besonderes Projekt fertig geworden, an dem ich nicht direkt beteiligt war: Ein metalhead.club Song! Oder wohl eher: Eine Hymne!

Einige talentierte Member haben sich im Sommer 2024 zusammengeschlossen, um einen Song für und über ihre Lieblings-Mastodoninstanz zu schreiben - und das ist ihnen sehr gelungen! Das Ergebnis kann hier angehört und gegen eine kleine Spende auch heruntergeladen werden.

Bandcamp: Als Künstler nur mit PayPal

Nun galt es allerdings, den Song auf einer passenden Plattform zu veröffentlichen und interessierten Membern und Nutzern anderer Mastodon-Instanzen zum Download anzubieten. Mein erster Gedanke ging Richtung Bandcamp. Dort höre und kaufe ich seit vielen Jahren sehr gerne Musik. Der separate Künstleraccount war schnell angelegt, doch relativ schnell weichte die anfängliche Begeisterung der Ernüchterung: Bandcamp unterstützt (zumindest hier in Deutschland) einzig und allein den Zahlungsdienstleister PayPal.

Während man als normaler Bandcamp-Nutzer wenigstens noch auf die Zahlung via Kreditkarte ausweichen kann, bleibt bei Künstleraccounts nur die Verknüpfung mit einem PayPal Konto. Anders lassen sich Zahlungen für die entstandenen Einnahmen nicht entgegennehmen. Sehr schade, denn Sinn und Zweck der Veröffentlichung sollte (auch aus Sicht der Band!) sein, dass die beim Verkauf eingenommenen Gelder für die weitere Finanzierung der Mastodon-Instanz verwendet werden sollten. Da Bandcamp keinerlei Alternativen anbietet, war die Plattform für mich also eine Sackgasse. PayPal ist für mich seit dem Zwischenfall im Dezember 2022 ein No-Go!

Faircamp als Alternative?

@MiseryPath, der das Song-Projekt ins Leben gerufen hat, brachte dann aber relativ schnell das richtige Stichwort ins Spiel: “Faircamp”!

Bei Faircamp handelt es sich nicht etwa um eine Bandcamp-Kopie, sondern genau genommen nur um einen Static Site Generator, aus dem sich Künstler ihre eigenen kleinen Bandcamp-ähnlichen Websites generieren können. Das Projekt wurde von Simon Repp ins Leben gerufen und maßgeblich entwickelt. Von Faircamp habe ich vor einer Weile schon einmal gehört und auch schon einzelne Künstlerseiten gesehen, die darauf basieren.

Also habe ich mir das Tool selbst einmal genauer angesehen und nach ersten Gehversuchen damit war ich schnell begeistert! Faircamp eignet sich hervorragend für genau das, wofür es vorgesehen ist: In kurzer Zeit eine eigene Bandcamp-ähnliche Website an den Start zu kriegen! Und das geht so:

Je nach Plattform wird das Faircamp Binary auf dem System installiert. Unter Fedora Linux ist das mit wenigen Kommandos erledigt:

1sudo dnf install cmake ffmpeg-free gcc git opus-devel rust vips-devel
2git clone https://codeberg.org/simonrepp/Faircamp.git
3cd Faircamp
4cargo install --features libvips --locked --path .

Danach wird der sogenannte “Catalog” angelegt: Ein Verzeichnis, das die zu veröffentlichen Musikdateien und (je nach Anpassungsbedarf) auch ein paar Konfigurationsdateien enthält. Hat man seine Verzeichnisstruktur fertiggestellt und alle Musikdateien passend sortiert abgelegt, wird in diesem Verzeichnis nur noch das faircamp Executable aufgerufen.

Und fertig ist die Website. Das Executable nimmt sich alle Dateien, konvertiert die Songs in die vorgegebenen bzw. passende Dateiformate, bringt auf Wunsch Metadaten mit ein und erzeugt alle HTML-Dateien und Assets, die für den Betrieb einer kleinen Website erforderlich sind. Die Dateien können dann per FTP oder SSH auf einen beliebigen Webspace hochgeladen werden. Dieser muss nur das Minimum von dem Erfüllen, was ein Webspace erfüllen muss: Er muss Dateien ausliefern können. Datenbank, PHP, Python oder irgendwelche speziellen Einstellungen werden nicht benötigt - der Charme eines Static Site Generators eben …

Das Resultat kann dann beispielsweise so aussehen:

Screenshot von Faircamp unter music.metalhead.club

Das Basis-Design ist vorgegeben. Allerdings lassen sich je nach Geschmack auch einige Schaltflächen oder Sektionen ein- oder ausblenden, umbenennen und die Farben für Hintergrund und Akzentfarben anpassen. Ich habe mich für ein ziemlich schlichtes Design entschieden.

“Softes” Abkassieren

Mit dabei ist auch eine “Weiche Bezahlschranke” (“Soft paycurtain”). Soll heißen: Man kann für die angebotenen Musikdateien durchaus einen Preis angeben. Entweder einen Fixpreis oder einen Preisbereich. Der Nutzer kann dann im Rahmen dessen selbst entscheiden, wie viel er für einen Download zu zahlen bereit ist. Allerdings wird der Bezahlvorgang bei dieser “soft” Variante nicht verifiziert, denn ob der Nutzer für einen Download gezahlt hat (oder nicht!), können wir technisch nicht abfragen. Das liegt in der Natur einer statischen Website: Anders als bei anderen Modellen kann der Server hier im Hintergrund keine Logik verarbeiten und somit nicht überprüfen, ob tatsächlich eine Zahlung getätigt wurde. Auch eine clientseitige Verifizierung ist relativ sinnlos - diese lässt sich sehr einfach manipulieren.

Insofern ist man spätestens hier auf die Ehrlichkeit der Nutzer angewiesen: Wer an dem Track interessiert ist, wird mit der entsprechenden “Ich habe bereits gezahlt”-Schaltfläche hoffentlich zurecht quittieren, dass er oder sie zu dem Download berechtigt ist. Selbstverständlich lässt sich die Bezahlung kinderleicht umgehen, wenn man das will.

Das lässt sich aus meiner Sicht in diesem Fall aber absolut verkraften. Denn mit der Musik soll nicht Geld gescheffelt werden - es geht darum, potentiellen metalhead.club-Spendern für ihre Spende eine kleine Belohnung in Form des Song-Downloads zu geben. Und das kann mit Faircamp ganz wunderbar umgesetzt werden - und ganz ohne PayPal, ohne Gebühren für Zahlungsdienstleister und ohne Aufschläge in Form von Steuern, weil der Plattformanbieter beispielsweise in den USA sitzt … ;-)

Wer auch mit dem Gedanken spielt, seine Musik auf einer selbst gehosteten Website zum Kauf oder kostenlosen Download anzubieten, sollte sich Faircamp einmal ansehen. Zumindest dann, wenn eine Bezahlung nicht verifiziert werden muss und es keinen Nutzeraccount mit eigener Bibliothek braucht, kann Faircamp eine tolle Alternative zu den zentralen Plattformen wie Soundcloud oder Bandcamp sein.

Ein Windows 10 USB Bootmedium unter Fedora / Linux erstellen

thomas.leister@mailbox.org (Thomas Leister) — Wed, 02 Oct 2024 11:52:12 +0200

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.

Kurzerhand habe ich also bei Microsoft ein WIndows 10 64-Bit Image heruntergeladen und wollte dieses auf meinen USB-Stick kopieren:

sudo dd if=~/Downloads/Win10.img of=/dev/sdc bs=8M

Nachdem das Image gebrannt war, habe ich den Stick am Laptop eingesteckt und über eine der F-Tasten beim Start den Bootmanager aufgerufen. Üblicherweise lässt sich das Bootmedium vor dem OS-start hier noch einmal anpassen, wenn die UEFI-Einstellung nicht schon korrekt ist. Schließlich wollte ich ja vom USB-Stick starten und nicht von einer der beiden verbauten Festplatten.

Doch: Nichts! Für den USB-Stick gab es keinen Eintrag. Ein Blick ins BIOS offenbarte, dass ein Start von einem USB-Medium zwar nicht die höchste Priorität hatte, aber selbst, nachdem ich das geändert hatte, zeigte mir das BIOS bzw. UEFI nur “No Boot Medium found”.

Na gut. Vielleicht war mein Bootmedium ja defekt. Ich versuchte es mit dem Fedora Media Writer - einem grafischen Tool, das standardmäßig in jeder Fedora-Installation enthalten ist. Über den Media Writer können Fedora Images auf USB-Sticks kopiert werden, aber auch beliebige andere Betriebssystemimages. Aber auch über den Fedora Media Writer gelangte ich zu keinem bootbaren USB-Stick: Selber Fehler. Auch das umstecken in andere USB-Slots brachte keinen Erfolg. Zuletzt versuchte ich sogar die manuelle Formatierung des USB-Sticks und ein anschließendes manuelles Kopieren der Dateien. Ich habe mich dabei nach dieser Anleitung gerichtet: “Windows 10 Bootstick erstellen”. Doch wieder kein Erfolg.

Schließlich kam ich über Umwege auf das Tool woeusb. Mir gefiel, dass es aus den Fedora Paketquellen installierbar war und - im Gegensatz zu Unetbootin und anderen Alternativen - über die Kommandozeile lief. Also auch in meiner Wayland-Umgebung (anders als Unetbootin!).

Mein Windows 10 Image habe ich also wie folgt auf meinen USB-Stick kopiert:

sudo woeusb --device ~/Downloads/Win10_22H2_German_x64v1.iso /dev/sda

… und hatte damit Erfolg!

Nun - wieso hat das funktioniert und meine vorherigen Versuche nicht? Das Log von woeusb liefert eine Erklärung:

WoeUSB v5.2.4
==============================
Info: Mounting source filesystem...
Info: Wiping all existing partition table and filesystem signatures in /dev/sda...
/dev/sda: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
/dev/sda: 8 bytes were erased at offset 0x734ffffe00 (gpt): 45 46 49 20 50 41 52 54
/dev/sda: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
/dev/sda: calling ioctl to re-read partition table: Erfolg
Info: Ensure that /dev/sda is really wiped...
Info: Creating new partition table on /dev/sda...
Info: Creating target partition...
Info: Making system realize that partition table has changed...
Info: Wait 3 seconds for block device nodes to populate...
mkfs.fat 4.2 (2021-01-31)
mkfs.fat: Warning: lowercase labels might not work properly on some systems
Info: Mounting target filesystem...
Info: Copying files from source media...
Splitting WIM: 4900 MiB of 4900 MiB (100%) written, part 2 of 26%
Finished splitting "./sources/install.wim"
Info: Installing GRUB bootloader for legacy PC booting support...
i386-pc wird für Ihre Plattform installiert.
installation beendet. Keine Fehler aufgetreten.
Info: Installing custom GRUB config for legacy PC booting...
Info: Done :)
Info: The target device should be bootable now
Info: Unmounting and removing "/tmp/woeusb-source-20240930-085645-Sunday.0twgOL"...
Info: Unmounting and removing "/tmp/woeusb-target-20240930-085645-Sunday.2DBYAG"...
Info: You may now safely detach the target device

Interessant sind hier zwei Stellen:

Zum einen wird das USB-Stick offenbar mit FAT formatiert (mkfs.fat) und nicht - wie in anderen Anleitungen zu lesen - mit NTFS
Und: install.wim wird “gesplittet”?!

Der Split der install.wim Datei erklärt, wieso es mit den anderen Methoden bei mir nicht funktioniert hat: Mit diesem Schritt wird die große Imagedatei (> 4 GB) auf kleinere Dateien aufgeteilt. Das ist nötig, weil das FAT Dateisystem nur mit Dateien bis zu einer Größe von 4 GB umgehen kann.

Und warum liefert Microsoft in seinem Image, welches ich per dd zu kopieren versucht habe, eine so große Datei aus? Weil das Microsoft Windows 10 ISO NTFS-formatiert ist. Und nicht FAT-formatiert. NTFS kann mit so großen Dateien problemlos umgehen - daher wurde mir in diversen Anleitungen auch dazu geraten, den USB-Stick nicht mit FAT, sondern mit NTFS zu formatieren.

Allerdings kommt hier eine weitere Besonderheit zum Tragen: Das Acer Laptop unterstützt offenbar keine NTFS-Bootmedien. … Wie das sein kann?

Der Laptop kam ursprünglich mit Windows 8 auf dem Markt. Damals enthielt das Windows Bootmedium noch keine Dateien, die größer als 4 GB waren. Dementsprechend kam man mit dem FAT Dateisystem aus. Folglich unterstützt der Acer E774 Laptop nur FAT im UEFI und nicht NTFS. Das erklärt auch, wieso er problemlos von allen Live-Linux USB-Sticks bootete, die ich ihm gab. Hier wird noch FAT benutzt.

Zusammengefasst: mit dem woeusb Tool hatte ich letztendlich Erfolg, weil:

Der Dell-Laptop nur FAT Medien unterstützt
Das woeusb Tool FAT nutzt
Und dabei aber dafür sorgt, dass keine der Dateien größer als 4 GB ist!

Der Schlüssel ist also woeusb’s “split” Funktion.

Auf neueren Laptops sollte das Kopieren des Win10 Images auch einfach via dd funktionieren. Für meinen älteren Laptop habe ich mit woeusb aber eine tolle Lösung gefunden.

thomas-leister.de

Mailserver mit Dovecot, Postfix, MySQL und Rspamd unter Debian Trixie

Was und für wen?

Voraussetzungen für den Betrieb eines E-Mail Servers

Annahmen und Bezeichnungen

Mailserverkomponenten und ihre Aufgaben

Dovecot

Postfix

MariaDB (MySQL-Datenbank)

Rspamd

Nginx

Redis

Vorbereitungen

Login als root

Aktualisierung des Systems

Hostnamen und Server-FQDN setzen

Unbound DNS Resolver installieren

Einrichtung des DNS

Reverse DNS

SPF-Records

DMARC Records

Erstkonfiguration Nginx Webserver

Beantragung der TLS-Zertifikate (via Let’s Encrypt)

MySQL Datenbank einrichten

Domain-Tabelle

Account-Tabelle

Alias-Tabelle

vmail-Benutzer und -Verzeichnis einrichten

Dovecot installieren und konfigurieren

Diffie-Hellman Parameter für Dovecot generieren

Globales Sieve-Filterscript für Spam

Spam Learning mit Rspamd

Postfix installieren und konfigurieren

/etc/postfix/main.cf

/etc/postfix/master.cf

SQL-Konfiguration

Zusätzliche Konfigurationsdatei without_ptr

Rspamd

Grundkonfiguration

Manuell gepflegte Black-/Whitelists

DKIM Signing

Rspamd starten

Nginx Proxy für Rspamd Weboberfläche

Weboberfläche aufrufen

Via SSH-Tunnel mit der Weboberfläche verbinden (Alternative)

Domains, Accounts und Aliase in Datenbank definieren

Neue Domain anlegen

Neuen E-Mail-Account anlegen

Neuen Alias anlegen

Optional: Firewall konfigurieren

Start all the things!

Eine Verbindung zum Mailserver herstellen

Debugging

Datensicherung / Backup

Das war’s auch schon! Hat dir diese Anleitung geholfen?

Häufige Fehler

Changelog im Vergleich zur letzten Anleitung (“Mailserver unter Debian Bullseye v1.2”)

Changelog zu diesem Beitrag

Mastodon Media Storage von Minio S3 zu SeaweedFS S3 migrieren

SeaweedFS installieren

Ein Bucket anlegen

Migration der Daten von Minio zu SeaweedFS

Zwei S3 Backends für einen glatten Übergang

Virtual Host style addressing für SeaweedFS S3

Umstellung der Mastodon Instanz

Datentransfer

Ärger mit dem großen /cache Verzeichnis

Dateien löschen über S3 Lifecycle Rules

Abschluss

Alte Dovecot Konfiguration zu Dovecot 2.4 (Debian Trixie) migrieren

Schritt 1: Config-Versionsnummern hinzufügen

SSL-Einstellungen

PassDB / UserDB und auth_username_format

Mail location

Protocols

Plugins Section

Sieve Plugineinstellungen

Quota

Änderung der Zugriffsrechte

Vollständige Beispielkonfiguration

`/etc/postfix/main.cf`

`/etc/postfix/master.cf`