Zum Inhalt

Mailcow & Caddy – Externer Mailzugriff

Setup-, Betriebs-, Netzwerk- und Support-Dokumentation für den Mailverkehr und den externen HTTPS-Zugriff.

Dokumentationsstand: 05.09.2026 (aktualisiert und verifiziert)

1. Übersicht

Mailcow läuft als lokale Mailplattform, während Caddy den öffentlichen Zugriff und die TLS-Terminierung für Mail- und Autoconfig-Endpunkte übernimmt.

Diese Kombination stellt unter anderem folgende Funktionen bereit:

  • öffentliche Mailzugriffe über mail.epping-haus.de,
  • Mail-Client-Autokonfiguration über autoconfig.epping-haus.de und autodiscover.epping-haus.de,
  • externen HTTPS-Zugriff über Caddy für die Mailoberfläche,
  • sichere Weiterleitung an den Mailcow-Server im lokalen Netzwerk.

Damit bleibt der Mailtraffic sauber getrennt von der öffentlichen Website und dem DokuWiki. Caddy übernimmt die Einbindung des externen HTTPS-Zugriffs, Mailcow übernimmt den eigentlichen Mailbetrieb.

Verwandte Seiten

2. Container-Spezifikationen (Proxmox VE)

Parameter Wert / Konfiguration
Container-ID 150
Hostname caddy
Betriebssystem Debian GNU/Linux 13.6 amd64
LXC-Typ Unprivileged (unprivilegiert)
CPU 2 Cores
RAM 2048 MB
Swap 1024 MB
RootFS local-zfs, 8 GB
Netzwerk-Bridge vmbr0
IPv4-Adresse 192.168.178.150/24
Gateway 192.168.178.10
DNS 192.168.178.10

3. Benutzer & Systemzugang

Benutzer Typ Berechtigungen / Rolle
root System Administrativer Root-Account; direkter Login wird vermieden
berthold Standard-Benutzer sudo-Gruppe; Besitzer der Webverzeichnisse

Der SSH-Server läuft auf Port 22. Caddy wird als systemd-Dienst betrieben.

4. Caddy Webserver

  • Version: Caddy v2.11.4
  • Dienst: caddy.service
  • Autostart: aktiviert
  • Konfiguration: /etc/caddy/Caddyfile
  • Website: /var/www/html
  • DokuWiki: /var/www/dokuwiki
  • PHP-FPM: php8.4-fpm über unix//run/php/php8.4-fpm.sock

4.1 Aktueller Caddyfile-Stand

epping-haus.de, www.epping-haus.de {
    root * /var/www/html
    file_server
}

