dovecot
Threads by month
- ----- 2026 -----
- May
- April
- March
- February
- January
- ----- 2025 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2024 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2002 -----
- December
- November
- October
- September
- August
- July
April 2026
- 44 participants
- 42 discussions
01 Apr '26
I am using dovecot 2.4.2 (almost) with new config language and I have a working configuration. However, the check for disabled users throws permanently errors in the log file, whenever a user is missing the ldap attribute for disabled. This is - in my view - due to a misfunction of Filter "default".
passdb ldap {
driver = ldap
ldap_bind = yes
ldap_filter = (&(|(objectClass=posixAccount)(objectClass=mailAccount))(uid=%{user}))
fields {
user = %{ldap:uid}
nologin = %{ldap:shadowInactive | default(null)}
reason = The account for this email address is disabled.
}
}
This results in the following log line:
2026-03-31T00:46:31.102690+02:00 mailserver dovecot: auth(test,ipv4,sasl:plain)<YE81n0VOVuofEeSD>: Error: ldap: auth_passdb_post settings: Failed to parse configuration: Failed to expand passdb_fields/nologin setting variables: ldap: No such attribute 'shadowinactive'
The right behaviour would be no logging on login success. Because the Filter "default" is intended to suppress any errors ("When value is missing or empty, you can use the default filter to provide value. Missing variables will cause errors and must be negated with default. This does not apply to all providers, some providers return empty when value is missing.").
https://doc.dovecot.org/2.4.2/core/settings/variables.html#variable-expansi…
As you may have seen I had to borrow null-value from sql db config also to make nologin ignoring a non present attribute. This is undocumented obviously. Instead, a non-working tip is provided ("Changed: 2.4.0 Extra fields can now also be set to empty string, "). However, the following does not work: "nologin = {ldap:shadowinactive | default("")}".
https://doc.dovecot.org/2.4.2/core/settings/variables.html
Also, the documentation is missing/hiding the part which explains that "default()" can be used to avoid error logs. PR regarding the documentation source is sent already. See "Fails if the attribute is not present, unless the ` <missing part>"
https://doc.dovecot.org/2.4.0/core/config/auth/databases/ldap.html#ldap-spe…
Is there another way to verify if account is disabled?
--
Johannes Nohl
postmaster i-t-cloud
--
Johannes Nohl
postmaster(a)i-t-cloud.de
I am using dovecot 2.4.2 (almost) with new config language and I have a
working configuration. However, the check for disabled users throws
permanently errors in the log file, whenever a user is missing the ldap
attribute for disabled. This is - in my view - due to a misfunction of
Filter "default".
passdb ldap {
driver = ldap
ldap_bind = yes
ldap_filter =
(&(|(objectClass=posixAccount)(objectClass=mailAccount))(uid=%{user}))
fields {
user = %{ldap:uid}
nologin = %{ldap:shadowInactive | default(null)}
reason = The account for this email address is disabled.
}
}
This results in the following log line:
*2026-03-31T00:46:31.102690+02:00 mailserver dovecot:
auth(test,ipv4,sasl:plain)<YE81n0VOVuofEeSD>: Error: ldap:
auth_passdb_post settings: Failed to parse configuration: Failed to expand
passdb_fields/nologin setting variables: ldap: No such attribute
'shadowinactive'
The right behaviour would be no logging on login success. Because the
Filter "default" is intended to suppress any errors ("When value is
missing or empty, you can use the default filter to provide value. Missing
variables will cause errors and must be negated with default. This does
not apply to all providers, some providers return empty when value is
missing.").
https://doc.dovecot.org/2.4.2/core/settings/variables.html#variable-expansi…
As you may have seen I had to borrow null-value from sql db config also to
make nologin ignoring a non present attribute. This is undocumented
obviously. Instead, a non-working tip is provided ("Changed: 2.4.0 Extra
fields can now also be set to empty string, "). However, the following
does not work: "nologin = {ldap:shadowinactive | default("")}".
https://doc.dovecot.org/2.4.2/core/settings/variables.html
Also, the documentation is missing/hiding the part which explains that
"default()" can be used to avoid error logs. PR regarding the
documentation source is sent already. See "Fails if the attribute is not
present, unless the ` <missing part>"
https://doc.dovecot.org/2.4.0/core/config/auth/databases/ldap.html#ldap-spe…
Is there another way to verify if account is disabled?
--
Johannes Nohl
postmaster i-t-cloud
--
Johannes Nohl
postmaster(a)i-t-cloud.de
2
1
Dovecot 2.4.3 crashes with SIGSEGV in indexer-worker and lmtp during FTS
Solr indexing. The crash is a use-after-free triggered when the HTTP
client does a DNS lookup for the Solr host.
Environment:
- Dovecot 2.4.3 (Alpine 3.23 / musl)
- Linux x86_64
- Filesystem: maildir on ZFS
- Solr 10.0.0
- fts_solr plugin with DNS-based Solr URL
dovecot -n:
# 2.4.3 (e278b1e09b): /etc/dovecot/dovecot.conf
# Pigeonhole version 2.4.3 (0bf9ee48)
# OS: Linux 6.12.74+deb13+1-amd64 x86_64
dovecot_config_version = 2.4.0
auth_mechanisms = oauthbearer xoauth2
dovecot_storage_version = 2.4.0
fts_autoindex = yes
fts_search_add_missing = yes
mail_always_cache_fields = date.save
mail_driver = maildir
mail_plugins {
fts = yes
fts_solr = yes
}
protocols = imap lmtp sieve
ssl = required
fts solr {
url = http://solr.example.com/solr/dovecot
}
(LDAP userdb/passdb, pigeonhole sieve, imapsieve for spam learning, and
oauth2 passdb omitted)
How to reproduce:
The crash occurs in the indexer-worker when processing multiple user
mailboxes sequentially for FTS indexing, using a DNS hostname for the
Solr URL.
Steps:
1. Configure fts_solr with a DNS-based URL (not an IP address)
2. Have the indexer-worker process mailboxes for more than one user
(e.g. fts_autoindex = yes with multiple users, or manual doveadm index
-A)
3. The first user session completes successfully. On the second user
session, the indexer-worker crashes with SIGSEGV during the DNS lookup
for the Solr host.
Reproduces reliably on musl (Alpine) due to aggressive memory reuse.
Likely also affects glibc but may not crash immediately due to delayed
reuse of freed memory.
Root cause:
The solr_http_client singleton outlives the user session that created
it. Its event chain holds a ref on the mail_storage_service_user event,
keeping it alive after the user is freed. The SETTINGS_EVENT_INSTANCE on
that event still points to the already-freed settings_instance. On the
next user session, dns_lookup() walks the stale event chain and
dereferences the dangling pointer in settings_instance_get().
Stack trace (from core dump, debug build with musl-dbg):
#0 strlen(s=0x415641d189485741) -- SIGSEGV, freed/reused
memory
#1 p_strdup() strfuncs.c:56
#2 event_add_str(key="protocol", value=...) lib-event.c:1099
#3 settings_instance_get() settings.c:2521
#4 settings_get_real() settings.c:2706
#5 settings_get_full() settings.c:2915
#6 settings_get(dns_client_setting_parser_info) settings.c:2976
#7 dns_client_init() dns-lookup.c:465
#8 dns_client_init_handle_failure() dns-lookup.c:317
#9 dns_lookup("solr.example.com") dns-lookup.c:337
#10 http_client_host_shared_lookup() http-client-host.c:166
#11 http_client_host_shared_refresh() http-client-host.c:195
#12-#19 http_client queue/host/request submit chain
#20 http_client_request_continue_payload()
http-client-request.c:1170
#21 http_client_request_send_payload()
http-client-request.c:1261
#22 solr_connection_post_more() solr-connection.c:269
Proposed fix:
Destroy solr_http_client in solr_connection_deinit() so it is recreated
with a fresh event chain on the next user session:
--- a/src/plugins/fts-solr/solr-connection.c
+++ b/src/plugins/fts-solr/solr-connection.c
@@ -117,6 +117,8 @@ void solr_connection_deinit(struct solr_connection
**_conn)
*_conn = NULL;
event_unref(&conn->event);
+ if (solr_http_client != NULL)
+ http_client_deinit(&solr_http_client);
i_free(conn->http_host);
i_free(conn->http_base_url);
I've been running for few days with the patch applied. FTS indexing
across multiple user sessions completes without crashes using a
DNS-based Solr URL.
Please let me know if there's anything else that would be helpful. The
core files have sensitive information so I've omitted them from the
report.
-Nick
Dovecot 2.4.3 crashes with SIGSEGV in indexer-worker and lmtp during FTS
Solr indexing. The crash is a use-after-free triggered when the HTTP
client does a DNS lookup for the Solr host.
Environment:
- Dovecot 2.4.3 (Alpine 3.23 / musl)
- Linux x86_64
- Filesystem: maildir on ZFS
- Solr 10.0.0
- fts_solr plugin with DNS-based Solr URL
dovecot -n:
# 2.4.3 (e278b1e09b): /etc/dovecot/dovecot.conf
# Pigeonhole version 2.4.3 (0bf9ee48)
# OS: Linux 6.12.74+deb13+1-amd64 x86_64
dovecot_config_version = 2.4.0
auth_mechanisms = oauthbearer xoauth2
dovecot_storage_version = 2.4.0
fts_autoindex = yes
fts_search_add_missing = yes
mail_always_cache_fields = date.save
mail_driver = maildir
mail_plugins {
fts = yes
fts_solr = yes
}
protocols = imap lmtp sieve
ssl = required
fts solr {
url = http://solr.example.com/solr/dovecot
}
(LDAP userdb/passdb, pigeonhole sieve, imapsieve for spam learning, and
oauth2 passdb omitted)
How to reproduce:
The crash occurs in the indexer-worker when processing multiple user
mailboxes sequentially for FTS indexing, using a DNS hostname for the Solr
URL.
Steps:
1. Configure fts_solr with a DNS-based URL (not an IP address)
2. Have the indexer-worker process mailboxes for more than one user (e.g.
fts_autoindex = yes with multiple users, or manual doveadm index -A)
3. The first user session completes successfully. On the second user
session, the indexer-worker crashes with SIGSEGV during the DNS lookup for
the Solr host.
Reproduces reliably on musl (Alpine) due to aggressive memory reuse.
Likely also affects glibc but may not crash immediately due to delayed
reuse of freed memory.
Root cause:
The solr_http_client singleton outlives the user session that created it.
Its event chain holds a ref on the mail_storage_service_user event,
keeping it alive after the user is freed. The SETTINGS_EVENT_INSTANCE on
that event still points to the already-freed settings_instance. On the
next user session, dns_lookup() walks the stale event chain and
dereferences the dangling pointer in settings_instance_get().
Stack trace (from core dump, debug build with musl-dbg):
#0 strlen(s=0x415641d189485741) -- SIGSEGV, freed/reused
memory
#1 p_strdup() strfuncs.c:56
#2 event_add_str(key="protocol", value=...) lib-event.c:1099
#3 settings_instance_get() settings.c:2521
#4 settings_get_real() settings.c:2706
#5 settings_get_full() settings.c:2915
#6 settings_get(dns_client_setting_parser_info) settings.c:2976
#7 dns_client_init() dns-lookup.c:465
#8 dns_clien t_init_handle_failure() dns-lookup.c:317
#9 dns_lookup("solr.example.com") dns-lookup.c:337
#10 http_client_host_shared_lookup() http-client-host.c:166
#11 http_client_host_shared_refresh() http-client-host.c:195
#12-#19 http_client queue/host/request submit chain
#20 http_client_request_continue_payload() http-client-request.c:1170
#21 http_client_request_send_payload() http-client-request.c:1261
#22 solr_connection_post_more() solr-connection.c:269
Proposed fix:
Destroy solr_http_client in solr_connection_deinit() so it is recreated
with a fresh event chain on the next user session:
--- a/src/plugins/fts-solr/solr-connection.c
+++ b/src/plugins/fts-solr/solr-connection.c
@@ -117,6 +117,8 @@ void solr_connection_deinit(struct solr_connection
**_conn)
*_conn = NULL;
event_unref(&conn->event);
+ if (solr_http_client != NULL)
+ http_client_deinit(&solr_http_client);
i_free(conn->http_host);
i_free(conn->http_base_url);
I've been running for few days with the patch applied. FTS indexing across
multiple user sessions completes without crashes using a DNS-based Solr
URL.
Please let me know if there's anything else that would be helpful. The
core files have sensitive information so I've omitted them from the
report.
-Nick
1
0