Alias-Strategie für Mailcow — UI-basierte Alias-Verwaltung im Docker-Stack
Mailcow (mailcow-dockerized) ist der UI-freundlichste der drei Self-Hosted-Stacks: Alias-Verwaltung läuft komplett im Web-Admin-Panel unter Configuration → Mail Setup → Aliases. Kein direkter Editor-Zugriff auf /etc/aliases nötig, kein Postmap-Hash-Build, kein Router-Setup wie bei Exim — Mailcow kapselt die Komplexität im Docker-Stack. Diese Anleitung zeigt die UI-Konfiguration, die CSV-Bulk-Import-Funktion, die Wildcard-Catchall-Mechanik und eine optionale Privacy-Layer-Empfehlung wie SimpleLogin (Proton-Tochter seit 8. April 2022).
Mailcow-Alias-Strategie — UI-Komfort über Docker-Postfix-Container
Mailcow (mailcow-dockerized) ist ein Docker-basierter Mailserver-Stack — Postfix als MTA, Dovecot als IMAP-Server, Rspamd als Spam-Filter und SOGo als Webmail-Frontend. Die Alias-Verwaltung läuft komfortabel über das Web-Admin-Panel unter Configuration → Mail Setup → Aliases. Anders als bei reinem Postfix oder Exim müssen Sie keine /etc/aliases-Dateien direkt editieren, keine postmap-Hashes bauen, keinen Router konfigurieren — Mailcow kapselt die Komplexität im Container-Stack. Aliase sind dort genauso ein natives Feature wie bei Postfix oder Exim, nur komfortabel im UI gekapselt — kein Mythos wie BIMI-MTA.
Die Mailcow-UI bietet pro Alias mehrere Optionen: Source-Adresse (der Alias selbst), Goto (das Ziel-Postfach), Public-Flag (kontrolliert, ob der Alias als CC-Empfänger sichtbar wird), Active-Status (zur Soft-Deaktivierung) und ein optionales Validity-Datum für automatische Ablauf-Deaktivierung. Letzteres ist besonders nützlich für temporäre Service-Aliase. Wildcard-Catchall (*@firma.de oder @firma.de) ist unterstützt — mit dem üblichen Spam-Risiko bei Dictionary-Attacks. Die Mailcow-Doku (docs.mailcow.email) ist englischsprachig — UI-Begriffe wie Configuration, Mail Setup und Aliases sind Originalbezeichnungen.
Hardening-Pfad: MX → SPF → DKIM → DMARC → ARC & SEG → Alias-Strategie (dieser Guide).
Mailcow-UI-Login und vorhandene Aliase auflisten
Bestandsaufnahme über Web-Admin-Panel oder via Postfix-Container-API.
# Mailcow-Version pruefen (Update-Disziplin)
cd /opt/mailcow-dockerized
git log -1 --pretty=format:"%h %s %ai"
# MAILCOW_HOSTNAME pruefen
grep MAILCOW_HOSTNAME mailcow.conf
# Container-Status
docker compose ps
# Aliase auflisten via Container-API
docker exec mailcowdockerized-postfix-mailcow-1 \
postmap -s hash:/opt/postfix/conf/aliases | head -20Service-Aliase in der Mailcow-UI anlegen
Pro externem Dienst ein eigener Service-Alias. UI bietet Validity-Datum für Auto-Deaktivierung.
# Service-Alias in der Mailcow-UI anlegen
# Browser: https://mail.ihre-domain.de/admin
# -> Configuration -> Mail Setup -> Aliases
# -> "Add Alias"
#
# Form:
# Address: hubspot-2026@firma.de
# Goto: marketing@firma.de
# Public flag: on/off (extern als CC-Empfaenger anzeigbar)
# Active: on
# Validity: optional Datum (Auto-Disable)
#
# Wildcard-Catchall
# Address: *@firma.de oder @firma.de
# Goto: catchall@firma.de
#
# Mailcow uebernimmt die Aenderung in den Postfix-Container
# und schreibt /opt/postfix/conf/aliases neu.
# Public Address Aliases (CSV-Bulk-Import in der UI verfuegbar)
# Configuration -> Mail Setup -> Aliases -> "Import CSV"Mailcows Validity-Feld erlaubt eine automatische Deaktivierung am Stichtag — ideal für temporäre Konferenz-Aliase, Trial-Service-Aliase oder Beta-Tests. Damit vermeiden Sie eine wuchernde Alias-Liste mit „vergessenen“ alten Adressen. Bei dauerhaften Service-Aliasen lassen Sie das Feld leer.
Externe Privacy-Anbieter optional empfehlen
Self-Hosted-Mailcow ist datensouverän. Zusätzliche Privacy-Anbieter sind sinnvoll für besondere Schutzbedarfe.
Self-Hosted (volle Datensouveränität): addy.io (vorher AnonAddy, Rebrand 9. August 2023) self-hosted neben Mailcow auf demselben Server. EU-/CH-souverän: SimpleLogin (Proton-Tochter seit 8. April 2022, Genf). US-Konzern: Firefox Relay, DuckDuckGo Email Protection, Apple Hide My Email. Detail in der Auswahl-Matrix im Kapitel-Index.
Verifikation und Leak-Erkennung via Service-Alias plus HIBP-Monitoring
Verifikation per Container-Log und postmap-Lookup. Dauerhaft Spam-Erkennung an Service-Aliasen plus HIBP.
# Mail-Log im Postfix-Container pruefen
docker exec mailcowdockerized-postfix-mailcow-1 \
tail -f /var/log/mail.log
# Alias-Lookup direkt testen
docker exec mailcowdockerized-postfix-mailcow-1 \
postmap -q "hubspot-2026@firma.de" hash:/opt/postfix/conf/aliases
# Leak-Erkennung — Spam an Service-Alias = Leak-Quelle
# HIBP API v3
curl -H "hibp-api-key: IHR-32-ZEICHEN-API-KEY" \
https://haveibeenpwned.com/api/v3/breacheddomain/firma.de
# Mailcow update.sh (Update-Disziplin nach NIS2 lit. e)
cd /opt/mailcow-dockerized
./update.sh --check
# Update: ./update.sh
# Wolf-Agents Email Security Check erkennt Mailcow-Setups ueber
# Postfix-Container-Banner und das MAILCOW_HOSTNAME-Muster.Häufige Fehler bei der Mailcow-Alias-Strategie
Direkter Edit der Postfix-Aliases-Datei im Container — Mailcow überschreibt
Problem: Manuell in /opt/postfix/conf/aliases editiert — Mailcow überschreibt die Änderung beim nächsten UI-Sync. Ursache: Mailcow generiert die Aliases-Datei aus der MariaDB-Datenbank, die von der UI gefüttert wird. Lösung: Aliase ausschließlich über die Mailcow-UI anlegen, nicht direkt im Container.
Wildcard-Catchall ohne Spam-Filter
Problem: *@firma.de als Catch-All — Spam-Volumen explodiert. Ursache: Dictionary-Attack-Bots probieren systematisch gängige Adressen. Lösung: Wildcard-Catchall nur temporär aktivieren oder mit strikter Rspamd-Konfiguration kombinieren — Mailcow bringt Rspamd nativ mit, das hilft bei der Filterung.
Public-Flag falsch gesetzt — Aliase als CC-Empfänger sichtbar
Problem: Service-Alias-Adressen tauchen ungewollt in CC-Listen extern auf. Ursache: Public-Flag in der Mailcow-UI war aktiviert. Lösung: Bei Service-Aliasen das Public-Flag deaktivieren — sie sollen unsichtbar bleiben.
update.sh vergessen — Sicherheits-Updates verpasst
Problem: Mailcow läuft monatelang ohne Update. Ursache: Mailcow erfordert manuelle Updates via update.sh-Script. Lösung: Regelmäßige ./update.sh --check-Läufe im Cron, NIS2 Art. 21 Abs. 2 lit. e (Sicherheitsmaßnahmen bei Wartung) verlangt Update-Disziplin.
DSGVO Art. 32, MITRE M1054 und Update-Disziplin bei Self-Hosted-Mailcow
Eine Alias-Strategie in Mailcow zahlt auf DSGVO Art. 32 (Sicherheit der Verarbeitung) ein. NIS2 Art. 21 Abs. 2 lit. e (Sicherheitsmaßnahmen bei Wartung) verlangt zudem Update-Disziplin — bei Mailcow regelmäßige update.sh-Läufe. Self-Hosted-Mailcow bedeutet volle Datensouveränität: eigener Docker-Stack, eigene Server, eigene Verarbeitungs-Kette.
Mailcow-Alias-Compliance-Stack: DSGVO Art. 32 (Pseudonymisierung als TOM) + DSGVO Art. 17 (Update-Disziplin via update.sh als Wartung) + RFC 5321 §4.1.2 + NIS2 Art. 21 Abs. 2 lit. e (Sicherheitsmaßnahmen bei Wartung — Update-Disziplin via update.sh) + MITRE M1054. Wolf-Agents-USP: Der Email Security Check erkennt Mailcow über Postfix-Container-Banner und das MAILCOW_HOSTNAME-Muster und prüft Role-Mailboxes (RFC 2142). Cross-Verweis: DMARC für Mailcow, ARC & SEG für Mailcow und Postfix / Exim.
Mehrwert — Mailcow UI-Verwaltung mit Validity-Datum-Auto-Disable und CSV-Bulk-Import
Mailcow bietet die komfortabelste UI-Verwaltung für Aliase unter den Self-Hosted-Lösungen — die Postfix-Container-Suite mit Web-Frontend. Navigation: Configuration → Mail Setup → Aliases. Pro Alias konfigurierbar: address, goto (Ziel-Mailbox), active (an/aus), sogo_visible (für SOGo-Webmail sichtbar), validity (Auto-Disable-Datum). Das Validity-Datum-Auto-Disable ist die operative Stärke von Mailcow gegenüber Postfix/Exim: pro Service-Alias ein Verfallsdatum setzen (z.B. hubspot-2026@firma.de mit Validity 31.12.2026), nach Ablauf wird der Alias automatisch inaktiv — sauberer Lifecycle ohne manuelle Bereinigung.
CSV-Bulk-Import für 1000+ Aliase: Mailcow akzeptiert CSV-Imports im Format address,goto,active,sogo_visible,validity. Bei großen Migrationen (z.B. von einem alten Provider) ist das Bulk-Format der praktikable Pfad — Mailcow-Doku unter docs.mailcow.email bestätigt CSV-Format und DKIM+ARC-Generation via Rspamd-Container. Wichtige Drift-Vermeidung (Empirik 61 R4-W2 Cross-Welle): Mailcow nutzt Rspamd für ARC-Signing, NICHT OpenARC. Wer in alten Anleitungen liest, dass man docker-compose.override.yml um einen OpenARC-Container ergänzen soll, sollte das ablehnen — das ist ein Architektur-Konflikt mit der nativen Mailcow-Rspamd-Pipeline.
Update-Disziplin als NIS2-Lieferketten-Anforderung: Mailcow erfordert regelmäßige update.sh-Läufe (typisch monatlich) — das ist eine NIS2-Art-21-Abs-2-lit-e-relevante Pflicht (Sicherheit der Lieferkette). RFC-2142-Role-Mailboxes (Dave Crocker, IMC, Mai 1997 Proposed Standard — datatracker.ietf.org/doc/rfc2142) als postmaster@/abuse@/hostmaster@/security@/info@/webmaster@-Aliasse im Mailcow-UI Pflicht. Wolf-Agents-USP: Der Scanner erkennt Mailcow über Postfix-Container-Banner und MAILCOW_HOSTNAME-Muster, prüft Catch-All-Konfiguration und RFC-2142-Role-Mailboxes als Hygiene-Indikator. Cross-Verweis: Postfix (Container-Basis), Exim (alternative MTA) und Mailcow ARC via Rspamd.
Alias-Strategie-Anleitung für weitere Provider:
Wie steht Ihre Domain bei Alias-Strategie · Mailcow?
Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.