wiki.epping-haus.de {
    root * /var/www/dokuwiki
    php_fastcgi unix//run/php/php8.4-fpm.sock
    file_server

    @blocked {
        path /data/* /conf/* /bin/* /inc/* /vendor/*
    }
    error @blocked 403
}

mail.epping-haus.de, autoconfig.epping-haus.de, autodiscover.epping-haus.de {
    reverse_proxy 192.168.178.146:443 {
        transport http {
            tls
            tls_server_name mail.epping-haus.de
        }
    }
}

Die Website- und DokuWiki-Konfiguration bleibt erhalten. Der Mailcow-Block stellt den öffentlichen HTTPS-Reverse-Proxy für Mailcow und die beiden Mail-Autokonfigurationsnamen bereit.

4.2 TLS / Let's Encrypt

Caddy verwaltet die TLS-Zertifikate automatisch über ACME / Let's Encrypt.

Am 05.09.2026 wurden die Zertifikate für folgende Hostnamen erfolgreich bezogen bzw. validiert:

  • mail.epping-haus.de
  • autoconfig.epping-haus.de
  • autodiscover.epping-haus.de

Caddy lauscht auf *:443.

5. Netzwerk, DNS & Portweiterleitungen

5.1 Architektur HTTPS / Mailcow

Internet
   |
   | TCP 443
   v
OpenWrt 192.168.178.10
   |
   | DNAT 443 -> 192.168.178.150:443
   v
Caddy 192.168.178.150:443
   |
   | HTTPS / Reverse Proxy
   v
Mailcow 192.168.178.146:443

5.2 Aktive OpenWrt-DNAT-Regeln

Aktuell verifiziert:

Name Eingang Ziel Zweck
Mailcow-SMTP-In TCP/25 192.168.178.146:25 Eingehendes SMTP
Mailcow-HTTP TCP/80 192.168.178.146:80 Bestehender Mailcow-HTTP-Zugriff
Caddy-HTTPS TCP/443 192.168.178.150:443 Öffentlicher HTTPS-Zugriff / Caddy
Mailcow-SMTP-Submission TCP/587 192.168.178.146:587 SMTP Submission
Mailcow-IMAPS TCP/993 192.168.178.146:993 IMAPS

Kontrolle der aktiven DNAT-Regeln:

nft list chain inet fw4 dstnat_wan | grep -E 'dport (25|443|587|993)'

Die bestehende Mailcow-No-Masq-Regel bleibt unverändert; sie dient dem Erhalt externer SMTP-Quelladressen.

5.3 Öffentliches DNS (Netcup CloudDNS)

Beim letzten Test wurde mail.epping-haus.de zu 213.21.40.83 aufgelöst. Die öffentliche IPv4 ist dynamisch und wird über PPPoE bezogen.

Record Ziel / Funktion
mail.epping-haus.de Dynamische WAN-IPv4; aktuell durch das verifizierte DynDNS-Skript gepflegt
www.epping-haus.de CNAME auf epping-haus.de
wiki.epping-haus.de CNAME auf epping-haus.de
autoconfig.epping-haus.de CNAME auf mail.epping-haus.de
autodiscover.epping-haus.de CNAME auf mail.epping-haus.de

MX:

  • epping-haus.de -> 10 mail.epping-haus.de

Hinweis: Der aktuell verifizierte OpenWrt-DynDNS-Lauf aktualisiert mail.epping-haus.de. Eine Pflege des Apex-Records epping-haus.de durch dieses konkrete Skript ist aktuell nicht als Sollzustand dokumentiert.

5.4 DynDNS auf OpenWrt

Die DynDNS-Konfiguration liegt in:

  • /etc/netcup-ddns.conf – Berechtigung 600
  • /root/bin/netcup-mail-ddns – Berechtigung 700

Der geheime DynDNS-Token wird nicht dokumentiert.

Das Skript liest die aktuelle WAN-IPv4 über ubus und ruft die Netcup-DynDNS-Schnittstelle per HTTPS auf. Der aktuell verifizierte Cron-Lauf für das Skript erfolgt alle 5 Minuten.

Aktueller Cron-Stand:

#0 4 * * * /sbin/ifdown wan && sleep 15 && /sbin/ifup wan
*/5 * * * * /root/bin/netcup-mail-ddns

Der tägliche PPPoE-Reconnect ist damit auskommentiert. Es werden keine künstlichen täglichen IP-Wechsel erzwungen; DynDNS reagiert auf tatsächliche PPPoE-IP-Wechsel.

6. Verifikation 05.09.2026

6.1 HTTPS-Webzugriff

Der Zugriff auf https://mail.epping-haus.de wurde erfolgreich über den Pfad Caddy -> Mailcow nginx verifiziert.

Der letzte Test lieferte:

HTTP/2 200
server: nginx
via: 2.0 Caddy

Damit ist der öffentliche Reverse-Proxy-Pfad über Caddy aktuell funktionsfähig.

6.2 Autoconfig

Der externe Aufruf

https://autoconfig.epping-haus.de/mail/config-v1.1.xml?emailaddress=berthold@epping-haus.de

lieferte HTTP 200 und gültiges XML. Die Antwort enthält unter anderem:

  • IMAP SSL/TLS auf Port 993
  • IMAP STARTTLS auf Port 143
  • SMTP SSL/TLS auf Port 465
  • SMTP STARTTLS auf Port 587

Für den bevorzugten Mailclient-Betrieb werden 993/SSL und 587/STARTTLS verwendet.

6.3 Autodiscover

Der externe Aufruf

https://autodiscover.epping-haus.de/autodiscover/autodiscover.xml

lieferte HTTP 200, Content-Type: application/xml und eine Mailcow-Autodiscover-Antwort.

Der manuell durchgeführte GET-Test ohne vollständigen Autodiscover-Request-Body führte innerhalb der XML-Antwort zu ErrorCode 600 / Invalid Request. Das ist kein Nachweis für einen Reverse-Proxy-Fehler; ein vollständiger Autodiscover-POST wurde in diesem Test nicht durchgeführt.

6.4 Mailclient-Ports

Mit Test-NetConnection wurden die Ports 993 und 587 erfolgreich erreicht. Der konkrete Test lief aus dem lokalen WLAN und ist daher als LAN-/Hairpin-Verifikation zu werten, nicht als abschließender WAN-Nachweis.

Test-NetConnection mail.epping-haus.de -Port 993
# TcpTestSucceeded : True

Test-NetConnection mail.epping-haus.de -Port 587
# TcpTestSucceeded : True

7. Mailclient-Einstellungen

Dienst Server Port Sicherheit
IMAP mail.epping-haus.de 993 SSL/TLS
SMTP Submission mail.epping-haus.de 587 STARTTLS

Benutzername: vollständige E-Mail-Adresse, z. B. berthold@epping-haus.de.

8. Wartungs- und Diagnosebefehle

8.1 Im Caddy-LXC

# Konfiguration prüfen
caddy validate --config /etc/caddy/Caddyfile

# Konfiguration neu laden
systemctl reload caddy

# Status
systemctl status caddy --no-pager

# Port 443 prüfen
ss -lntp | grep ':443'

# Logs
journalctl -u caddy -n 100 --no-pager
journalctl -u caddy -f

# Verbindung zu Mailcow aus Caddy testen
curl -vk --resolve mail.epping-haus.de:443:192.168.178.146 https://mail.epping-haus.de/

8.2 Vom Proxmox-Host

pct status 150
pct exec 150 -- systemctl status caddy --no-pager
pct exec 150 -- caddy version
pct exec 150 -- caddy validate --config /etc/caddy/Caddyfile
pct exec 150 -- ss -lntp | grep ':443'

8.3 Mailcow-502-Diagnose

Nach Neustarts oder Neuerstellungen von php-fpm-mailcow können sich die internen Docker-IP-Adressen ändern. Am 05.09.2026 zeigte nginx noch alte Upstream-Adressen, obwohl die aktuelle nginx-Konfiguration korrekt php-fpm-mailcow:9001 bzw. php-fpm-mailcow:9002 verwendet hat.

Die aktuelle Verbindung vom nginx-Container zu PHP-FPM war erfolgreich:

cd /opt/mailcow-dockerized
docker compose exec nginx-mailcow getent hosts php-fpm-mailcow
docker compose exec nginx-mailcow nc -zv -w 3 php-fpm-mailcow 9001
docker compose exec nginx-mailcow nc -zv -w 3 php-fpm-mailcow 9002

Dabei waren beide Ports offen. PHP-FPM lauschte auf [::]:9001 und [::]:9002; bindv6only war 0.

Die Behebung bestand darin, nur nginx-mailcow neu zu starten, damit die aktuelle Docker-DNS-Auflösung übernommen wird:

cd /opt/mailcow-dockerized
docker compose restart nginx-mailcow
sleep 10
curl -k -I https://mail.epping-haus.de

Der anschließende Test lieferte HTTP/2 200. Bei einem vergleichbaren 502-Fehler daher nicht sofort PHP-FPM oder das Docker-Netzwerk ändern. Zuerst Container-IP, DNS-Auflösung und die Erreichbarkeit von 9001/9002 prüfen.

9. Backups & Wiederherstellung

Bekannte Backups aus den bisherigen Arbeiten:

  • Caddy-Konfigurationsbackup vor HTTPS-Aktivierung: /root/caddyfile.before-https-20260904-123628
  • OpenWrt-Firewallbackup vor Freigabe TCP/443: /root/firewall.before-caddy-443-20260904-121445
  • OpenWrt-Firewallbackup vor Mailclient-Ports 587/993: /etc/config/firewall.backup-before-mailclient-ports
  • Mailcow-Konfigurationsbackup vor Secret-Rotation: /root/mailcow.conf.before-secret-rotation-<timestamp>
  • Mailcow-Compose-Sicherung vor Secret-Rotation: /root/mailcow-compose.before-secret-rotation-<timestamp>.yml
  • Mailcow-Status-Sicherung vor Secret-Rotation: /root/mailcow-status.before-secret-rotation-<timestamp>.txt

Vor jeder Änderung an Caddy oder OpenWrt zuerst die bestehende Konfiguration sichern.

10. Sicherheits- und Betriebsregeln

  • DynDNS-Token, Passwörter, DB-Zugangsdaten, Redis-Zugangsdaten und SMTP-Zugangsdaten niemals in Dokumentationen veröffentlichen.
  • MariaDB- und Redis-Zugangsdaten wurden am 05.09.2026 rotiert und anschließend erfolgreich getestet.
  • Der produktive Mailcow-DKIM-Schlüssel wird über den vorgesehenen Mailcow-Mechanismus in Redis verwaltet; der produktive Selector ist dkim.
  • Ein bei einem manuellen rspamadm dkim_keygen-Test erzeugter und sichtbar gewordener privater DKIM-Schlüssel gilt als kompromittiert und darf nicht verwendet werden.
  • Vor Firewall-Änderungen immer ein Backup erstellen.
  • Nach Firewall-Änderungen den effektiven nftables-Regelsatz kontrollieren.
  • Caddy-Konfiguration vor Reload immer mit caddy validate prüfen.
  • Nach Container-Neuerstellungen interne Docker-IP-Adressen nicht als feste Sollwerte dokumentieren.
  • Das SMGW / smgw_zone darf bei Mailcow-, Caddy-, DNS- oder Firewall-Arbeiten nicht verändert werden.

11. Aktueller Gesamtzustand

  • Caddy-LXC: CT 150 / 192.168.178.150
  • Mailcow: 192.168.178.146
  • OpenWrt: 192.168.178.10
  • Caddy: v2.11.4
  • HTTPS: 443 -> Caddy -> Mailcow HTTPS
  • SMTP: 25 -> Mailcow
  • SMTP Submission: 587 -> Mailcow
  • IMAPS: 993 -> Mailcow
  • Website: epping-haus.de / www.epping-haus.de
  • DokuWiki: wiki.epping-haus.de
  • Mail-Webzugriff: mail.epping-haus.de
  • Mail-Autoconfig: autoconfig.epping-haus.de
  • Mail-Autodiscover: autodiscover.epping-haus.de
  • Öffentliche IPv4 beim letzten Test: 213.21.40.83 (dynamisch)
  • HTTPS-Mail-Webzugriff: HTTP/2 200 über Caddy -> Mailcow
  • Autoconfig: HTTP 200 / gültiges XML
  • Autodiscover: HTTP 200 / Mailcow-Antwort; GET-Test ohne vollständigen Body erwartungsgemäß ErrorCode 600
  • DynDNS: mail.epping-haus.de aktiv; Token geschützt; Lauf alle 5 Minuten
  • Brevo: ausgehender Mailversand aktiv; Domain authentifiziert und gebrandet
  • SMGW: separat und unverändert

Dokumentationsstand: 05.09.2026

Erweiterte Dokumentation

Mailcow – Setup & Support 2026