Stalwart — selbstgehosteter Mail-Server in Rust

E-Mail selbst zu hosten ist heute kein technisches Problem mehr — es ist ein politisches Statement. Wer eigene Domains betreibt, will keine Google-Postfächer, kein Outlook.com, kein Proton mit Vertrauensvorschuss in einen Schweizer Anbieter. Wer wirklich kontrollieren will, was mit seiner Kommunikation passiert, betreibt seinen eigenen Mail-Server.

Ich tue das seit gut einem Jahr mit Stalwart — einer einzelnen Rust-Binary, die SMTP, IMAP, JMAP, CalDAV, CardDAV und ManageSieve gleichzeitig beherrscht. Dieser Artikel ist kein Tutorial aus dem Nichts, sondern ein Praxisbericht aus dem produktiven Betrieb.

Warum Stalwart

Vor Stalwart habe ich die üblichen Kandidaten evaluiert.

Mailcow ist der bekannteste selbst-hostbare Mail-Stack. Er ist ausgefeilt, hat eine gute Weboberfläche und eine aktive Community — aber er kommt mit 15+ Docker-Containern: Postfix, Dovecot, Rspamd, ClamAV, Redis, MariaDB, Nginx, SOGo als Webmail, Watchdog, Certbot, Netfilter, Oletools, Unbound. Auf meinem kleinen Docker-Host belegt der Stack im Ruhebetrieb über 2 GB RAM. Ich will einen Mail-Server, kein Betriebssystem.

Mailu ist schlanker, aber der Protokoll-Support ist eingeschränkt: kein JMAP, kein CalDAV nativ. Als ich meine Kalender migrieren wollte, war das bereits eine Sackgasse.

iRedMail hatte ich kurz in Betracht gezogen, aber das Projekt ist seit 2023 kaum noch gepflegt und der Installationsweg wirkt wie eine Zeitkapsel aus 2015.

Stalwart trifft meine Anforderungen exakt:

• Einzelne Binary, geschrieben in Rust — kein Postfix, kein Dovecot, kein Rspamd daneben
• SMTP (eingehend + ausgehend), SMTP Submission, IMAP4, JMAP, CalDAV, CardDAV, ManageSieve in einem Prozess
• Kein Webmail by design — ich nutze Thunderbird auf Fedora, K-9 Mail auf Android
• RocksDB als eingebetteter Speicher — kein externer Datenbankserver erforderlich
• Im Ruhebetrieb: ~60–80 MB RAM für alles

Architektur — was Stalwart ist und was nicht

Ein vollständiger Mail-Server muss mehrere unabhängige Aufgaben beherrschen: eingehende Mails annehmen und spam-filtern (SMTP MX), ausgehende Mails für Clients entgegennehmen (SMTP Submission), Postfächer verwalten und Clients Zugriff geben (IMAP/JMAP), und optional Kalender und Kontakte synchronisieren (CalDAV/CardDAV).

Stalwart deckt alle diese Rollen in einem einzigen Prozess ab:

Hinzu kommt LMTP (interne Zustellung) und POP3 (für Legacy-Clients, falls gewünscht).

Speicher-Backends

Stalwart ist nicht an ein bestimmtes Backend gebunden:

Für privates Selfhosting auf einem Docker-Host ist RocksDB die richtige Wahl: keine zusätzliche Dependency, kein separater Container, kein Backup-Overhead für einen Datenbankserver.

Was Stalwart nicht ist

Kein Webmail. Bewusste Designentscheidung der Entwickler. Wer SOGo oder Roundcube will, muss das selbst danebenstellen. Für mich ist das kein Nachteil — ich verwende native Clients.

Kein Postfix-Wrapper. Stalwart implementiert SMTP von Grund auf neu, in Rust. Das bedeutet: keine /etc/postfix/-Configs, keine main.cf-Magie, kein postqueue -f. Wer Jahre mit Postfix verbracht hat, muss umdenken — aber das Ergebnis ist ein konsistenteres System.

Docker-Setup

