There is still a serious bug in dovecot 2.4.4 with the ssl_key_file.
If e.g. sievec is invoked.

→ doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf
line 76: key_file: open(/etc/ssl/private/XXXXXX.key.pem) failed: Permission
denied

The same occurs in for every mail deliverd to any user account using mailsieve
and a lot of error mails are produced degrading the mail-service for the users.

The problem is upstream discussed in
https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/KT7LWWQWEMLKKLKXICBGPG7OGOQIJWEV/
There is also a weird configuration hack mentioned to mitigate the dovecot bug.
The bug is that the key_file isn't read before the privileges are dropped e.g.
for the sieve processing.

This bug was solved in dovecot 2.4.5.

I mitigated the problem here with a no-change forky backport for the moment.

Please upgrade the trixie version from 2.4.4 to 2.4.5 to solve the problem for
other users.

Control: tags -1 + moreinfo

I'm a bit confused.  You reported this bug against version 2.4.5, but
also claim that it's fixed in 2.4.5.  Do you happen to know exactly
where/what the fix is?  The mailing list thread doesn't seem to identify
it a specific commit as containing the fix.

Trixie contains 2.4.1 (with a bunch of backported bugfixes, not 2.4.4).
Unfortunately dovecot minor versions contain incompatible changes, so we
cannot simply upgrade between them with trixie point releases.  We will
need to identify the specific commit so we can introduce a targeted fix
into trixie's version.

noah

Am Sonntag, dem 18.10.2026 um 17:35 -0400 schrieb Noah Meyerhans:

As written:
That is the reason 2.4.5 was picked up.

I can't identify the fix on github – sorry. 
Sorry this was a typo in in the 3rd number.

Maybe it can be added to backports?
The forky version compiles as backport without any changes.

Best Regards,

H.-Dirk 

should be fixed in the main archive.

Unfortunately, I haven't been able to find a suitable looking change
from the 2.4.4..2.4.5 range upstream.  I have also been unable to come
up with a way to reproduce the failure.

From your description, as well as the mailing list discussion, it seems
like issue is that when a dovecot program is run as a user that does not
have permission to access some file referenced in the configuration,
typically a TLS key.  So, to try to reproduce this failure, I've set up
the following and tested it with the dovecot 1:2.4.1+dfsg1-6 packages
from the original trixie release.  I have not encountered any errors,
though, so something must be missing.  Can you tell from here what's
missing?  If you can provide a minimal repro configuration, that would
be helpful.

Certificates are locked down:

# ls -l /etc/dovecot/private/tls/
total 8
-r-------- 1 1000 1000 1529 May  8  2025 example.net.crt
-r-------- 1 1000 1000 1704 May  8  2025 example.net.key

And what I think are the relevant parts of `doveconf -n`:

dovecot_config_version = 2.4.0
dovecot_storage_version = 2.4.0
mail_gid = vmail
mail_uid = vmail
mail_home = /home/vmail/users/%{user | username}/mail
mail_path = /home/vmail/users/%{user | username}/mail
mail_privileged_group = mail
ssl_server {
  cert_file = /etc/dovecot/private/tls/example.net.crt
  key_file = /etc/dovecot/private/tls/example.net.key
}
protocol lda {
  mail_plugins {
    sieve = yes
  }
  sieve_script personal {
    driver = file
    path = /home/vmail/users/%{user | username}/mail.sieve
  }
}
protocol lmtp {
  auth_username_format = %{user | username | lower}
  mail_plugins {
    sieve = yes
  }
  sieve_script personal {
    path = /home/vmail/users/%{user | username}/mail.sieve
  }
}

I've then created a virtual user with a sieve script that does some
simple filtering:

root@94faf4d30408:/home/vmail/users/testuser# cat mail.sieve
require ["fileinto", "envelope"];
if header :is "X-Sieve-Test" "yes" {
  fileinto "incoming/filtered";
} else {
  keep;
}

And sent mail to that user using /usr/lib/dovecot/deliver:

root@94faf4d30408:/home/vmail/users/testuser# cat | runuser -u vmail -g vmail -- /usr/lib/dovecot/deliver -e -f mailer-daemon -a testuser -d testuser
From: mailer-daemon
To: noahm <noahm@localhost>
Subject: test message
X-Sieve-Test: yes
Message-ID: <this-is-a-test-message-3311@some-host.somewhere>

testing delivery

lda(testuser)<113><6YMTBeF31mpxAAAA1oRN5w>: Info: sieve: msgid=<this-is-a-test-message-3311@some-host.somewhere>: fileinto action: stored mail into mailbox 'incoming/filtered'

Have you tried with the certificates outside of /etc/dovecot? I think that is where the issues start. But I am not at my pc, so can’t test now.

