Announcing nauthilus-director: a Nauthilus-backed mail protocol director
Hi,
I would like to announce nauthilus-director for the first time on this list.
nauthilus-director is an open-source mail protocol director and transparent proxy for Nauthilus-backed mail deployments. It sits in front of stateful mail backends, authenticates frontend sessions through Nauthilus, resolves routing and placement inside the director, selects healthy backend services, keeps active user affinity in Redis, and then proxies the established connection to the selected backend.
The current focus is on deployments where backend placement, maintenance, drains, user movement and session affinity need to be explicit, observable and controllable. The director is not a mailbox server and not a general-purpose load balancer; it owns the narrow director responsibilities between clients, Nauthilus and backend mail services.
Current capabilities include:
- IMAP/IMAPS, POP3/POP3S, LMTP/LMTPS and ManageSieve proxying
- Nauthilus-backed authentication over HTTP or gRPC
- director-owned routing and backend selection
- Redis-backed session affinity and runtime coordination
- backend health, maintenance, runtime drains and placement overrides
- an OpenAPI-based REST control API and
nauthilus-directorctl - metrics, structured logging and OpenTelemetry tracing
The demo stack includes Dovecot backend shards and exercises real IMAP, LMTP, POP3 and ManageSieve paths, so feedback from Dovecot operators would be especially useful.
Related to this, Nauthilus itself has recently been released as version 3.0.0. Nauthilus is the central authentication and policy engine in this setup: it provides centralized authentication and identity handling for mail and web workloads, LDAP-backed or Lua-driven policy decisions, OIDC/SAML IdP functionality, MFA support, and Redis-backed state handling. In the director architecture, Nauthilus remains the authentication and policy authority, while nauthilus-director owns concrete backend placement and proxy lifecycle decisions.
Project links:
- nauthilus-director: https://github.com/croessner/nauthilus-director
- Nauthilus: https://github.com/croessner/nauthilus
- Documentation / website: https://nauthilus.org
The director is still young, so I would be interested in feedback from people running Dovecot-backed infrastructures, especially around operational workflows, backend maintenance, migration scenarios and protocol behavior. The director is still in beta.
Best regards,
Christian Rößner
Rößner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Hi,
I would like to announce nauthilus-director for the first time on this
list.
nauthilus-director is an open-source mail protocol director and
transparent proxy for Nauthilus-backed mail deployments. It sits in front
of stateful mail backends, authenticates frontend sessions through
Nauthilus, resolves routing and placement inside the director, selects
healthy backend services, keeps active user affinity in Redis, and then
proxies the established connection to the selected backend.
The current focus is on deployments where backend placement, maintenance,
drains, user movement and session affinity need to be explicit, observable
and controllable. The director is not a mailbox server and not a
general-purpose load balancer; it owns the narrow director
responsibilities between clients, Nauthilus and backend mail services.
Current capabilities include:
- IMAP/IMAPS, POP3/POP3S, LMTP/LMTPS and ManageSieve proxying
- Nauthilus-backed authentication over HTTP or gRPC
- director-owned routing and backend selection
- Redis-backed session affinity and runtime coordination
- backend health, maintenance, runtime drains and placement overrides
- an OpenAPI-based REST control API and
nauthilus-directorctl - metrics, structured logging and OpenTelemetry tracing
The demo stack includes Dovecot backend shards and exercises real IMAP,
LMTP, POP3 and ManageSieve paths, so feedback from Dovecot operators would
be especially useful.
Related to this, Nauthilus itself has recently been released as version
3.0.0. Nauthilus is the central authentication and policy engine in this
setup: it provides centralized authentication and identity handling for
mail and web workloads, LDAP-backed or Lua-driven policy decisions,
OIDC/SAML IdP functionality, MFA support, and Redis-backed state handling.
In the director architecture, Nauthilus remains the authentication and
policy authority, while
nauthilus-directorowns concrete backend placement and proxy lifecycle decisions. Project links: - nauthilus-director: https://github.com/croessner/nauthilus-director
- Nauthilus: https://github.com/croessner/nauthilus
Documentation / website: https://nauthilus.org The director is still young, so I would be interested in feedback from people running Dovecot-backed infrastructures, especially around operational workflows, backend maintenance, migration scenarios and protocol behavior. The director is still in beta. Best regards, Christian Roessner
Roessner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
Wow, Christian! Congrats!
This replaces the old director and even goes further as it allows to route single protocols per identity during migration. Very nice!
And… I've seen you also added a complete Director Demo Stack to <https://github.com/croessner/nauthilus-director/tree/main/contrib/demo-stack>, which contains not only dovecot, but also Postfix and even stalwart.
Very, very fine move!
Thanks,
p@rick
- Christian Rößner via dovecot <lists@mlserv.org>:
Hi, I would like to announce
nauthilus-directorfor the first time on this list.nauthilus-directoris an open-source mail protocol director and transparent proxy for Nauthilus-backed mail deployments. It sits in front of stateful mail backends, authenticates frontend sessions through Nauthilus, resolves routing and placement inside the director, selects healthy backend services, keeps active user affinity in Redis, and then proxies the established connection to the selected backend. The current focus is on deployments where backend placement, maintenance, drains, user movement and session affinity need to be explicit, observable and controllable. The director is not a mailbox server and not a general-purpose load balancer; it owns the narrow director responsibilities between clients, Nauthilus and backend mail services. Current capabilities include:
- IMAP/IMAPS, POP3/POP3S, LMTP/LMTPS and ManageSieve proxying
- Nauthilus-backed authentication over HTTP or gRPC
- director-owned routing and backend selection
- Redis-backed session affinity and runtime coordination
- backend health, maintenance, runtime drains and placement overrides
- an OpenAPI-based REST control API and
nauthilus-directorctl- metrics, structured logging and OpenTelemetry tracing The demo stack includes Dovecot backend shards and exercises real IMAP, LMTP, POP3 and ManageSieve paths, so feedback from Dovecot operators would be especially useful. Related to this, Nauthilus itself has recently been released as version 3.0.0. Nauthilus is the central authentication and policy engine in this setup: it provides centralized authentication and identity handling for mail and web workloads, LDAP-backed or Lua-driven policy decisions, OIDC/SAML IdP functionality, MFA support, and Redis-backed state handling. In the director architecture, Nauthilus remains the authentication and policy authority, while
nauthilus-directorowns concrete backend placement and proxy lifecycle decisions. Project links:- nauthilus-director: https://github.com/croessner/nauthilus-director
- Nauthilus: https://github.com/croessner/nauthilus
Documentation / website: https://nauthilus.org The director is still young, so I would be interested in feedback from people running Dovecot-backed infrastructures, especially around operational workflows, backend maintenance, migration scenarios and protocol behavior. The director is still in beta. Best regards, Christian Roessner
Roessner-Network-Solutions Zertifizierter ITSiBe / CISO Marburger Str. 70a, 36304 Alsfeld Mobil: +49 171 9905345 USt-IdNr.: DE225643613, https://roessner.website PGP fingerprint: 658D 1342 B762 F484 2DDF 1E88 38A5 4346 D727 94E5
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
-- [*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
- Benny Pedersen via dovecot <me@junc.eu>:
Patrick Ben Koetter via dovecot skrev den 2026-06-17 11:32:
Very, very fine move!
Authentication-Results SUBMISSION465; auth=pass smtp.auth=p@sys4.de smtp.mailfrom=p@sys4.de
is SUBMISSION465 fqdn ?
Doh!
It's the darn Postfix milter_macro_daemon_name:
echo ~ # grep SUBMISSION465 /etc/postfix/master.cf -o milter_macro_daemon_name=SUBMISSION465 -o milter_macro_daemon_name=SUBMISSION465
No idea how to fix that ATM.
i just ask for consensus :=)
:)
p@rick
-- [*] sys4 AG
https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
participants (3)
-
Benny Pedersen
-
Christian Rößner
-
Patrick Ben Koetter