Unix socket support for HTTP/JMAP listener

[shukiv]

Problem

When running Stalwart alongside other services on the same host (e.g., CrowdSec, monitoring agents), TCP port conflicts can occur on the HTTP/JMAP listener. In my case, CrowdSec's LAPI defaults to port 8080 — the same port Stalwart's HTTP listener uses — preventing Stalwart from binding.

Switching to another port works but is fragile. Any new service that claims the chosen port breaks JMAP silently.

Proposed Solution

Allow server.listener.<id>.bind to accept a Unix socket path in addition to IP:port, for example:

[server.listener.http]
protocol = "http"
bind = ["/run/stalwart/http.sock"]

The reverse proxy (nginx, Caddy, etc.) would then use proxy_pass http://unix:/run/stalwart/http.sock instead of a TCP port.

Benefits

• Eliminates port conflicts with co-located services
• Slightly lower latency for local reverse-proxy connections (no TCP overhead)
• Better security posture — no TCP port to accidentally expose; socket permissions control access
• Consistent with how other server software handles local-only listeners (PHP-FPM, PostgreSQL, Redis, etc.)

Context

This would only make sense for listeners accessed locally (HTTP/JMAP behind a reverse proxy). SMTP/IMAP listeners that accept remote connections would continue using TCP.

(Originally filed as issue #2961, closed because feature requests belong in Discussions per the issue template — reposting here.)

[mdecimus]

Sorry, this is not planned.

[shukiv]

Thank you for your reply.
First of all great work.
I don't know why your passing on a such an important security feature. I really hope you guys will consider it in the future.

Thanks again,
Shuki

[NextWork123]

Sorry, this is not planned.

Could you share the reasoning behind this decision? A bare "not planned" with no explanation is frustrating, especially for a feature with clear and well documented benefits.
Unix socket support for local listeners is a standard practice across the ecosystem PHP-FPM, PostgreSQL, Redis, Nginx itself all support it precisely because it solves real problems: port conflict avoidance, tighter access control through filesystem permissions, and marginally lower latency for local reverse-proxy traffic. None of these are niche concerns.
For those of us running Stalwart behind a reverse proxy on a shared host, this isn't a nice to have it's the difference between a clean, secure setup and a fragile one that breaks whenever another service claims a port.
I'd genuinely like to understand what makes this not worth pursuing. Is it a technical constraint in the listener architecture? A prioritization call? Knowing the actual reason would at least let the community assess whether a contribution or workaround is feasible.