Kind regards,

    Edmund

That doesn't seem to be it.

root@1e17878e1058:/home/vmail# doveconf -n|grep -A3 ssl_server
ssl_server {
  cert_file = /etc/tls/example.net.crt
  key_file = /etc/tls/example.net.key
}
root@1e17878e1058:/home/vmail# ls -ld /etc/tls /etc/tls/*
drwx------ 2 1000 1000 4096 Oct 19 18:10 /etc/tls
-r-------- 1 1000 1000 1529 May  8  2025 /etc/tls/example.net.crt
-r-------- 1 1000 1000 1704 May  8  2025 /etc/tls/example.net.key

Sieve compilation and filtering still works without error when deliver is
invoked as the vmail user:

root@1e17878e1058:/home/vmail/users/testuser# ls -l mail.*
-rw-r--r-- 1 vmail vmail 122 Oct 19 19:44 mail.sieve
root@1e17878e1058:/home/vmail/users/testuser# generate-test-mail.sh | runuser -u vmail -g vmail -- /usr/lib/dovecot/deliver -e -f mailer-daemon -a testuser -d testuser
lda(testuser)<48><FKxnB5Kt12owAAAAOT1REg>: Info: sieve: msgid=<this-is-a-test-message-899@some-host.somewhere>: fileinto action: stored mail into mailbox 'incoming/filtered'
root@1e17878e1058:/home/vmail/users/testuser# ls -l mail.*
-rw-r--r-- 1 vmail vmail 122 Oct 19 19:44 mail.sieve
-rw-r--r-- 1 vmail vmail 317 Oct 20 18:06 mail.svbin

Sorry for my late response – due to illness I was some days offline. 

Mee to 😉 
I asked in
the https://dovecot.org/mailman3/archives/users/0f8d81437b7e48e39f7fd13b0e57166d/
 for the patch – maybe it helps.
[...]
ssl = yes
ssl_server_cert_file = /etc/dovecot/private/c42-client.cert.pem
ssl_server_key_file = /etc/dovecot/private/c42-client.key.pem
ssl_server_ca_file = /etc/ssl/certs/c42-srv-ca.crt
ssl_min_protocol = TLSv1.2
ssl_server {
  cert_file = /etc/ssl/c42/c42-client.cert.pem
  dh_file = /etc/dovecot/dh.pem
  key_file = /etc/ssl/private/c42-client.key.pem
}

Maybe your configuration is to „small“. I have the suspicion that the
'ssl = yes' is required – maybe more.

Thanks for your all time investigation the issue. I would really like
to go back to the stable debian version of dovecot instead being
responsible for my own backport.

Best Regards,

H.-Dirk Schmitt

Sorry - copy&paste error:
dovecet mailinglist
→ https://dovecot.org/mailman3/archives/list/dovecot@dovecot.org/thread/KT7LWWQWEMLKKLKXICBGPG7OGOQIJWEV/

I think that's it.  I only had the top-level ssl_server_* settings, I
did not have the ssl_server block.  When I added that, I encountered the
reported failure:

# cat /etc/dovecot/conf.d/10-ssl.conf
ssl = yes
ssl_server_cert_file = /etc/tls/example.net.crt
ssl_server_key_file = /etc/tls/example.net.key
ssl_min_protocol = TLSv1.2
ssl_server {
    key_file = /etc/tls/example.net.key
}

# generate-test-mail.sh | runuser -u vmail -g vmail -- /usr/lib/dovecot/deliver -e -f mailer-daemon -a testuser -d testuser
doveconf: Fatal: Error in configuration file /etc/dovecot/conf.d/10-ssl.conf line 8: key_file: open(/etc/tls/example.net.key) failed: Permission denied


Is it not sufficient for your configuration to list the ssl_server_*
settings and omit the ssl_server block?  The docs don't indicate a need
to define an ssl_server block in a normal configuration:
https://doc.dovecot.org/2.4.5/core/config/ssl.html#configuration-overview

noah

I'm not sure. I migrated my old 2.3 configuration with the help
of https://dovecot.org/upgrader 
Wasn't the `ssl = true` the triggering point?

Best Regards
H.-Dirk  Schmitt

No, I had that in my config all along.  What I posted earlier was only
what I suspected as the relevant part of the doveconf -n output; I
figured actually enabling ssl was assumed.

Try updating your config to drop the ssl_server {} block and see if that
resolves the issue for you.  Based on what I've seen, I suspect it will.
Note that you can move the nested dh_file setting to a top-level
ssl_server_dh_file setting to go along with the rest of the top-level
settings.

If this works, that doesn't change the fact that this is a bug that
should be fixed, but it may reduce the urgency of it and let you move
back to the trixie packages.

noah