feat: MAILCOW_RESOLVE_HOST für internes DNS-Routing hinzufügen

README.md

@@ -15,15 +15,23 @@ services:
     birthdaydaemon:
         image: git.techniverse.net/scriptos/mailcow-birthday-daemon:latest
         restart: always
+        depends_on:
+            - nginx-mailcow
+        networks:
+            - mailcow-network
         environment:
-        - MAILCOW_BASE=https://mailcow.host
-        - MAILCOW_APIKEY=DEIN-APIKEY-HIER
+            - MAILCOW_BASE=https://mail.example.com
+            - MAILCOW_APIKEY=DEIN-APIKEY-HIER
+            - MAILCOW_RESOLVE_HOST=nginx-mailcow
         volumes:
-        - birthdaydaemon:/data
+            - birthdaydaemon:/data
+
 volumes:
     birthdaydaemon:
 ```
 
+> **Wichtig:** `mail.example.com` muss durch den tatsächlichen FQDN der eigenen Mailcow-Instanz ersetzt werden. `MAILCOW_RESOLVE_HOST=nginx-mailcow` sorgt dafür, dass der Daemon den Mailcow-Nginx innerhalb des Docker-Netzes direkt erreicht, anstatt über die öffentliche IP zu gehen (Hairpin-NAT-Problem). TLS-SNI und Zertifikatsprüfung verwenden weiterhin den Hostnamen aus `MAILCOW_BASE`.
+
 > **Tipp:** Statt `:latest` kann auch eine feste Version wie `:1.0.0` verwendet werden.
 
 Den API-Key findet man im Admin-Panel unter Konfiguration > Zugang > Administratordetails bearbeiten > API > Lese-/Schreibzugriff.
@@ -36,9 +44,10 @@ Da die Mailcow-API derzeit nicht vollständig ist und sich eher im Early-Access-
 |---|---|---|---|
 | `MAILCOW_BASE` | **Ja** | – | Basis-URL der Mailcow-Instanz (z. B. `https://mailcow.example.com`) |
 | `MAILCOW_APIKEY` | **Ja** | – | API-Key mit Lese-/Schreibzugriff aus dem Mailcow-Admin-Panel |
+| `MAILCOW_RESOLVE_HOST` | Nein | – | Interner Hostname für TCP-Verbindungen (z. B. `nginx-mailcow`). Löst Hairpin-NAT-Probleme in Docker-Netzen. TLS nutzt weiterhin den Hostnamen aus `MAILCOW_BASE`. |
 | `STATEFILE` | Nein | `state.json` (im Container: `/data/state.json`) | Pfad zur Zustandsdatei, in der App-Passwörter gespeichert werden |
 
-> **Hinweis für bestehende Installationen:** Es wurden keine Variablennamen oder Funktionalitäten geändert. Ein Update ist ohne Anpassungen möglich.
+> **Hinweis für bestehende Installationen:** Falls der Daemon die Mailcow-API wegen Hairpin-NAT nicht erreichen kann, muss lediglich `MAILCOW_RESOLVE_HOST=nginx-mailcow` als Umgebungsvariable ergänzt werden. Details siehe Installationsabschnitt.
 
 ## Funktionsweise
 

cmd/mcbdd/main.go

@@ -4,6 +4,7 @@ import (
 	"context"
 	"fmt"
 	"log/slog"
+	"net"
 	"net/http"
 	"os"
 	"strings"
@@ -56,11 +57,7 @@ func run() error {
 		userTokensLock: &sync.RWMutex{},
 		baseURL:        mailcowBase,
 		stateFilepath:  os.Getenv("STATEFILE"),
-		httpClient: &http.Client{
-			Transport: &http.Transport{
-				Proxy: http.ProxyFromEnvironment,
-			},
-		},
+		httpClient:     &http.Client{Transport: buildTransport()},
 	}
 	if len(d.stateFilepath) == 0 {
 		d.stateFilepath = "state.json"
@@ -139,3 +136,31 @@ func (d *Daemon) processUser(ctx context.Context, m mailcow.Mailbox) error {
 	}
 	return nil
 }
+
+// buildTransport erstellt einen http.Transport.
+// Wenn MAILCOW_RESOLVE_HOST gesetzt ist (z. B. "nginx-mailcow"), wird der
+// tatsächliche TCP-Connect auf diesen Host umgeleitet, während TLS-SNI und
+// Zertifikatsprüfung den Original-Hostnamen aus der URL verwenden.
+// Damit wird das Hairpin-NAT-Problem in Docker-Netzen umgangen.
+func buildTransport() *http.Transport {
+	resolveHost := os.Getenv("MAILCOW_RESOLVE_HOST")
+	t := &http.Transport{
+		Proxy: http.ProxyFromEnvironment,
+	}
+	if resolveHost != "" {
+		slog.Info("using internal resolve host for connections", "resolveHost", resolveHost)
+		dialer := &net.Dialer{
+			Timeout:   30 * time.Second,
+			KeepAlive: 30 * time.Second,
+		}
+		t.DialContext = func(ctx context.Context, network, addr string) (net.Conn, error) {
+			_, port, err := net.SplitHostPort(addr)
+			if err != nil {
+				return nil, err
+			}
+			addr = net.JoinHostPort(resolveHost, port)
+			return dialer.DialContext(ctx, network, addr)
+		}
+	}
+	return t
+}