Stalwart ist als einzelnes Docker-Image verfügbar. Meine docker-compose.yml:

services:
  stalwart:
    image: stalwartlabs/mail-server:latest
    container_name: stalwart-mail
    restart: unless-stopped
    ports:
      - "25:25"      # SMTP MX — muss direkt erreichbar sein
      - "465:465"    # SMTP Submission (implizit TLS)
      - "587:587"    # SMTP Submission (STARTTLS)
      - "143:143"    # IMAP
      - "993:993"    # IMAPS
      - "4190:4190"  # ManageSieve
      - "8080:8080"  # HTTP: JMAP, WebDAV, Admin-UI
    volumes:
      - ./data:/opt/stalwart-mail
    environment:
      - TZ=Europe/Berlin

Kein externes Netzwerk, kein Reverse-Proxy für die Mail-Ports — SMTP und IMAP müssen direkt auf den Server-Ports erreichbar sein. Nur der HTTP-Port 8080 läuft hinter meinem Caddy-Reverse-Proxy.

Da Stalwart hinter einer OPNsense-Firewall läuft, brauchen alle Mail-Ports ein NAT-Port-Forward vom WAN auf den Docker-Host. Die Regel sieht so aus:

Verzeichnisstruktur

Nach dem ersten Start legt Stalwart seine Struktur selbst an:

stalwart/
├── docker-compose.yml
└── data/
    ├── etc/
    │   ├── config.toml      # Hauptkonfiguration
    │   ├── certs/           # TLS-Zertifikate
    │   └── dkim/            # DKIM-Private-Keys
    └── data/                # RocksDB-Dateien

Erster Start und Admin-Account

Beim allerersten Start ohne vorhandene Konfiguration startet Stalwart im Setup-Modus. Die Admin-UI ist dann unter http://localhost:8080/admin erreichbar und führt durch die initiale Konfiguration: Hostname, Admin-Passwort, Speicher-Backend.

docker compose up -d
# Dann im Browser: http://SERVER-IP:8080/admin

Nach dem Setup-Wizard ist der Server betriebsbereit. Die Konfiguration liegt in data/etc/config.toml und kann direkt editiert oder über die Admin-API geändert werden.

TLS-Zertifikate

Stalwart hat ACME-Support eingebaut — es kann Zertifikate direkt bei Let’s Encrypt beantragen, wenn Port 80 erreichbar ist:

[acme."letsencrypt"]
directory = "https://acme-v02.api.letsencrypt.org/directory"
contact = ["mailto:admin@example.com"]
challenge = "http-01"
default = true

Alternativ lege ich eigene Zertifikate in data/etc/certs/ und referenziere sie:

[certificate."default"]
cert = "%{file:/opt/stalwart-mail/etc/certs/fullchain.pem}%"
private-key = "%{file:/opt/stalwart-mail/etc/certs/privkey.pem}%"

Ich nutze Caddy als Reverse-Proxy und lasse Caddy die Zertifikate verwalten. Caddy kopiert die Zertifikate via Cron in data/etc/certs/, Stalwart lädt sie beim Neustart.

Reverse-Proxy für HTTP

Der HTTP-Port 8080 läuft hinter Caddy. Meine Caddy-Konfiguration:

mail.example.com {
    reverse_proxy localhost:8080
}

