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
Aki