I have the same issue since the 2.4 update, in my case affecting use of dovecot-lda as a transport for Postfix.
The transport invokes dovecot-lda as an unprivileged user 'vmail' and it fails with the same permission error showing up in syslog. Immediate remedial options of loosening permissions on private key file(s) or invoking dovecot-lda as root are suboptimal to say the least (the latter would probably break my virtual mailbox config anyway). >The technical reason might be that dovecot.conf is parsed for each doveadm invocation? This is borne out by the manpage: "All standalone programs, such as dovecot(1), will first get their settings by executing doveconf, unless they can get the settings by connecting to the config UNIX socket." This may or may not be applicable with doveadm depending upon your personal config and what subcommands are needed, but for dovecot-lda I think a solution that may work is to create a separate config file, minus the ssl_* directives, to use instead of the normal dovecot.conf in this context. >In any case, the certificate access check for subcommands like "flags" or "mailbox" seems like a bug to me. Agreed, because it in effect makes these commands only runnable by root (unless you want to live with sloppy file permissions on your SSL keys). Doveconf needs to be more context-aware and/or be permitted to not puke on the certs being unreadable in certain invocations. It's probably a lot more complex to address for doveadm due to its scope (when I use it I usually have needed to be root anyway) but lda has no use for SSL whatsoever as far as I'm aware so it should be able to invoke doveconf without configs that don't concern it causing errors. Best, Robin _______________________________________________ dovecot mailing list -- [email protected] To unsubscribe send an email to [email protected]