Das gibt mir HTTPS für die Admin-UI, JMAP (https://mail.example.com/jmap/) und CalDAV/CardDAV (https://mail.example.com/dav/).

Domains und Nutzer konfigurieren

Mehrere Domains

Stalwart unterstützt virtuelle Domains — ich betreibe mehrere Domains auf derselben Instanz. Domains werden entweder über die Admin-UI unter Domains → Hinzufügen angelegt oder direkt in der Config:

[[local-key]]
key = "domain.example.com"
value = "true"

[[local-key]]
key = "domain.example.org"
value = "true"

In der Praxis nutze ich die Admin-UI — sie ist schnell und der TOML-Reload passiert automatisch.

Nutzer-Verzeichnis

Stalwart kann Nutzer intern verwalten (Standard) oder an ein externes Verzeichnis delegieren: LDAP, OIDC (OpenID Connect), PostgreSQL/MySQL als Nutzerdatenbank.

Für privates Selfhosting reicht das interne Verzeichnis vollständig aus. Nutzer werden über die Admin-UI angelegt:

Benutzer → Neu → Name, E-Mail-Adressen, Passwort, Quota

Jeder Nutzer kann mehrere E-Mail-Adressen haben — primäre Adresse und beliebig viele Aliase, alle in einem Postfach. Ich habe für jede meiner Domains eine primäre Adresse und nutze Aliase für verschiedene Zwecke.

Aliase und Catch-All

Aliase (ohne eigenes Postfach) werden ebenfalls über die Admin-UI angelegt: Aliase → Neu → Quell-Adresse → Ziel-Nutzer.

Ein Catch-All für eine Domain (alle Mails an nicht existente Adressen abfangen) wird als Alias @example.com → nutzer@example.com angelegt.

Postmaster und DMARC-Postfach

Für den Betrieb zwingend notwendig: eine postmaster@-Adresse (RFC-Pflicht) und ein Postfach für DMARC-Reports. Ich lege beides als Aliase auf meinen Haupt-Account an:

postmaster@example.com  →  henning@example.com
dmarc@example.com       →  henning@example.com

DMARC-Reports landen damit direkt in meinem Postfach — ich filtere sie per Sieve-Regel in einen eigenen Ordner.

E-Mail-Sicherheit — DKIM, DMARC, SPF, ARC

E-Mail-Authentifizierung ist heute Pflicht. Ohne SPF, DKIM und DMARC landet jede Mail im Spam oder wird abgelehnt. Gut — das hält auch echten Spam draußen.

SPF

SPF (Sender Policy Framework) definiert, welche Server Mails für eine Domain senden dürfen. DNS-Eintrag für example.com:

example.com.  IN  TXT  "v=spf1 mx ~all"

mx erlaubt den MX-Servern das Senden. ~all ist zunächst Softfail — nach DMARC-Rollout auf -all (Hardfail) verschärfen.

Stalwart prüft SPF eingehend automatisch und leitet das Ergebnis an DMARC weiter.

DKIM

DKIM (DomainKeys Identified Mail) signiert ausgehende Mails kryptografisch. Der Empfänger verifiziert die Signatur anhand eines öffentlichen DNS-Eintrags.

Key generieren:

# Im Stalwart-Datenverzeichnis
openssl genrsa -out ./data/etc/dkim/example.com.key 2048

# Public Key für DNS extrahieren
openssl rsa \
  -in ./data/etc/dkim/example.com.key \
  -pubout -outform DER 2>/dev/null \
  | base64 -w 0

DNS-Eintrag (TXT, Selector mail2024):

mail2024._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=<BASE64-KEY>"

Stalwart-Config für DKIM-Signierung:

[signature."rsa-example-com"]
private-key = "%{file:/opt/stalwart-mail/etc/dkim/example.com.key}%"
domain = "example.com"
selector = "mail2024"
algorithm = "rsa-sha256"
canonicalization = "relaxed/relaxed"

[auth.dkim.sign]
"example.com" = ["rsa-example-com"]

Alternativ kann der DKIM-Schlüssel direkt über die Admin-UI unter Einstellungen → DKIM → Neuer Schlüssel generiert werden — Stalwart gibt dann den fertigen DNS-Eintrag aus.

DMARC

DMARC verbindet SPF und DKIM und definiert, was passiert, wenn beides nicht passt. DNS-Eintrag:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

Rollout in drei Phasen:

1. p=none — Nur Reports sammeln, keine Aktion (2–4 Wochen beobachten)
2. p=quarantine — Verdächtige Mails in Spam verschieben
3. p=reject — Nicht authentifizierte Mails ablehnen

Ich bin seit Monaten bei p=reject. Zustellbarkeit bei Gmail, Outlook und Fastmail ist problemlos.

ARC — Authenticated Received Chain

ARC löst ein spezifisches Problem: Weiterleitungen. Wenn Mail von a@example.com an b@gmail.com weitergeleitet wird, bricht der ursprüngliche SPF-Check — weil der weitergeleitende Server nicht in SPF von example.com steht.

ARC ist eine Kette von Signaturen, die jeder Server beim Weiterleiten anhängt. Der Empfänger kann so die ursprüngliche Authentifizierung nachvollziehen. Stalwart signiert und verifiziert ARC automatisch — kein Konfigurationsaufwand.

Verifizierung

• MXToolbox SuperTool — SPF, DKIM, DMARC, Blacklist-Check
• mail-tester.com — Testmail schicken, Score 10/10 anstreben
• Google Postmaster Tools — Domain-Reputation bei Gmail langfristig beobachten

Anti-Spam

Stalwart hat eine mehrstufige Spam-Pipeline eingebaut — kein Rspamd, kein SpamAssassin als externer Prozess.

Pipeline

Eingehende Mail
  → SPF/DKIM/DMARC-Check (Authentifizierung)
  → DNS-Blocklists (IP-Reputation)
  → Inhaltsanalyse (Bayes-Filter)
  → [optional] LLM-Klassifikator
  → Schwellwert-Entscheidung (Accept / Tag / Quarantine / Reject)

Konfiguration

[spam.threshold]
discard = 12.0    # Über diesem Score: still verwerfen
reject = 10.0     # Über diesem Score: SMTP-Fehler zurückgeben
spam = 5.0        # Über diesem Score: als Spam markieren (Header)

[spam.bayes]
enable = true

[spam.dnsbl]
servers = [
  "zen.spamhaus.org",
  "b.barracudacentral.org",
  "bl.spamcop.net"
]

Bayes-Training

Der Bayes-Filter lernt aus Beispielen. Stalwart verwendet dafür spezielle Systempostfächer:

• Mails in Spam-Ordner verschieben → automatisch als Spam trainiert
• Mails aus Spam zurückholen → automatisch als Ham trainiert

Nach einer Einlaufphase von 2–3 Wochen mit echtem Traffic ist der Filter brauchbar. Meine Spam-Rate liegt seitdem unter einem Promille der eingehenden Mails.

LLM-Klassifikator

Stalwart kann optional einen LLM (Large Language Model) für Spam-Klassifikation einsetzen. Unterstützt werden OpenAI-kompatible APIs — also auch Ollama lokal.

[spam.llm]
enable = true
model = "gpt-4o-mini"
url = "https://api.openai.com/v1"
key = "sk-..."

Ob das sinnvoll ist, hängt vom eigenen Spam-Profil ab. Bei mir filtert Bayes + DNSBL bereits so gut, dass der LLM keinen messbaren Mehrwert bringt — aber CPU kostet. Ich habe ihn deaktiviert.

JMAP — das modernere IMAP

IMAP wurde 1986 entworfen. Es hat Jahrzehnte überlebt und wird es noch weitere überleben — aber es zeigt sein Alter.

JMAP (JSON Meta Application Protocol, RFC 8620 und RFC 8621) ist der offizielle Nachfolger. Entwickelt von Fastmail, standardisiert von der IETF.

Was JMAP besser macht

Push statt Poll. IMAP-Clients fragen den Server ständig mit IDLE-Befehlen ab. JMAP öffnet einen einzelnen EventSource-Stream — der Server schickt Delta-Updates, sobald etwas passiert. Weniger Verbindungen, weniger Strom.

Effizientes Sync. IMAP-Clients laden beim Start oft komplette Ordner-States herunter. JMAP liefert nur Deltas — was sich seit dem letzten Sync geändert hat.

Strukturierte Queries. Suche und Filterung passieren server-seitig mit strukturierten JSON-Abfragen statt proprietärer IMAP-Extensions.

Atomare Operationen. Mehrere Änderungen (Lesen + Verschieben + Löschen) in einer einzigen HTTP-Anfrage.

Client-Support

Ich nutze Thunderbird auf Fedora — JMAP ist dort noch experimentell, funktioniert aber stabil genug für den Alltag. Auf Android läuft K-9 Mail mit IMAP; JMAP-Support ist dort noch nicht angekommen.

Endpoint

Stalwart stellt JMAP unter https://mail.example.com/jmap/ bereit. Die Session-URL für Clients: https://mail.example.com/jmap/.

Keine zusätzliche Konfiguration nötig — JMAP ist in Stalwart standardmäßig aktiv.

CalDAV und CardDAV

Stalwart bringt Kalender (CalDAV) und Kontakte (CardDAV) ohne zusätzliche Software mit. Selber Server, selbe Config, selbe Authentifizierung.

Das war für mich ein entscheidender Faktor gegenüber reinen Mail-Servern: keine separate Nextcloud, kein Radicale, kein Baikal.

Endpoints

Die .well-known-URLs funktionieren — Clients mit Auto-Discovery finden die Endpoints ohne manuelle Konfiguration.

Client-Setup

GNOME Online Accounts (Fedora):

Einstellungen → Online-Konten → Konto hinzufügen → CalDAV

• Server: https://mail.example.com
• Benutzername: henning@example.com
• Passwort: Stalwart-Passwort

GNOME integriert CalDAV automatisch in GNOME Calendar und CardDAV in GNOME Contacts. Discovery funktioniert über .well-known — kein manuelles Eintragen der Kalender-URLs nötig.

Thunderbird: Thunderbird mit dem Add-on TbSync und Provider for CalDAV/CardDAV.

Android (DAVx⁵):

DAVx⁵ aus F-Droid oder dem Play Store installieren:

• Account hinzufügen → URL und E-Mail-Adresse
• Base-URL: https://mail.example.com
• DAVx⁵ findet Kalender und Kontakte automatisch über Discovery

Praxiserfahrung

Seit einem Jahr kein einziger Sync-Fehler. Kalender und Kontakte synchronisieren zuverlässig zwischen Fedora und Android. Stalwart verhält sich wie ein braver DAV-Server.

Betrieb und Monitoring

Logs

Stalwart schreibt strukturierte Logs. Log-Level und Format konfigurierbar:

[tracing.appender.stdout]
type = "stdout"
level = "info"
enable = true

[tracing.appender.stdout.format]
type = "plain"
# Alternativ: "json" für strukturiertes Logging in Loki/Elasticsearch

Im Alltag reicht info. Für Debugging einzelner Zustellprobleme temporär auf debug setzen:

docker compose exec stalwart-mail stalwart-cli server set-log-level debug

SMTP-Queue

Die Queue ist über die Admin-UI sichtbar: Warteschlange → Nachrichten. Dort sieht man, welche Mails auf Zustellung warten, wie oft bereits versucht wurde und warum vorige Versuche fehlschlugen.

Alternativ über die API:

curl -s -u admin:password http://localhost:8080/api/queue/messages \
  | jq '.[] | {id: .id, to: .recipients[].address, attempts: .attempts}'

Queue manuell flushen (alle wartenden Mails sofort wieder versuchen):

curl -X POST -u admin:password http://localhost:8080/api/queue/retry

Prometheus-Metriken

Stalwart stellt einen OpenMetrics-Endpunkt bereit:

http://localhost:8080/metrics

Prometheus-Scrape-Config:

- job_name: stalwart
  static_configs:
    - targets: ["mail-server:8080"]
  metrics_path: /metrics
  basic_auth:
    username: admin
    password: <password>

Nützliche Metriken: stalwart_smtp_message_received_total, stalwart_queue_active_messages, stalwart_imap_sessions_active.

Backup

Was gesichert werden muss:

# Alles unter data/ sichern
rsync -a --delete /opt/stalwart-mail/data/ backup@backup-server:/backup/stalwart/

# DKIM-Keys extra sichern (in data/etc/dkim/)
# Config extra sichern (data/etc/config.toml)

Für konsistente Backups den Container kurz stoppen oder den Snapshot-Mechanismus des Hypervisors nutzen. RocksDB verkraftet auch Backups im laufenden Betrieb — aber nur wenn keine parallelen Schreibzugriffe stattfinden.

Typische Fallstricke

Reverse-DNS (PTR-Record): Der wichtigste und meistübersehene Punkt. mail.example.com muss auf die Server-IP auflösen — und die IP muss per PTR-Record auf mail.example.com zurückzeigen. Ohne korrekten PTR-Record lehnen viele große Provider eingehende Mails ab oder verschieben sie in Spam. PTR-Records werden beim Hoster gesetzt, nicht im eigenen DNS.

Port 25 gesperrt: Viele Consumer-Hoster (Hetzner CX-Linie, DigitalOcean, Linode) sperren Port 25 ausgehend standardmäßig. Lösung: beim Support einen Antrag stellen (Hetzner entsperrt schnell), einen Hoster mit offenen SMTP-Ports wählen, oder einen SMTP-Relay (Mailgun, Postmark) zwischenschalten.

TLS-Zertifikat-Renewal: Wenn ACME nicht automatisch erneuert, scheitern IMAP- und SMTP-Clients oft still — sie zeigen nur “Verbindung getrennt”, keine Zertifikat-Fehlermeldung. Alerting auf Zertifikats-Ablauf einrichten: Prometheus-Alert auf ssl_earliest_cert_expiry oder ein einfacher Cronjob mit openssl s_client.

Lizenzierung — was kostet die Offenheit

Stalwart ist unter AGPL-3.0 lizenziert. Das ist eine starke Copyleft-Lizenz — und für die meisten Selfhoster irrelevant.

Was AGPL-3.0 bedeutet

Privates Selfhosting: Keine Einschränkungen. AGPL greift nur, wenn Software als Service anderen zur Verfügung gestellt wird. Wer Stalwart für sich und seine Familie betreibt, ist vollständig frei.

Betrieb für eine kleine Organisation (Verein, Kleinunternehmen): Ebenfalls frei, solange kein kommerzieller Weiterbetrieb als E-Mail-Dienst stattfindet.

Kommerzieller Mail-Hosting-Dienst: Wer E-Mail als Dienst für zahlende Kunden anbietet und dabei Stalwart modifiziert, muss den Quelltext offenlegen. Das betrifft Hoster, nicht Endnutzer.

Enterprise-Features

Stalwart Labs verkauft eine Enterprise-Lizenz, die zusätzliche Features freischaltet:

Für privates Selfhosting fehlt in der AGPL-Version nichts, was im Alltag spürbar wäre. Clustering brauche ich nicht — eine Instanz reicht. Object-Storage ist für mein Mailvolumen überdimensioniert.

Meine Einschätzung

AGPL ist die ehrlichere Lizenz als BSL oder “Source Available”. Der Quelltext ist offen, die Entwickler verdienen mit Enterprise-Features Geld — ein nachhaltiges Modell für Open Source.

Das einzige reale Risiko: Stalwart Labs entscheidet sich, künftige Core-Features in die Enterprise-Tier zu verschieben. Das ist bei anderen Projekten passiert (Grafana, HashiCorp). Ich beobachte das Changelog und halte meine Konfiguration portierbar.

Stalwart ist das erste Mail-Server-Projekt, das mich dazu gebracht hat, E-Mail-Selbsthosting als angenehm zu empfinden. Nicht als notwendiges Übel. Die Architektur ist durchdacht, die Dokumentation ist solide, und die Rust-Codebasis bedeutet in der Praxis: kein Speicherleck nach Wochen, keine zufälligen Abstürze, vorhersehbares Verhalten.

Für wen reicht Stalwart? Für jeden, der einen eigenen Server betreibt, eine oder mehrere Domains hat, und Kontrolle über seine Kommunikation will — ohne einen Kubernetes-Cluster dafür betreiben zu müssen.