Hi everyone!
Due to a severe bug in doveadm deduplicate, we are releasing patch release 2.3.19.1. Please find it at locations below:
https://dovecot.org/releases/2.3/dovecot-2.3.19.1.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.19.1.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot
Aki Tuomi Open-Xchange oy
- doveadm deduplicate: Non-duplicate mails were deleted. v2.3.19 regression.
- auth: Crash would occur when iterating multiple backends. Fixes: Panic: file userdb-blocking.c: line 125 (userdb_blocking_iter_next): assertion failed: (ctx->conn != NULL)
Hi Aki,
Am 14.06.22 um 12:24 schrieb Aki Tuomi:
Hi everyone!
Due to a severe bug in doveadm deduplicate, we are releasing patch release 2.3.19.1. Please find it at locations below:
https://dovecot.org/releases/2.3/dovecot-2.3.19.1.tar.gz https://dovecot.org/releases/2.3/dovecot-2.3.19.1.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot
Aki Tuomi Open-Xchange oy
- doveadm deduplicate: Non-duplicate mails were deleted. v2.3.19 regression.
- auth: Crash would occur when iterating multiple backends. Fixes: Panic: file userdb-blocking.c: line 125 (userdb_blocking_iter_next): assertion failed: (ctx->conn != NULL)
As the above Panic is fixed I tried again (see my attached mail to the 2.3.19 release) and I can confirm to no longer get the Panic, BUT authentication is NOT working either :(
Reverting back to a container with Dovecot 2.3.16, get's everything working again.
We use a hourly updated local SQLight database and a dict for user- and passdb.
Is the usage of multiple backends no longer supported, or did something in that regard changed between 2.3.16 and 2.3.19.1?
Here's the relevant part of my config (full doveadm config -n is attached):
userdb { args = /etc/dovecot/dovecot-sql.conf driver = sql } userdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = dict } passdb { args = /etc/dovecot/dovecot-dict-master-auth.conf driver = dict master = yes } passdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = dict }
The SQLight DB is used for listing all users and to keep the replication running, even if the dict is unavailable.
Any ideas what might be the cause or how to narrow the problem down?
Ralf
-- Ralf Becker EGroupware GmbH [www.egroupware.org] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 631 31657-0
On 20. Jun 2022, at 10.03, Ralf Becker rb@egroupware.org wrote:
Fixes: Panic: file userdb-blocking.c: line 125 (userdb_blocking_iter_next): assertion failed: (ctx->conn != NULL)
As the above Panic is fixed I tried again (see my attached mail to the 2.3.19 release) and I can confirm to no longer get the Panic, BUT authentication is NOT working either :(
Reverting back to a container with Dovecot 2.3.16, get's everything working again.
We use a hourly updated local SQLight database and a dict for user- and passdb.
Is the usage of multiple backends no longer supported, or did something in that regard changed between 2.3.16 and 2.3.19.1?
We have lots of tests using multiple backends for authentication, and lots of people are using many passdbs/userdbs in production. I was only aware of iteration being broken with multiple userdbs, since that's not used so much. And we added a test to verify that multiple userdb iteration is actually returning results from both userdbs, so that shouldn't be completely broken either.
So I'd need more details of what exactly goes wrong and how. Is it the authentication or the iteration that is now broken? Logs with auth_debug=yes would likely help. Also:
Here's the relevant part of my config (full doveadm config -n is attached):
userdb { args = /etc/dovecot/dovecot-sql.conf driver = sql } userdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = dict } passdb { args = /etc/dovecot/dovecot-dict-master-auth.conf driver = dict master = yes } passdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = dict }
What do these external conf files contain?
Hi Timo,
Am 20.06.22 um 12:17 schrieb Timo Sirainen:
On 20. Jun 2022, at 10.03, Ralf Becker rb@egroupware.org wrote:
Fixes: Panic: file userdb-blocking.c: line 125 (userdb_blocking_iter_next): assertion failed: (ctx->conn != NULL) As the above Panic is fixed I tried again (see my attached mail to the 2.3.19 release) and I can confirm to no longer get the Panic, BUT authentication is NOT working either :(
Reverting back to a container with Dovecot 2.3.16, get's everything working again.
We use a hourly updated local SQLight database and a dict for user- and passdb.
Is the usage of multiple backends no longer supported, or did something in that regard changed between 2.3.16 and 2.3.19.1? We have lots of tests using multiple backends for authentication, and lots of people are using many passdbs/userdbs in production. I was only aware of iteration being broken with multiple userdbs, since that's not used so much. And we added a test to verify that multiple userdb iteration is actually returning results from both userdbs, so that shouldn't be completely broken either.
So I'd need more details of what exactly goes wrong and how. Is it the authentication or the iteration that is now broken?
I only seen authentication errors in doveadm log errors and our montioring trying to access the backend with user credentials.
Logs with auth_debug=yes would likely help.
I will get you the logs tonight, don't want to switch (one leg of) the production system during daytime. I can then also try eg. doveadm user -A to check the iteration.
Also:
Here's the relevant part of my config (full doveadm config -n is attached):
userdb { args = /etc/dovecot/dovecot-sql.conf driver = sql } userdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = dict } passdb { args = /etc/dovecot/dovecot-dict-master-auth.conf driver = dict master = yes } passdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = dict } What do these external conf files contain?
/etc/dovecot/dovecot-sql.conf:
driver = sqlite connect = /etc/dovecot/users.sqlite
#password_query = SELECT userid AS username, domain, password
# FROM users WHERE userid = '%n' AND domain = '%d'
#user_query = SELECT home, uid, gid FROM users WHERE userid = '%n' AND
domain = '%d'
# return no userdb, as db contains only user-names
#user_query = SELECT home,NULL AS uid,NULL AS gid FROM users WHERE
userid = '%n' AND domain = '%d'
user_query = SELECT home,NULL AS uid,NULL AS gid,
'*:bytes='||(quota*1048576) AS quota_rule,
userid||'@'||domain AS master_user,
LOWER(REPLACE(groups||',', ',', '@'||domain||',')) AS acl_groups
FROM users WHERE userid = '%n' AND domain = '%d'
# For using doveadm -A: iterate_query = SELECT userid AS username, domain FROM users
/etc/dovecot/dovecot-dict-auth.conf:
uri = proxy:/var/run/dovecot_auth_proxy/socket:somewhere #uri = proxy:10.44.99.180:2001:somewhere
password_key = passdb/%u/%w user_key = userdb/%u iterate_disable = yes #iterate_disable = no #iterate_prefix = userdb/ default_pass_scheme = md5
/etc/dovecot/dovecot-dict-master-auth.conf:
uri = proxy:/var/run/dovecot_auth_proxy/socket:somewhere #uri = proxy:10.44.99.180:2001:somewhere
#password_key = master/%{login_domain}/%u/%w password_key = master/%{login_user}/%u/%w iterate_disable = yes default_pass_scheme = md5
Thanks :)
Ralf
-- Ralf Becker EGroupware GmbH [www.egroupware.org] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 631 31657-0
Hi Timo,
attached is the log with auth_debug=true from the starting process and running "doveadm auth test ralfimaptest@egroupware.org" and one other regular passdb lookup.
I replaced passwords and the customer email with XXXXXX.
I also run "doveadm user '*'" to test the iteration, which worked.
Ralf
Hi Timo, > > Am 20.06.22 um 12:17 schrieb Timo Sirainen: >> On 20. Jun 2022, at 10.03, Ralf Becker rb@egroupware.org wrote: >>>> Fixes: Panic: file userdb-blocking.c: line 125 >>>> (userdb_blocking_iter_next): assertion failed: (ctx->conn != >>>> NULL) >>> As the above Panic is fixed I tried again (see my attached mail >>> to the 2.3.19 release) and I can confirm to no longer get the >>> Panic, BUT authentication is NOT working either :( >>> >>> Reverting back to a container with Dovecot 2.3.16, get's >>> everything working again. >>> >>> We use a hourly updated local SQLight database and a dict for >>> user- and passdb. >>> >>> Is the usage of multiple backends no longer supported, or did >>> something in that regard changed between 2.3.16 and 2.3.19.1? >> We have lots of tests using multiple backends for authentication, >> and lots of people are using many passdbs/userdbs in production. I >> was only aware of iteration being broken with multiple userdbs, >> since that's not used so much. And we added a test to verify that >> multiple userdb iteration is actually returning results from both >> userdbs, so that shouldn't be completely broken either. >> >> So I'd need more details of what exactly goes wrong and how. Is it >> the authentication or the iteration that is now broken? > > I only seen authentication errors in doveadm log errors and our > montioring trying to access the backend with user credentials.
Logs with auth_debug=yes would likely help. > > I will get you the logs tonight, don't want to switch (one leg of) > the production system during daytime. I can then also try eg. doveadm > user -A to check the iteration. > >> Also: >> >>> Here's the relevant part of my config (full doveadm config -n is >>> attached): >>> >>> userdb { args = /etc/dovecot/dovecot-sql.conf driver = sql } >>> userdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = >>> dict } passdb { args = /etc/dovecot/dovecot-dict-master-auth.conf driver = dict master = yes } passdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = dict } >> What do these external conf files contain? > > /etc/dovecot/dovecot-sql.conf: > > driver = sqlite connect = /etc/dovecot/users.sqlite > > #password_query = SELECT userid AS username, domain, password \ # > FROM users WHERE userid = '%n' AND domain = '%d' #user_query = SELECT > home, uid, gid FROM users WHERE userid = '%n' AND domain = '%d' # > return no userdb, as db contains only user-names #user_query = SELECT > home,NULL AS uid,NULL AS gid FROM users WHERE userid = '%n' AND > domain = '%d' user_query = SELECT home,NULL AS uid,NULL AS gid, \ > '*:bytes='||(quota*1048576) AS quota_rule, \ userid||'@'||domain AS > master_user, \ LOWER(REPLACE(groups||',', ',', '@'||domain||',')) AS > acl_groups \ FROM users WHERE userid = '%n' AND domain = '%d' > > # For using doveadm -A: iterate_query = SELECT userid AS username, > domain FROM users > > /etc/dovecot/dovecot-dict-auth.conf: > > uri =
Am 20.06.22 um 13:32 schrieb Ralf Becker: proxy:/var/run/dovecot_auth_proxy/socket:somewhere #uri = > proxy:10.44.99.180:2001:somewhere > > password_key = passdb/%u/%w user_key = userdb/%u iterate_disable = > yes #iterate_disable = no #iterate_prefix = userdb/ > default_pass_scheme = md5 > > /etc/dovecot/dovecot-dict-master-auth.conf: > > uri = proxy:/var/run/dovecot_auth_proxy/socket:somewhere #uri = > proxy:10.44.99.180:2001:somewhere > > #password_key = master/%{login_domain}/%u/%w password_key = > master/%{login_user}/%u/%w iterate_disable = yes default_pass_scheme > = md5 > > Thanks :) > > Ralf >
Ralf Becker EGroupware GmbH [www.egroupware.org] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 631 31657-0
Hi Timo,
attached is the log with auth_debug=true from the starting process and running "doveadm auth test ralfimaptest@egroupware.org" and one other regular passdb lookup.
I replaced passwords and the customer email with XXXXXX.
I also run "doveadm user '*'" to test the iteration, which worked.
Ralf
Am 20.06.22 um 13:32 schrieb Ralf Becker:
Hi Timo,
Am 20.06.22 um 12:17 schrieb Timo Sirainen:
Fixes: Panic: file userdb-blocking.c: line 125 (userdb_blocking_iter_next): assertion failed: (ctx->conn != NULL) As the above Panic is fixed I tried again (see my attached mail to the 2.3.19 release) and I can confirm to no longer get the Panic, BUT authentication is NOT working either :(
Reverting back to a container with Dovecot 2.3.16, get's everything working again.
We use a hourly updated local SQLight database and a dict for user- and passdb.
Is the usage of multiple backends no longer supported, or did something in that regard changed between 2.3.16 and 2.3.19.1? We have lots of tests using multiple backends for authentication, and lots of people are using many passdbs/userdbs in production. I was only aware of iteration being broken with multiple userdbs, since
On 20. Jun 2022, at 10.03, Ralf Becker rb@egroupware.org wrote: that's not used so much. And we added a test to verify that multiple userdb iteration is actually returning results from both userdbs, so that shouldn't be completely broken either.
So I'd need more details of what exactly goes wrong and how. Is it the authentication or the iteration that is now broken?
I only seen authentication errors in doveadm log errors and our montioring trying to access the backend with user credentials.
Logs with auth_debug=yes would likely help.
I will get you the logs tonight, don't want to switch (one leg of) the production system during daytime. I can then also try eg. doveadm user -A to check the iteration.
Also:
Here's the relevant part of my config (full doveadm config -n is attached):
userdb { args = /etc/dovecot/dovecot-sql.conf driver = sql } userdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = dict } passdb { args = /etc/dovecot/dovecot-dict-master-auth.conf driver = dict master = yes } passdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = dict } What do these external conf files contain?
/etc/dovecot/dovecot-sql.conf:
driver = sqlite connect = /etc/dovecot/users.sqlite
#password_query = SELECT userid AS username, domain, password
# FROM users WHERE userid = '%n' AND domain = '%d' #user_query = SELECT home, uid, gid FROM users WHERE userid = '%n' AND domain = '%d' # return no userdb, as db contains only user-names #user_query = SELECT home,NULL AS uid,NULL AS gid FROM users WHERE userid = '%n' AND domain = '%d' user_query = SELECT home,NULL AS uid,NULL AS gid,
'*:bytes='||(quota*1048576) AS quota_rule,
userid||'@'||domain AS master_user,
LOWER(REPLACE(groups||',', ',', '@'||domain||',')) AS acl_groups
FROM users WHERE userid = '%n' AND domain = '%d'# For using doveadm -A: iterate_query = SELECT userid AS username, domain FROM users
/etc/dovecot/dovecot-dict-auth.conf:
uri = proxy:/var/run/dovecot_auth_proxy/socket:somewhere #uri = proxy:10.44.99.180:2001:somewhere
password_key = passdb/%u/%w user_key = userdb/%u iterate_disable = yes #iterate_disable = no #iterate_prefix = userdb/ default_pass_scheme = md5
/etc/dovecot/dovecot-dict-master-auth.conf:
uri = proxy:/var/run/dovecot_auth_proxy/socket:somewhere #uri = proxy:10.44.99.180:2001:somewhere
#password_key = master/%{login_domain}/%u/%w password_key = master/%{login_user}/%u/%w iterate_disable = yes default_pass_scheme = md5
Thanks :)
Ralf
-- Ralf Becker EGroupware GmbH [www.egroupware.org] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 631 31657-0
Oh, I think your problem is that you've implemented a separate dict-server. And looks like we forgot to mention in v2.3.17 release notes that the dict protocol had to be changed due to some improvements. Your dict server should verify that the VERSION line's major version number is as expected, and error out if not. That would have made it easier to notice this change. See https://doc.dovecot.org/developer_manual/design/dict_protocol/ for the new protocol - the only relevant change I think is that a "<tab><username>" is appended to each lookup command, and since these are shared/ key lookups it means there is no username, and you just need to ignore the trailing <tab> at the end of L-command lines.
On 21. Jun 2022, at 0.47, Ralf Becker rb@egroupware.org wrote:
Hi Timo,
attached is the log with auth_debug=true from the starting process and running "doveadm auth test ralfimaptest@egroupware.org" and one other regular passdb lookup.
I replaced passwords and the customer email with XXXXXX.
I also run "doveadm user '*'" to test the iteration, which worked.
Ralf
Am 20.06.22 um 13:32 schrieb Ralf Becker:
Hi Timo,
Am 20.06.22 um 12:17 schrieb Timo Sirainen:
On 20. Jun 2022, at 10.03, Ralf Becker rb@egroupware.org wrote:
Fixes: Panic: file userdb-blocking.c: line 125 (userdb_blocking_iter_next): assertion failed: (ctx->conn != NULL) As the above Panic is fixed I tried again (see my attached mail to the 2.3.19 release) and I can confirm to no longer get the Panic, BUT authentication is NOT working either :(
Reverting back to a container with Dovecot 2.3.16, get's everything working again.
We use a hourly updated local SQLight database and a dict for user- and passdb.
Is the usage of multiple backends no longer supported, or did something in that regard changed between 2.3.16 and 2.3.19.1? We have lots of tests using multiple backends for authentication, and lots of people are using many passdbs/userdbs in production. I was only aware of iteration being broken with multiple userdbs, since that's not used so much. And we added a test to verify that multiple userdb iteration is actually returning results from both userdbs, so that shouldn't be completely broken either.
So I'd need more details of what exactly goes wrong and how. Is it the authentication or the iteration that is now broken?
I only seen authentication errors in doveadm log errors and our montioring trying to access the backend with user credentials.
Logs with auth_debug=yes would likely help.
I will get you the logs tonight, don't want to switch (one leg of) the production system during daytime. I can then also try eg. doveadm user -A to check the iteration.
Also:
Here's the relevant part of my config (full doveadm config -n is attached):
userdb { args = /etc/dovecot/dovecot-sql.conf driver = sql } userdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = dict } passdb { args = /etc/dovecot/dovecot-dict-master-auth.conf driver = dict master = yes } passdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = dict } What do these external conf files contain?
/etc/dovecot/dovecot-sql.conf:
driver = sqlite connect = /etc/dovecot/users.sqlite
#password_query = SELECT userid AS username, domain, password
# FROM users WHERE userid = '%n' AND domain = '%d' #user_query = SELECT home, uid, gid FROM users WHERE userid = '%n' AND domain = '%d' # return no userdb, as db contains only user-names #user_query = SELECT home,NULL AS uid,NULL AS gid FROM users WHERE userid = '%n' AND domain = '%d' user_query = SELECT home,NULL AS uid,NULL AS gid,
'*:bytes='||(quota*1048576) AS quota_rule,
userid||'@'||domain AS master_user,
LOWER(REPLACE(groups||',', ',', '@'||domain||',')) AS acl_groups
FROM users WHERE userid = '%n' AND domain = '%d'# For using doveadm -A: iterate_query = SELECT userid AS username, domain FROM users
/etc/dovecot/dovecot-dict-auth.conf:
uri = proxy:/var/run/dovecot_auth_proxy/socket:somewhere #uri = proxy:10.44.99.180:2001:somewhere
password_key = passdb/%u/%w user_key = userdb/%u iterate_disable = yes #iterate_disable = no #iterate_prefix = userdb/ default_pass_scheme = md5
/etc/dovecot/dovecot-dict-master-auth.conf:
uri = proxy:/var/run/dovecot_auth_proxy/socket:somewhere #uri = proxy:10.44.99.180:2001:somewhere
#password_key = master/%{login_domain}/%u/%w password_key = master/%{login_user}/%u/%w iterate_disable = yes default_pass_scheme = md5
Thanks :)
Ralf
-- Ralf Becker EGroupware GmbH [www.egroupware.org] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 631 31657-0
Also, nowadays Lua would be a better way to do custom authentication and we're more careful not to break that.
On 21. Jun 2022, at 13.47, Timo Sirainen timo@sirainen.com wrote:
Oh, I think your problem is that you've implemented a separate dict-server. And looks like we forgot to mention in v2.3.17 release notes that the dict protocol had to be changed due to some improvements. Your dict server should verify that the VERSION line's major version number is as expected, and error out if not. That would have made it easier to notice this change. See https://doc.dovecot.org/developer_manual/design/dict_protocol/ for the new protocol - the only relevant change I think is that a "<tab><username>" is appended to each lookup command, and since these are shared/ key lookups it means there is no username, and you just need to ignore the trailing <tab> at the end of L-command lines.
On 21. Jun 2022, at 0.47, Ralf Becker rb@egroupware.org wrote:
Hi Timo,
attached is the log with auth_debug=true from the starting process and running "doveadm auth test ralfimaptest@egroupware.org" and one other regular passdb lookup.
I replaced passwords and the customer email with XXXXXX.
I also run "doveadm user '*'" to test the iteration, which worked.
Ralf
Am 20.06.22 um 13:32 schrieb Ralf Becker:
Hi Timo,
Am 20.06.22 um 12:17 schrieb Timo Sirainen:
On 20. Jun 2022, at 10.03, Ralf Becker rb@egroupware.org wrote:
Fixes: Panic: file userdb-blocking.c: line 125 (userdb_blocking_iter_next): assertion failed: (ctx->conn != NULL) As the above Panic is fixed I tried again (see my attached mail to the 2.3.19 release) and I can confirm to no longer get the Panic, BUT authentication is NOT working either :(
Reverting back to a container with Dovecot 2.3.16, get's everything working again.
We use a hourly updated local SQLight database and a dict for user- and passdb.
Is the usage of multiple backends no longer supported, or did something in that regard changed between 2.3.16 and 2.3.19.1? We have lots of tests using multiple backends for authentication, and lots of people are using many passdbs/userdbs in production. I was only aware of iteration being broken with multiple userdbs, since that's not used so much. And we added a test to verify that multiple userdb iteration is actually returning results from both userdbs, so that shouldn't be completely broken either.
So I'd need more details of what exactly goes wrong and how. Is it the authentication or the iteration that is now broken?
I only seen authentication errors in doveadm log errors and our montioring trying to access the backend with user credentials.
Logs with auth_debug=yes would likely help.
I will get you the logs tonight, don't want to switch (one leg of) the production system during daytime. I can then also try eg. doveadm user -A to check the iteration.
Also:
Here's the relevant part of my config (full doveadm config -n is attached):
userdb { args = /etc/dovecot/dovecot-sql.conf driver = sql } userdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = dict } passdb { args = /etc/dovecot/dovecot-dict-master-auth.conf driver = dict master = yes } passdb { args = /etc/dovecot/dovecot-dict-auth.conf driver = dict } What do these external conf files contain?
/etc/dovecot/dovecot-sql.conf:
driver = sqlite connect = /etc/dovecot/users.sqlite
#password_query = SELECT userid AS username, domain, password
# FROM users WHERE userid = '%n' AND domain = '%d' #user_query = SELECT home, uid, gid FROM users WHERE userid = '%n' AND domain = '%d' # return no userdb, as db contains only user-names #user_query = SELECT home,NULL AS uid,NULL AS gid FROM users WHERE userid = '%n' AND domain = '%d' user_query = SELECT home,NULL AS uid,NULL AS gid,
'*:bytes='||(quota*1048576) AS quota_rule,
userid||'@'||domain AS master_user,
LOWER(REPLACE(groups||',', ',', '@'||domain||',')) AS acl_groups
FROM users WHERE userid = '%n' AND domain = '%d'# For using doveadm -A: iterate_query = SELECT userid AS username, domain FROM users
/etc/dovecot/dovecot-dict-auth.conf:
uri = proxy:/var/run/dovecot_auth_proxy/socket:somewhere #uri = proxy:10.44.99.180:2001:somewhere
password_key = passdb/%u/%w user_key = userdb/%u iterate_disable = yes #iterate_disable = no #iterate_prefix = userdb/ default_pass_scheme = md5
/etc/dovecot/dovecot-dict-master-auth.conf:
uri = proxy:/var/run/dovecot_auth_proxy/socket:somewhere #uri = proxy:10.44.99.180:2001:somewhere
#password_key = master/%{login_domain}/%u/%w password_key = master/%{login_user}/%u/%w iterate_disable = yes default_pass_scheme = md5
Thanks :)
Ralf
-- Ralf Becker EGroupware GmbH [www.egroupware.org] Handelsregister HRB Kaiserslautern 3587 Geschäftsführer Birgit und Ralf Becker Leibnizstr. 17, 67663 Kaiserslautern, Germany Telefon +49 631 31657-0
participants (3)
-
Aki Tuomi
-
Ralf Becker
-
Timo Sirainen