Regression/Bug report: crypt_private_key_file (for crypt_global_private_key) no longer supports inline base64 (from userdb) in dev branch
Hi,
I’ve run into what appears to be a regression (or at least a behavioral change) in Dovecot 3.3.0+ / current HEAD regarding crypt_private_key_file handling for the crypt_global_private_key.
I don‘t use per-folder user keys but a global encryption key per user.
Previously, it was possible to provide the private key via userdb using an inline base64:-encoded PEM directly to the crypt_global_private_key_file and Dovecot would correctly parse and use it.
With the latest config scheme change, this no longer works, as you cannot really set named config variables from userdb. I did workaround by setting a custom userdb variable and setting the needed named/filter variables manually in the config file. To make it work, I had to enclose the config in a „protocol imap“ scope. The crypt_global_public_key_file is accessible from userdb (as it is not within a named filter scope), so inline-base64 works as with Dovecot 2.3+.
When using the following workaround to reach the scoped variables, Dovecot tries to load the file „inline:BASE64ENCODEDPEM“ as a literal filename (error open(inline:AB….C==) failed):
protocol imap { crypt_global_private_key user { crypt_private_key_file = %{userdb:private_key_file} crypt_private_key_password = %{userdb:private_key_password} } }
As a workaround, I now have to: • store the private key as a file (e.g. %{home}/privkey.pem) • pass only the password via userdb • inject the path indirectly via static config + userdb variables
This works, but is less elegant:
protocol imap { crypt_global_private_key user { crypt_private_key_file = %{home}/privkey.pem crypt_private_key_password = %{userdb:private_key_password} } }
Again, with the new named filter mechanism, it’s no longer possible to directly inject such config values via userdb, which makes fully dynamic per-user key provisioning harder. I now have to export all encrypted private keys from the database to the users home directory.
Ömer
Hi, I've run into what appears to be a regression (or at least a behavioral change) in Dovecot 3.3.0+ / current HEAD regarding crypt_private_key_file handling for the crypt_global_private_key. I don`t use per-folder user keys but a global encryption key per user. Previously, it was possible to provide the private key via userdb using an inline base64:-encoded PEM directly to the crypt_global_private_key_file and Dovecot would correctly parse and use it. With the latest config scheme change, this no longer works, as you cannot really set named config variables from userdb. I did workaround by setting a custom userdb variable and setting the needed named/filter variables manually in the config file. To make it work, I had to enclose the config in a "protocol imap" scope. The crypt_global_public_key_file is accessible from userdb (as it is not within a named filter scope), so inline-base64 works as with Dovecot 2.3+. When using the following workaround to reach the scoped variables, Dovecot tries to load the file "inline:BASE64ENCODEDPEM" as a literal filename (error open(inline:AB....C==) failed):
protocol imap {
crypt_global_private_key user {
crypt_private_key_file = %{userdb:private_key_file}
crypt_private_key_password = %{userdb:private_key_password}
}
}As a workaround, I now have to: o store the private key as a file (e.g. %{home}/privkey.pem) o pass only the password via userdb o inject the path indirectly via static config + userdb variables This works, but is less elegant:
protocol imap {
crypt_global_private_key user {
crypt_private_key_file = %{home}/privkey.pem
crypt_private_key_password = %{userdb:private_key_password}
}
}Again, with the new named filter mechanism, it's no longer possible to directly inject such config values via userdb, which makes fully dynamic per-user key provisioning harder. I now have to export all encrypted private keys from the database to the users home directory. Oemer
On 05/04/2026 22:18 EEST Ömer Güven via dovecot <dovecot@dovecot.org> wrote:
Hi,
I’ve run into what appears to be a regression (or at least a behavioral change) in Dovecot 3.3.0+ / current HEAD regarding crypt_private_key_file handling for the crypt_global_private_key.
I don‘t use per-folder user keys but a global encryption key per user.
Previously, it was possible to provide the private key via userdb using an inline base64:-encoded PEM directly to the crypt_global_private_key_file and Dovecot would correctly parse and use it.
With the latest config scheme change, this no longer works, as you cannot really set named config variables from userdb. I did workaround by setting a custom userdb variable and setting the needed named/filter variables manually in the config file. To make it work, I had to enclose the config in a „protocol imap“ scope. The crypt_global_public_key_file is accessible from userdb (as it is not within a named filter scope), so inline-base64 works as with Dovecot 2.3+.
When using the following workaround to reach the scoped variables, Dovecot tries to load the file „inline:BASE64ENCODEDPEM“ as a literal filename (error open(inline:AB….C==) failed):
protocol imap { crypt_global_private_key user { crypt_private_key_file = %{userdb:private_key_file} crypt_private_key_password = %{userdb:private_key_password} } }
As a workaround, I now have to: • store the private key as a file (e.g. %{home}/privkey.pem) • pass only the password via userdb • inject the path indirectly via static config + userdb variables
This works, but is less elegant:
protocol imap { crypt_global_private_key user { crypt_private_key_file = %{home}/privkey.pem crypt_private_key_password = %{userdb:private_key_password} } }
Again, with the new named filter mechanism, it’s no longer possible to directly inject such config values via userdb, which makes fully dynamic per-user key provisioning harder. I now have to export all encrypted private keys from the database to the users home directory.
Ömer Hi, I've run into what appears to be a regression (or at least a behavioral change) in Dovecot 3.3.0+ / current HEAD regarding crypt_private_key_file handling for the crypt_global_private_key. I don`t use per-folder user keys but a global encryption key per user. Previously, it was possible to provide the private key via userdb using an inline base64:-encoded PEM directly to the crypt_global_private_key_file and Dovecot would correctly parse and use it. With the latest config scheme change, this no longer works, as you cannot really set named config variables from userdb. I did workaround by setting a custom userdb variable and setting the needed named/filter variables manually in the config file. To make it work, I had to enclose the config in a "protocol imap" scope. The crypt_global_public_key_file is accessible from userdb (as it is not within a named filter scope), so inline-base64 works as with Dovecot 2.3+. When using the following workaround to reach the scoped variables, Dovecot tries to load the file "inline:BASE64ENCODEDPEM" as a literal filename (error open(inline:AB....C==) failed):
}As a workaround, I now have to: o store the private key as a file (e.g. %{home}/privkey.pem) o pass only the password via userdb o inject the path indirectly via static config + userdb variables This works, but is less elegant:
protocol imap { crypt_global_private_key user { crypt_private_key_file = %{home}/privkey.pem crypt_private_key_password = %{userdb:private_key_password} } }Again, with the new named filter mechanism, it's no longer possible to directly inject such config values via userdb, which makes fully dynamic per-user key provisioning harder. I now have to export all encrypted private keys from the database to the users home directory. Oemer
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Hi!
Did you try
protocol imap { crypt_global_private_key user { crypt_private_key_file = inline:%{userdb:private_key_file} crypt_private_key_password = %{userdb:private_key_password} } }
See https://doc.dovecot.org/2.4.3/core/settings/types.html#file
Aki
Yes, that didn‘t work either (by removing inline: from the variable and setting it in the config). I discovered yesterday that you can set „crypt_private_key_file“ in userdb and that this sets the global private key file (note that there is no prefix/named filter).
I can live with that, but I guess the correct way should‘ve be „crypt_global_private_key/user/crypt_private_key_file“, but latter is non-functional, despite documented. (Named list filter „user“ is set with empty content in config, so it should exist, but isn‘t reachable from userdb…)
Am 07.04.2026 um 07:11 schrieb Aki Tuomi <aki.tuomi@open-xchange.com>:
On 05/04/2026 22:18 EEST Ömer Güven via dovecot <dovecot@dovecot.org> wrote:
Hi,
I’ve run into what appears to be a regression (or at least a behavioral change) in Dovecot 3.3.0+ / current HEAD regarding crypt_private_key_file handling for the crypt_global_private_key.
I don‘t use per-folder user keys but a global encryption key per user.
Previously, it was possible to provide the private key via userdb using an inline base64:-encoded PEM directly to the crypt_global_private_key_file and Dovecot would correctly parse and use it.
With the latest config scheme change, this no longer works, as you cannot really set named config variables from userdb. I did workaround by setting a custom userdb variable and setting the needed named/filter variables manually in the config file. To make it work, I had to enclose the config in a „protocol imap“ scope. The crypt_global_public_key_file is accessible from userdb (as it is not within a named filter scope), so inline-base64 works as with Dovecot 2.3+.
When using the following workaround to reach the scoped variables, Dovecot tries to load the file „inline:BASE64ENCODEDPEM“ as a literal filename (error open(inline:AB….C==) failed):
protocol imap { crypt_global_private_key user { crypt_private_key_file = %{userdb:private_key_file} crypt_private_key_password = %{userdb:private_key_password} } }
As a workaround, I now have to: • store the private key as a file (e.g. %{home}/privkey.pem) • pass only the password via userdb • inject the path indirectly via static config + userdb variables
This works, but is less elegant:
protocol imap { crypt_global_private_key user { crypt_private_key_file = %{home}/privkey.pem crypt_private_key_password = %{userdb:private_key_password} } }
Again, with the new named filter mechanism, it’s no longer possible to directly inject such config values via userdb, which makes fully dynamic per-user key provisioning harder. I now have to export all encrypted private keys from the database to the users home directory.
Ömer Hi, I've run into what appears to be a regression (or at least a behavioral change) in Dovecot 3.3.0+ / current HEAD regarding crypt_private_key_file handling for the crypt_global_private_key. I don`t use per-folder user keys but a global encryption key per user. Previously, it was possible to provide the private key via userdb using an inline base64:-encoded PEM directly to the crypt_global_private_key_file and Dovecot would correctly parse and use it. With the latest config scheme change, this no longer works, as you cannot really set named config variables from userdb. I did workaround by setting a custom userdb variable and setting the needed named/filter variables manually in the config file. To make it work, I had to enclose the config in a "protocol imap" scope. The crypt_global_public_key_file is accessible from userdb (as it is not within a named filter scope), so inline-base64 works as with Dovecot 2.3+. When using the following workaround to reach the scoped variables, Dovecot tries to load the file "inline:BASE64ENCODEDPEM" as a literal filename (error open(inline:AB....C==) failed):
}As a workaround, I now have to: o store the private key as a file (e.g. %{home}/privkey.pem) o pass only the password via userdb o inject the path indirectly via static config + userdb variables This works, but is less elegant:
protocol imap { crypt_global_private_key user { crypt_private_key_file = %{home}/privkey.pem crypt_private_key_password = %{userdb:private_key_password} } }Again, with the new named filter mechanism, it's no longer possible to directly inject such config values via userdb, which makes fully dynamic per-user key provisioning harder. I now have to export all encrypted private keys from the database to the users home directory. Oemer
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Hi!
Did you try
protocol imap { crypt_global_private_key user { crypt_private_key_file = inline:%{userdb:private_key_file} crypt_private_key_password = %{userdb:private_key_password} } }
See https://doc.dovecot.org/2.4.3/core/settings/types.html#file
Aki
To make it more complicated: You can set it in doveadm -o crypt_global_private_key/user/crypt_private_key_file=inline:… but not in userdb the same way. (I‘m returning it via passdb lua, with userdb_ prefixed.) Setting userdb_crypt_private_key_file without any named filter works inexpectedly. So userdb returned variables are somehow parsed differently (maybe slashes aren‘t split) than doveadm options with divergent behavior and the documentation is wrong about that. :( I guess the way it works now is unintented and won‘t work in the future.
Am 07.04.2026 um 10:04 schrieb Ömer Güven <omer.guven@zuplu.com>: Yes, that didn‘t work either (by removing inline: from the variable and setting it in the config). I discovered yesterday that you can set „crypt_private_key_file“ in userdb and that this sets the global private key file (note that there is no prefix/named filter).
I can live with that, but I guess the correct way should‘ve be „crypt_global_private_key/user/crypt_private_key_file“, but latter is non-functional, despite documented. (Named list filter „user“ is set with empty content in config, so it should exist, but isn‘t reachable from userdb…)
Am 07.04.2026 um 07:11 schrieb Aki Tuomi <aki.tuomi@open-xchange.com>:
On 05/04/2026 22:18 EEST Ömer Güven via dovecot <dovecot@dovecot.org> wrote: Hi, I’ve run into what appears to be a regression (or at least a behavioral change) in Dovecot 3.3.0+ / current HEAD regarding crypt_private_key_file handling for the crypt_global_private_key. I don‘t use per-folder user keys but a global encryption key per user. Previously, it was possible to provide the private key via userdb using an inline base64:-encoded PEM directly to the crypt_global_private_key_file and Dovecot would correctly parse and use it. With the latest config scheme change, this no longer works, as you cannot really set named config variables from userdb. I did workaround by setting a custom userdb variable and setting the needed named/filter variables manually in the config file. To make it work, I had to enclose the config in a „protocol imap“ scope. The crypt_global_public_key_file is accessible from userdb (as it is not within a named filter scope), so inline-base64 works as with Dovecot 2.3+. When using the following workaround to reach the scoped variables, Dovecot tries to load the file „inline:BASE64ENCODEDPEM“ as a literal filename (error open(inline:AB….C==) failed): protocol imap { crypt_global_private_key user { crypt_private_key_file = %{userdb:private_key_file} crypt_private_key_password = %{userdb:private_key_password} } } As a workaround, I now have to: • store the private key as a file (e.g. %{home}/privkey.pem) • pass only the password via userdb • inject the path indirectly via static config + userdb variables This works, but is less elegant: protocol imap { crypt_global_private_key user { crypt_private_key_file = %{home}/privkey.pem crypt_private_key_password = %{userdb:private_key_password} } } Again, with the new named filter mechanism, it’s no longer possible to directly inject such config values via userdb, which makes fully dynamic per-user key provisioning harder. I now have to export all encrypted private keys from the database to the users home directory. Ömer Hi, I've run into what appears to be a regression (or at least a behavioral change) in Dovecot 3.3.0+ / current HEAD regarding crypt_private_key_file handling for the crypt_global_private_key. I don`t use per-folder user keys but a global encryption key per user. Previously, it was possible to provide the private key via userdb using an inline base64:-encoded PEM directly to the crypt_global_private_key_file and Dovecot would correctly parse and use it. With the latest config scheme change, this no longer works, as you cannot really set named config variables from userdb. I did workaround by setting a custom userdb variable and setting the needed named/filter variables manually in the config file. To make it work, I had to enclose the config in a "protocol imap" scope. The crypt_global_public_key_file is accessible from userdb (as it is not within a named filter scope), so inline-base64 works as with Dovecot 2.3+. When using the following workaround to reach the scoped variables, Dovecot tries to load the file "inline:BASE64ENCODEDPEM" as a literal filename (error open(inline:AB....C==) failed):
}As a workaround, I now have to: o store the private key as a file (e.g. %{home}/privkey.pem) o pass only the password via userdb o inject the path indirectly via static config + userdb variables This works, but is less elegant: protocol imap { crypt_global_private_key user { crypt_private_key_file = %{home}/privkey.pem crypt_private_key_password = %{userdb:private_key_password} } } Again, with the new named filter mechanism, it's no longer possible to directly inject such config values via userdb, which makes fully dynamic per-user key provisioning harder. I now have to export all encrypted private keys from the database to the users home directory. Oemer
dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-leave@dovecot.org
Hi!
Did you try
protocol imap { crypt_global_private_key user { crypt_private_key_file = inline:%{userdb:private_key_file} crypt_private_key_password = %{userdb:private_key_password} } }
See https://doc.dovecot.org/2.4.3/core/settings/types.html#file
Aki
To make it more complicated: You can set it in
doveadm -o
crypt_global_private_key/user/crypt_private_key_file=inline:...but not in userdb the same way. (Im returning it via passdb lua, with userdb_ prefixed.) Setting userdb_crypt_private_key_file without any named filter works inexpectedly. So userdb returned variables are somehow parsed differently (maybe slashes arent split) than doveadm options with
divergent behavior and the documentation is wrong about that. :(
I guess the way it works now is unintented and won`t work in the future.
Am 07.04.2026 um 10:04 schrieb Oemer Gueven <omer.guven@zuplu.com>:
Yes, that didn`t work either (by removing inline: from the variable and
setting it in the config).
I discovered yesterday that you can set "crypt_private_key_file" in
userdb and that this sets the global private key file (note that there
is no prefix/named filter).
I can live with that, but I guess the correct way should`ve be
"crypt_global_private_key/user/crypt_private_key_file", but latter is
non-functional, despite documented. (Named list filter "user" is set
with empty content in config, so it should exist, but isn`t reachable
from userdb...)
Am 07.04.2026 um 07:11 schrieb Aki Tuomi <aki.tuomi@open-xchange.com>:
On 05/04/2026 22:18 EEST Oemer Gueven via dovecot
<dovecot@dovecot.org> wrote:
Hi,
I've run into what appears to be a regression (or at least a
behavioral change) in Dovecot 3.3.0+ / current HEAD regarding
crypt_private_key_file handling for the crypt_global_private_key.
I don`t use per-folder user keys but a global encryption key per
user.
Previously, it was possible to provide the private key via userdb
using an inline base64:-encoded PEM directly to the
crypt_global_private_key_file and Dovecot would correctly parse and
use it.
With the latest config scheme change, this no longer works, as you
cannot really set named config variables from userdb. I did
workaround by setting a custom userdb variable and setting the
needed named/filter variables manually in the config file.
To make it work, I had to enclose the config in a "protocol imap"
scope.
The crypt_global_public_key_file is accessible from userdb (as it is
not within a named filter scope), so inline-base64 works as with
Dovecot 2.3+.
When using the following workaround to reach the scoped variables,
Dovecot tries to load the file "inline:BASE64ENCODEDPEM" as a
literal filename (error open(inline:AB....C==) failed):
protocol imap {
crypt_global_private_key user {
crypt_private_key_file = %{userdb:private_key_file}
crypt_private_key_password = %{userdb:private_key_password}
}
}
As a workaround, I now have to:
o store the private key as a file (e.g. %{home}/privkey.pem)
o pass only the password via userdb
o inject the path indirectly via static config + userdb
variables
This works, but is less elegant:
protocol imap {
crypt_global_private_key user {
crypt_private_key_file = %{home}/privkey.pem
crypt_private_key_password = %{userdb:private_key_password}
}
}
Again, with the new named filter mechanism, it's no longer possible
to directly inject such config values via userdb, which makes fully
dynamic per-user key provisioning harder. I now have to export all
encrypted private keys from the database to the users home
directory.
Oemer
Hi,
I've run into what appears to be a regression (or at least a
behavioral
change) in Dovecot 3.3.0+ / current HEAD regarding
crypt_private_key_file
handling for the crypt_global_private_key.
I don`t use per-folder user keys but a global encryption key per
user.
Previously, it was possible to provide the private key via userdb
using an
inline base64:-encoded PEM directly to the
crypt_global_private_key_file
and Dovecot would correctly parse and use it.
With the latest config scheme change, this no longer works, as you
cannot
really set named config variables from userdb. I did workaround by
setting
a custom userdb variable and setting the needed named/filter
variables
manually in the config file.
To make it work, I had to enclose the config in a "protocol imap"
scope.
The crypt_global_public_key_file is accessible from userdb (as it
is not
within a named filter scope), so inline-base64 works as with
Dovecot 2.3+.
When using the following workaround to reach the scoped variables,
Dovecot
tries to load the file "inline:BASE64ENCODEDPEM" as a literal
filename
(error open(inline:AB....C==) failed):
}
As a workaround, I now have to:
o store the private key as a file (e.g.
%{home}/privkey.pem)
o pass only the password via userdb
o inject the path indirectly via static config +
userdb
variables
This works, but is less elegant:
protocol imap {
crypt_global_private_key user {
crypt_private_key_file = %{home}/privkey.pem
crypt_private_key_password =
%{userdb:private_key_password}
}
}
Again, with the new named filter mechanism, it's no longer possible
to
directly inject such config values via userdb, which makes fully
dynamic
per-user key provisioning harder. I now have to export all
encrypted
private keys from the database to the users home directory.
Oemer
_______________________________________________
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-leave@dovecot.org
Hi!
Did you try
protocol imap {
crypt_global_private_key user {
crypt_private_key_file = inline:%{userdb:private_key_file}
crypt_private_key_password = %{userdb:private_key_password}
}
}
See https://doc.dovecot.org/2.4.3/core/settings/types.html#file
AkiOn 7. Apr 2026, at 11.23, Ömer Güven via dovecot <dovecot@dovecot.org> wrote:
To make it more complicated: You can set it in
doveadm -o crypt_global_private_key/user/crypt_private_key_file=inline:...but not in userdb the same way. (I
m returning it via passdb lua, with userdb_ prefixed.) Setting userdb_crypt_private_key_file without any named filter works inexpectedly. So userdb returned variables are somehow parsed differently (maybe slashes arent split) than doveadm options with divergent behavior and the documentation is wrong about that. :( I guess the way it works now is unintented and won`t work in the future.
It would help if you gave full crypto configs in dovecot.conf and userdb of what doesn't work. I'm now suspecting that you're trying to return everything from userdb, but you don't create the "user" named list filter anywhere? If you don't have in config:
crypt_global_private_key user { }
Then in userdb you need to return userdb_crypt_global_private_key=user to create it.
Not really sure why it works in -o parameter without it.
I created that empty user named list in my config, so it exists. I wrote about that earlier. You still cannot set values inside it via userdb but only via doveadm.
Am 07.04.2026 um 11:45 schrieb Timo Sirainen <timo@sirainen.com>:
On 7. Apr 2026, at 11.23, Ömer Güven via dovecot <dovecot@dovecot.org> wrote:
To make it more complicated: You can set it in
doveadm -o crypt_global_private_key/user/crypt_private_key_file=inline:...but not in userdb the same way. (I
m returning it via passdb lua, with userdb_ prefixed.) Setting userdb_crypt_private_key_file without any named filter works inexpectedly. So userdb returned variables are somehow parsed differently (maybe slashes arent split) than doveadm options with divergent behavior and the documentation is wrong about that. :( I guess the way it works now is unintented and won`t work in the future.It would help if you gave full crypto configs in dovecot.conf and userdb of what doesn't work. I'm now suspecting that you're trying to return everything from userdb, but you don't create the "user" named list filter anywhere? If you don't have in config:
crypt_global_private_key user { }
Then in userdb you need to return userdb_crypt_global_private_key=user to create it.
Not really sure why it works in -o parameter without it.
It's not very clear from your mails what configuration doesn't work. I see you've mainly listed configuration for workarounds that do work, or workarounds that do not work. Since we have a passing CI test for the functionality you're apparently trying, I'm not sure what is going on with your config that is different. Please send the whole doveconf -n and the returned values from your userdb. Privately is fine too.
On 7. Apr 2026, at 14.07, Ömer Güven <omer.guven@zuplu.com> wrote:
I created that empty user named list in my config, so it exists. I wrote about that earlier. You still cannot set values inside it via userdb but only via doveadm.
Am 07.04.2026 um 11:45 schrieb Timo Sirainen <timo@sirainen.com>:
On 7. Apr 2026, at 11.23, Ömer Güven via dovecot <dovecot@dovecot.org> wrote:
To make it more complicated: You can set it in
doveadm -o crypt_global_private_key/user/crypt_private_key_file=inline:...but not in userdb the same way. (I
m returning it via passdb lua, with userdb_ prefixed.) Setting userdb_crypt_private_key_file without any named filter works inexpectedly. So userdb returned variables are somehow parsed differently (maybe slashes arent split) than doveadm options with divergent behavior and the documentation is wrong about that. :( I guess the way it works now is unintented and won`t work in the future.It would help if you gave full crypto configs in dovecot.conf and userdb of what doesn't work. I'm now suspecting that you're trying to return everything from userdb, but you don't create the "user" named list filter anywhere? If you don't have in config:
crypt_global_private_key user { }
Then in userdb you need to return userdb_crypt_global_private_key=user to create it.
Not really sure why it works in -o parameter without it.
I have sent you the lua and config privately.
Am 07.04.2026 um 13:22 schrieb Timo Sirainen <timo@sirainen.com>:
It's not very clear from your mails what configuration doesn't work. I see you've mainly listed configuration for workarounds that do work, or workarounds that do not work. Since we have a passing CI test for the functionality you're apparently trying, I'm not sure what is going on with your config that is different. Please send the whole doveconf -n and the returned values from your userdb. Privately is fine too.
On 7. Apr 2026, at 14.07, Ömer Güven <omer.guven@zuplu.com> wrote:
I created that empty user named list in my config, so it exists. I wrote about that earlier. You still cannot set values inside it via userdb but only via doveadm.
Am 07.04.2026 um 11:45 schrieb Timo Sirainen <timo@sirainen.com>:
On 7. Apr 2026, at 11.23, Ömer Güven via dovecot <dovecot@dovecot.org> wrote:
To make it more complicated: You can set it in
doveadm -o crypt_global_private_key/user/crypt_private_key_file=inline:...but not in userdb the same way. (I
m returning it via passdb lua, with userdb_ prefixed.) Setting userdb_crypt_private_key_file without any named filter works inexpectedly. So userdb returned variables are somehow parsed differently (maybe slashes arent split) than doveadm options with divergent behavior and the documentation is wrong about that. :( I guess the way it works now is unintented and won`t work in the future.It would help if you gave full crypto configs in dovecot.conf and userdb of what doesn't work. I'm now suspecting that you're trying to return everything from userdb, but you don't create the "user" named list filter anywhere? If you don't have in config:
crypt_global_private_key user { }
Then in userdb you need to return userdb_crypt_global_private_key=user to create it.
Not really sure why it works in -o parameter without it.
participants (3)
-
Aki Tuomi
-
Timo Sirainen
-
Ömer Güven